This invention relates generally to the field of dependent accounts, and more particularly embodiments of the invention relate to apparatuses and methods for a dependent account, such as a credit card or other type of account, which provides the primary user flexible control mechanisms over the use of the dependent account by the dependent user.
It may be difficult for some people with limited financial transaction history to be approved for a credit card, or other type of financial account. Furthermore, customers are typically averse to acting as co-signers for people with limited financial transaction history because they do not want to be liable for any debt that other people on the account might accrue. As such, some customers in some situations may want to control the purchases of other customers, for example with parent-child, child-parent, employer-employee, legal representative-legal dependent, or other like relationships.
Embodiments of the present invention address the above needs and/or achieve other advantages by providing apparatuses (e.g., a system, computer program product, and/or other device) and methods that help a primary user of one or more accounts control the transactions made by a dependent user of the one or more accounts.
Embodiments of the prevent invention allow a primary user to open a dependent account (or link a current account to a dependent user), such as, but not limited to, a dependent credit card account in order to control and monitor the transactions made by a dependent user that is authorized to use the dependent account controlled by the primary user. In other embodiments of the invention, other types of accounts may be used, such as debit accounts. Examples of a dependent account are generally described herein with reference to a dependent credit card account; however, references to credit cards, dependent credit card accounts, or other types of financial accounts, may be replaced by references to other types of accounts, such as debit accounts or the like, throughout this application and the invention discussed herein applies to the other types of accounts.
In some embodiments of the invention the primary user discussed herein may be a parent and the dependent user discussed herein may be a child. In other embodiments the primary user may be an owner, manager, or employee within a business that would like to control the spending of a dependent user who may be another employee of the business. In other embodiments of the invention the primary user may be a guardian and dependent user is a legal dependent of the primary user. In still other embodiments of the invention the primary user may be a child and the dependent user may be parent of the child that may need help in managing finances. In some embodiments the primary user may be a trustee and the dependent user may be beneficiary of the trust. In other embodiments the primary user may be any person, while the dependent user is any other person agreeing to allow the primary user to control the use of the dependent user's account or use of the primary user's account. Furthermore, although a credit card is often used herein to describe the payment device that is utilized to make a transaction, it should be understood that the present invention may include payment devices other than cards and/or financial accounts other than credit card accounts. For example, instead of a credit card the payment device may be a debit card, gift card, reward card, or another other type of card. In other embodiments the payment device may be a mobile wallet, phone application, near-field communication device, or any other type of electronic payment device, or may simply be account information that is stored within a database and electronically transferred to enter into a transaction. The financial accounts may be any type of account, such as, but not limited to checking accounts, debit accounts, savings accounts, investment accounts, prepaid accounts, or any other type of account.
In some embodiments, the primary user can set a maximum limit that the dependent user can spend using an account up to the maximum amount (e.g., up to or equal to) that the financial institution has approved for the account. In some embodiments, the primary user can also limit the transactions that the dependent user can make at a store (e.g., a physical store location, over the Internet, over the telephone with a representative, or the like) or on goods or services (hereinafter “products”). In some embodiments limits on the stores include specific stores, such as, but not limited to chain stores or individual stores, or in other embodiments the limits on stores includes stores that are grouped together in various categories. A store can be grouped in more than one category, for example a one-stop shopping store that sells a range of products can be grouped as both a grocery store and an electronics store. With respect to the limits on products, in some embodiments, the limits include a single product, or in other embodiments product limits include limits on the type of products that are grouped together in various categories, or limits on a brand that covers a range of products. A product can be grouped into more than one category of products, for example, a specific beverage can be grouped into a category with other beverages, and also be grouped into a snack food category that includes beverages, chips, cookies, candy, and the like.
The primary user can limit the transactions that the dependent user can make by, for example, adding Merchant Category Codes (MCCs), store names, store types, Universal Product Codes (UPCs), Stock Keeping Unit Codes (SKUs), product names, product types, and/or other like identifiers (e.g., merchant identifiers or product identifiers) to a blocked list or an approved list of stores or products. In other embodiments, the primary user can set transaction amount limits and transaction time limits on the transactions the dependent user can make at the blocked/approved stores or on the blocked/approved products that the primary user added to the blocked/approved list. In some embodiments of the invention the transaction time limits are days, weeks, months, or the like, but in other embodiments the time limits may be times of day (e.g., morning, afternoon, night), or specific hours of the day (e.g., between 11 am and 1 pm).
In other embodiments of the invention other limits, such as transaction type limits (e.g., in store purchase vs. online purchase, or the like), location limits (e.g., radius location, zip code, state, region, or the like), or variance limits (e.g., particular transactions may be a percentage or dollar amount over the limits). In addition to the merchant limits and product limits, these types of limits may be described herein as transaction account limits, while the limits on the amounts of the transaction may be described herein a transaction amount limits, and the limits on the time of the transaction may be described as transaction time limits.
Furthermore, the primary user can periodically edit the transaction account limits (e.g., merchant limits or the products limits) on the blocked/approved list, as well as the transaction amount limits, the transaction time limits, and other limits in order to control the transactions made by the dependent user as the needs of the dependent user change. In some embodiments, both the primary user and dependent user can view the transactions made through the account by logging into an online banking account. The dependent user may be prevented from having the ability to access the sections of the dependent account related to the limits set by the primary user, which control the transactions the dependent user is allowed to make.
A blocked list of transactions allows a dependent user to enter into the transactions on the list according to the limits on the list as well as all other types of transactions not specifically included in the list. An approved list of transactions allows the primary user to limit the transactions that the dependent user can enter into to only the transactions on the list according to the limits and no other transactions outside of what is listed. The blocked list and approved list work in much the same way, in that the primary user can set transaction account limits on the stores and products by using merchant or product identifiers, or other types of limits, as well as transaction amount limits and transaction time limits. As such, the dependent user can make any type of transaction outside of any store or product on the blocked list, while the approved list only allows the dependent user to make transactions that are included on the approved list.
In addition to the limits discussed above the primary user may also set allocation limits that limit the amount of an allowed transaction that can be applied to the dependent account. The difference between the allowed transaction amount and the allocation limit amount is to be paid for through the use of another account of the primary user or dependent user. The alternate account may be pre-determined, may be determined at the time of the transaction, or at a later point in time after the transaction has been completed between the dependent user and the merchant.
The features, functions, and advantages that have been discussed may be achieved independently in various embodiments of the present invention or may be combined in yet other embodiments, further details of which can be seen with reference to the following description and drawings.
Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, wherein:
Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout. Although some embodiments of the invention described herein are generally described as involving a “financial institution” or “bank,” one of ordinary skill in the art will appreciate that other embodiments of the invention may involve other businesses that take the place of or work in conjunction with the financial institution or bank to perform one or more of the processes or steps described herein as being performed by a financial institution. Still in other embodiments of the invention the financial institution or bank described herein may be replaced with other types of businesses that offer account services to customers.
As further described herein users 9 may be either primary users or dependent users. As previously described, the primary users are generally users 9 that control the dependent accounts, set the limits on the dependent accounts, and in some embodiments are ultimately responsible for the debt accrued through the use of the dependent accounts. The primary users, in some cases, are the only users 9 that can set-up and change the transaction account limits, transaction amount limits, transaction time limits, and allocation limits, as is described in further detail later, which are used for controlling the transactions of the dependent users, and allocation of the transaction costs.
As illustrated by block 104 of
Block 106 of
As illustrated by block 108, the primary user may also set an allocation limit for the transaction amount limit in block 104. The allocation limit may limit the amount of a transaction that can be applied to a particular dependent account. For example, continuing with the example provided for block 104, while there may be a $200 transaction amount limit, the primary user may only want to allow a portion of the $200 transaction amount limit using a first dependent account. As such the allocation limit may only be $150. The purchase for the TV may only be made when a particular TV is purchased from a particular store based on the transaction account limits from block 102, and the TV costs less than $200 based on the transaction amount limit from block 104; however, only $150 is charged to the first dependent account, and either the remainder is charged to another account or paid by the dependent user himself at the point of sale (e.g., cash). In other embodiments of the invention the allocation limit may be used a number of different ways to control the purchases a dependent user, as will be explained in further detail with respect to
After the limits are set, as illustrated by block 110, an indication is received by the financial institution that a dependent user has entered into a transaction. The financial institution determines if the transaction meets or violates the transaction account limits set in block 102, as illustrated in block 112. If the account limits are violated then the transaction may be denied. If however, the account limits are met, then as illustrated by block 114 the financial institution determines if the transaction meets or violates the transaction amount limits and the transaction time limits. If the transaction amount limits or transaction time limits are violated then the transaction may be denied. If however, the transaction amount limits and transaction time limits are met, then as illustrated by block 116 the transaction is allowed and a determination is made if the transaction meets or violates the allocation limits. If the transaction meets the allocation limits then the transaction is allowed. However, as illustrated by block 118 if the transaction violates the allocation limits then a determination is made on where to allocate the deficiency in the transaction amount to other accounts (e.g., other dependent user accounts, another account owned by the dependent user that is not controlled by the primary user, credit card, cash, debit account, or the like that the dependent user controls or that belongs to the primary user, or the like). As such, the present invention allows a primary user to not only control the purchases of a dependent user by controlling limits on the transaction, but may also allocate how the transaction may be funded.
After the primary user is authenticated, the online banking application 17 displays the online banking home page interface 300, as illustrated in
In other embodiments of the invention, the primary user may take a current account that is owned by the primary user and link the account to a dependent user (e.g., add the dependent user to the primary account to create a dependent account), and as such the dependent user may be able to enter into transactions using the dependent account. For example, a primary user may have a credit card account that the primary user links to a dependent user. As such, the dependent user may receive a credit card that is linked to the primary user's credit card account. In other embodiments the link may be an electronic link that allows the dependent user to make transactions using a mobile wallet or other like device using the primary user's account.
Continuing with the example of applying for a dependent credit card, after selecting the dependent credit card link 332 the primary user is taken to the account interface 400 in the account tab 402, as illustrated by
In some embodiments the dependent user may log into his online banking account to participate in the application process, such as to complete the dependent user section 440. In some embodiments of the invention the dependent user may fill out the dependent user section 440 first and ask a person to act as the primary user by having the person sign into the primary user's online banking account to fill out the rest of the application. In other embodiments of the invention, the dependent user logs into the online banking account after the primary user has filled out the primary user section 410 of the application. In some embodiments of the invention the primary user and dependent user may sign into the online banking account before the dependent credit card is issued in order to agree to the terms and conditions of the card. In other embodiments of the invention the primary user or dependent user can fill out or apply for a part of or all of the dependent credit card application through another channel, such as, in person at the bank, over e-mail, over instant message, or the like.
After the primary user has created the dependent account, the primary user can begin to set the account limits on the dependent account. In some embodiments the primary user can set a dependent account balance limit, block/approve specific MCCs, stores, and/or products using the primary user's online banking account.
As illustrated by block 204 of
As illustrated in
In some embodiments of the invention the primary user can put different limits on the same merchants. For example, as illustrated in
If the primary user does not want the dependent user to be able to purchase anything related to a particular merchant, in one embodiment the primary user can set a limit of zero (0) dollars for the particular merchant. For example, if the primary user wants to prevent a dependent user from purchasing any products at a package store, such as beer, wine, and liquor, the primary user sets a limit of zero (0) dollars on the merchant related to package stores. In other embodiments of the invention no transaction amount limits are included on the blocked list, and as such if a merchant is added to the blocked list the dependent user is simply not allowed to purchase anything from the merchant. This may also apply to an approved list in which the merchants on the approved list are the only merchants with which the dependent user may enter into transactions.
In other embodiments of the invention, the primary user can add specific stores to the blocked list if the primary user wants to limit the transactions the dependent user can make at specific stores. For example, as illustrated in
In order to add the merchant codes, or other particular stores to the blocked/approved list, in one embodiment, the primary user can enter the MCC, type of store, store name, address, or the like directly into the blocked/approved list. In other embodiments, the primary user can enter the MCC, type of store, store name, address, or the like into a search feature and thereafter into the blocked/approved list after each is found through the search feature. As illustrated in the search section 540 of
In some embodiments of the invention the primary user can add a range of MCCs (or other merchant identifiers) to the blocked/approved list, so that the dependent user does not need to add every individual MCC related to a particular industry to the blocked/approved list. For example, the primary user can add the group of MCCs from three-thousand (3000) to three-thousand two-hundred and ninety-nine (3299) which covers “Airlines” in order to limit the transactions the dependent user can make with merchants related to airlines.
As illustrated by block 206, a primary user may also set a product limit on the dependent account. The primary user can create a blocked/approved list of transactions for products by, for example, selecting particular UPCs, SKUs, or other types of product codes, product names, product types, product brands, product categories, or the like (collectively “product identifiers”). For example, UPCs are codes that are assigned to each product in the market. The UPCs have a bar code assigned to each UPC such that when the product is purchased computer systems identify the product for purposes such as pricing, accounting, inventory, or the like. UPCs or other product codes may be used to add products to the blocked/approved list.
The product identifiers may be used to add products to the blocked/approved list in the same way as was discussed with respect to the merchant identifiers in block 204 of
As illustrated in
If the primary user does not want the dependent user to be able to purchase anything related to a particular product, in one embodiment the primary user can set a limit of zero (0) dollars for the particular product. For example, if the primary user wants to prevent a dependent user from purchasing any products related to alcohol, such as beer, wine, and liquor, the primary user sets a limit of zero (0) dollars on the product types related to alcohol. In other embodiments of the invention no transaction amount limits are included on the blocked list, and as such if a product is added to the blocked list the dependent user simply is not allowed to purchase the product. This may also apply to an approved list in which the products on the approved list are the only products for which the dependent user may enter into transactions.
In some embodiments of the invention the primary user can put different limits on the same products, as was described with respect to the merchant limits in block 204. In other embodiments of the invention products limits may be added to a blocked/approved list in addition to merchant limits. For example, as illustrated in
In order to add the products to the blocked/approved list, in one embodiment, the primary user may enter the products identifiers (e.g., SKU, UPC, product names, brand names, or the like) directly into the blocked/approved list. In other embodiments, the primary user may enter the products identifiers (e.g., SKU, UPC, product names, brand names, or the like) into a search feature and thereafter into the blocked/approved list after each is found through the search feature. As illustrated in the product search section 630 of
In some embodiments of the invention the primary user can add a range of product codes to the blocked/approved list, such that the dependent user does not need to add every individual product code to the blocked/approved list, as described with respect to the merchant limits above.
As discussed briefly above and illustrated by block 210 in
Moreover, the time limit may be set over a period of time as a percentage of the overall account limit for a specific period of time. For example, the account limit on books may be set by the primary user at five-hundred (500) dollars. Thereafter, the primary user can set a limit that the dependent user can spend one-hundred (100) percent of the account limit in September, fifty (50) percent of the account limit in October, and zero (0) percent the rest of the year. This allows the primary user to set a changing limit over a span of time to cover the approximate time periods in which the dependent user is likely going to enter into the transactions.
As illustrated by block 212 of
The transaction type limit section 710 may include a selection feature 712 that allows the primary user to set the transaction type limit on all purchases, all merchants, specific merchants, all products, specific products, or the like for the blocked/approved list in the dependent account. As illustrated in one example in
The location limit section 730, like the transaction type limits section 710, may include a selection feature 732 to allow the primary user to indicate to what transactions the location limit may apply (e.g., all transactions, merchants, products, or the like). As illustrated in the selection feature 732 of
As illustrated by block 216 the primary user may also set variance limits on the other limits set on the dependent account. As with the transaction type limit section 710 and the location limit section 730, the primary user may utilize a selection feature to indicate to what transactions the variance limit may apply (e.g., all transactions, merchants, products, or the like). As illustrated by the variance limit section 750 the primary user may set the variance limits as a percentage, an increased amount, or the like. For example, as illustrated in
In some embodiments of the invention the limit interface 700 can be populated by the primary user using drag and drop features in order to set the limits in the limit interface 700.
In some embodiments of the invention, instead of creating limits that either block/approve transactions made by dependent users, other limits can be applied to merchants or products that serve simply as notification limits instead of denial/acceptance limits. Therefore, in some embodiments, the primary user allows the dependent user to make various types of transactions at stores or for products, but sets notification limits in order to be notified when the dependent user enters into transactions. In these embodiments, the primary user can track the transactions made by the dependent user without having to limit the types of transactions made by the dependent user.
In still other embodiments of the invention other identifiers can be used in place of or in conjunction with the merchant identifiers or product identifiers. For example 2D barcodes, Quick Response codes (“QD codes”), RFID tags, or the like that are assigned to products could be added to a blocked/approved list of merchants or products in the dependent account. Therefore, products that the dependent user tries to purchase at a merchant, which use these product identifiers may be checked by the dependent account application 27 against the blocked/approved list before the transaction is approved.
As illustrated by block 218 in
In one example, when the merchant system 7 makes the request to connect to the dependent account system 20, or sometime thereafter, identifier information about the merchant and/or product involved in the transaction, such as but not limited to MCCs, store names, store addresses, store types, UPCs, product names, product types, or other like transaction information (e.g., price, transaction type, transaction location, or the like) are received by the dependent account system 20. The dependent account application 27 utilizes the transaction information to determine if the transaction has been blocked/approved by the primary user. If the merchant and/or products involved in the transaction are not on the blocked list (or are on the approved list), then the other limits on the dependent account are identified. The dependent account application 27 determines if the merchant and/or product are subject to any transaction amount limits, such as but not limited to an amount that the dependent user cannot exceed when making a purchase at the merchant and/or for the product. If the purchase being made by the dependent user is not within the transaction amount limit then the transaction is denied by the dependent account application 27. If however, the purchase is within the transaction amount limit then the dependent account application 27 determines if the purchase is within the transaction time limits set by the primary user. For example, the purchase could be within the transaction amount limits for a one-time purchase, but the purchase could push the dependent user over the limit for the number of purchases made within a month and/or the total amount of all the purchases made within the month. If the purchase being made by the dependent user is not within the transaction time limits then the transaction is denied. If however, the purchase being made by the dependent user is within the transaction time limits then the transaction is allowed to proceed. The other limits related to the transaction type limit, location limit, variance limit, or other like limits are also checked to determine if the transactions will be allowed or denied, or if a notification should be sent to the primary user regarding the transaction.
In some embodiments, as illustrated by block 222 in
At any time during the use of the dependent account (e.g., credit card) the primary user or dependent user can log into their online banking account to view the transactions made using the dependent account. In some embodiments, the dependent user has a separate online banking account, login name, and password from the primary user. This allows the dependent user to view any transactions using the dependent account, but prevents the dependent user from being able to make changes to the limits on the blocked/approved lists of merchants, products, or other like limits.
In some embodiments, the primary user can also make purchases with the dependent credit card. In one embodiment, the primary user and dependent user both have different account numbers that are linked to the dependent account. In other embodiments, the primary user and dependent user have the same account number, but have identifiers that distinguish them from each other when making purchases. In other embodiments, the primary user does not have an account linked to the dependent account, and thus even though the primary user has control over the account the primary user cannot make purchases using the account. As illustrated in
In the case where the dependent account is a dependent debit account (e.g., debit card), the settlement process would work differently than as described for a dependent credit card. Instead of carrying a balance on the dependent credit card as illustrated in
In other embodiments of the invention, the primary user and/or the dependent user can request to be notified when a particular limit is close to being reached or has been reached. For example, in some embodiments the primary user or dependent user can request a notification from the dependent account when the dependent user has reached a percentage of a transaction amount limit, such as 80 percent of the funds that can be spent at grocery stores. This feature allows the primary user and/or the dependent user to be aware of the spending of the dependent user. As such, the primary user may change the limits if necessary, add variance limits for a period of time to the limits, and/or allow the dependent user to control his spending or request that the primary user change the limits. These features also allow the primary user and the dependent user to pay down certain limits or change the variance on the limits before they reach the maximum limit in order to prevent additional transactions from being denied. In some embodiments the primary user can set notification alerts in order to be notified when the dependent user makes a transaction at a store or for a product, type of store or product, range of stores or products, or the like, in order to make payments on the transactions before the end of the billing cycle. In some embodiments, the primary user may want to pay off some transactions immediately or sometime before the end of the billing cycle, therefore the notification alerts allow the primary user to payoff certain transactions made by the dependent user. Furthermore, in some embodiments the primary user can link the dependent account to another account and set up automatic payments to occur at various times for various transactions made by the dependent user.
The primary user can at any time log into the dependent account (e.g., through an online banking account) and edit the limits set on the dependent credit card. For example, if the primary user originally set a limit of five hundred (500) dollars at the campus bookstore so the dependent user could buy books for classes, the primary user can change the limit to zero (0) dollars after the dependent user has purchased the books, in order to prevent the dependent user from making purchases at the campus bookstore for other products, such as clothing or other supplies. When the primary user first sets up the limits on the dependent credit card and/or at any point thereafter when the primary user changes the limits on the dependent credit card a notification can be sent to the dependent user identifying the limits that were set or changed by the primary user. In some embodiments the dependent user can be notified of any limits set or changed by the primary user through text message, e-mail, telephone call, or any other like communication channel.
In the embodiments where there is more than one dependent user under the account of the primary user, each dependent user may have their own limit interfaces 500, 600, 700 and transaction history interfaces 800. The separate interfaces for each dependent user allows the primary user to better manage each account because the primary user can set limits and view the transaction history of each dependent user individually based on the needs of each of the individual dependent users.
Regardless of whether or not the transactions using the dependent account were approved or denied, in some embodiments the transactions are posted and saved to the transaction history interface 800, in order to allow the dependent user, and more importantly, the primary user to see the purchases that the dependent user tried to make using the dependent account.
In some embodiments of the invention, a primary user can utilize a mobile device, which includes a data capture system, to set limits on stores directly at the store location. In one embodiment, the primary user can utilize the mobile device, having a data capture system comprising a data capture device and a data capture application, such as but not limited to a GPS device and application, a scanning device and application, an image capture device and application, and/or a wireless transmitter device and application. For example, in one embodiment, if the primary user is in a location, such as a store, restaurant, or the like, which the primary user would like to add to the list of blocked/approved merchants, the primary user can use the mobile device to add the store to the blocked/approved list. In some embodiments, the primary user can log into his dependent account through the online banking application 17 using a mobile device, such as but not limited to a smartphone. The mobile device may have a GPS device and an application that can determine the location of the primary user. Therefore, while the primary user is logged into the dependent account the primary user can select a function in the dependent account that adds the primary user's current location to a blocked/approved list. The dependent account application 27 may add the store automatically or it may display the location to the customer on the mobile device for the primary user's approval. The dependent account application 27 can save the store identified by the GPS application to the list of blocked/approved stores. In other embodiments, instead of using GPS to identify the store location, the primary user can take an image of the store, store name, address, or other identifier, and an image capture application can use the image or data captured in the image to identify the store by cross-referencing the image or data of the store with information stored by the bank or other entities over the network 2. When the image capture application identifies the store the dependent account application 27 can add the store to the blocked/approved list automatically or it may display the store on the mobile device for the primary user's approval. In still other embodiments of the invention the primary user can use a wireless transmitter device and wireless transmitter application in the mobile device to capture information about a store indentifying the store by type, name, address, or the like in order to add the store to the a list of blocked/approved stores in the dependent account. The wireless transmitter device can receive information about a store from a transmitter, such as but not limited to a RFID tag, located at the store. When the wireless transmitter application identifies the store the dependent credit application 27 can add the store to the blocked/approved list automatically or it may display the store on the mobile device for the primary user's approval to add the store to the blocked/approved list of stores. In still other embodiments of the invention the primary user can scan a barcode, or other identifier, using a scanning device and a scanning application in the mobile phone, to identify the store location. The dependent account application 27 can utilize the scanned information to add the store to the list of blocked/approved stores.
In some embodiments of the invention, a primary user can utilize a mobile device, which includes a data capture device, to set limits on products located directly at the store or at any other location, as previously described with respect to adding merchant limits. For example, in one embodiment, the primary user can identify a product that the primary user would like to add to the blocked/approved list. The primary user can log into his dependent account through an online banking application 17 using a mobile device, such as but not limited to a smartphone. As such, while the primary user is logged into his dependent account the primary user can select a function in the dependent account that adds a product to the blocked/approved list of products using a scanning device. Thereafter, the primary user can use a scanning device and scanning application in the mobile device to capture information on the product, associated packaging, or associated marketing materials identifying the product by name, SKU, UPC, or other identifier in order to add the product to a list of blocked/approved products in the dependent account. For example, in one embodiment the scanning device can be a laser scanner that captures the barcode UPC of the product and adds the product to the blocked/approved list of products. The dependent account application 27 may add the product automatically or it may display the scanned product to the primary user on the mobile device for the primary user's approval to add it to the blocked/approved list. In other embodiments of the invention, while the primary user is logged into his dependent account the primary user can select a function in the dependent account that adds a product to the blocked/approved list of products using an image capture device. Thereafter, the primary user can use an image capture device and image capture application in the mobile device to capture information on the product, associated packaging, or associated marketing materials identifying the product by name, SKU, UPC, or other identifier in order to add the product to the a list of blocked/approved products in the dependent account. The image capture application can use an image or data obtained from the image, through character recognition software or other software, for cross-referencing with images or data of products stored by the bank or other entities over the network 2. When the image capture application identifies the product related to the image captured by the primary user the dependent account application 27 can add the product to the blocked/approved list automatically or it may display the product on the mobile device for the primary user's approval to add the product to the blocked/approved list of products. In still other embodiments of the invention the primary user can use a wireless transmitter device and wireless transmitter application in the mobile device to capture information on a product, associated packaging, or associated marketing materials indentifying the product by name, SKU, UPC, or other product identifier in order to add the product to the a list of blocked/approved products in the dependent account. The wireless transmitter device can receive information about a product from a transmitter, such as but not limited to a RFID tag on or near the product. When the wireless transmitter application identifies the product the dependent credit application 27 can add the product to the blocked/approved list automatically or it may display the product on the mobile device for the primary user's approval to add the product to the blocked/approved list of products.
Furthermore, in other embodiments of the invention the primary user can also set other limits on the merchants or products added to the blocked/approved list using the mobile device, such as but not limited to transaction account limits, transaction time limits, or the like, as previously explained herein.
In other embodiments of the invention the dependent user can utilize a mobile device, which includes a data capture device and a data capture application, to check to see if limits have been applied by the primary user on a merchant at which the dependent user is located or on a product in which the dependent user is interested. This embodiment can work in the same or similar way as described with respect to the primary user setting limits on merchants and products using a mobile device herein. For example, the dependent user can utilize a mobile device, having a data capture system comprising a data capture device and data capture application, such as but not limited to a GPS device and application, a scanning device and application, an image capture device and application, and/or a wireless transmitter device and application. The dependent user can use the data capture device and application to capture information about a store, such as the store MCC, store type, name, address, or other like merchant identifier, and/or information about a product, such as but not limited to UPC, product name, product type, other product identifier, or the like, and use the information to determine if the primary user placed any limits on the dependent account for the merchant or product, or any other type of limit. In some embodiments, the dependent user can log into his dependent account through the online banking application 17 using a mobile device, such as but not limited to a smartphone. The data capture device and application captures the information about the merchant and product, as previously discussed, and the dependent account application 27 determines if the store or product is on the blocked/approved list of merchants and products. Thereafter, the dependent account application 27 can display to the dependent user any limits on the merchant or product through the dependent account on the mobile device. In this way the dependent user can check if a transaction would be allowed at the store or on the product before making an effort to purchase a product.
In other embodiments of the invention, instead of having to be logged into the dependent account in order for the dependent account application 27 to display to the user 9 on the mobile device if the merchant or product is on the blocked/approved list, the system can work in other ways. For example, after the data capture device captures information about the merchant or product on the mobile device, the mobile device can send the information to the dependent account application 27, and the dependent account application 27 thereafter can send any information regarding limits on the merchant or product to the user 9 on the mobile device using text messages, e-mail, phone calls, or the like.
In some embodiments, when a transaction is being made at the checkout of a store, at a physical store location, or on the user computer system 20, the dependent account application 27 can display the limits, such as the transaction amount limit, the transaction time limit, or the like, as the limits would be if the customer were to make the transaction or not make the transaction. In this way, the dependent user can determine if a transaction that the he wants to make would be approved or if the transaction may prevent other transactions from being made in the future because the dependent user could potentially violate other limits set by the primary user.
In other embodiments, if the proposed transaction being made or inquired by the customer is denied, the dependent user can have the option of notifying the primary user asking to lift the limit on the transaction. The notification can come through text message, e-mail, phone call, through the dependent account, or the like. Thereafter, the primary user can change the limit permanently, override the limit as a one time exception, or keep the limit the same. An override function allows the primary user to allow the dependent user to enter into certain transactions (e.g., in times of need, emergency situations, or the like) that ordinarily would not be allowed. This feature can be implemented through many different types of payment scenarios. For example, in some embodiments the feature could be used if the dependent user is making a purchase at store checkout, in which the purchase would be denied because it violated a limit. The dependent account application 27 could notify the primary user before the transaction is denied, to allow the primary user to override the limit as a one time exception. In other embodiments, the dependent user could notify the primary user through the online banking application that he wants to make a purchase that he knows will be denied in order to get approval for the transaction before the dependent user tries to make the purchase. For example, the dependent user could notify the primary user of a purchase on a product through the mobile device and the primary user could respond by allowing the transaction. Thereafter, the dependent account application 27 would allow the one time transaction that does not meet the limits set in the dependent account based on the override provided by the primary user.
In some embodiments of the invention, a reward system can be implemented for the dependent account. In addition to limits set by the primary user, the primary user may want to set spending goals that are lower than the limits in order to control the customer's spending, but leave enough credit available for the dependent user in case there is an emergency situation. For example, the primary user may set a limit of five-hundred (500) dollars at the bookstore in case the dependent user needs supplies from the bookstore; however, the primary user only wants the dependent user to spend three-hundred (300) dollars. In some embodiments the primary user can set of goal of three-hundred (300) dollars and a limit of five-hundred (500) dollars on the bookstore. If the dependent user spends less than the goal for the specified time limit then the limit on another store or product can be removed, or increased. For example, the dependent user can now spend one-hundred (100) dollars at an electronics store. Alternatively, if the dependent user spends more than the goal then the limit on another store or product can be set or decreased. For example, the dependent user can no longer make purchases at movie theaters.
In the embodiments described throughout this specification, the online banking application 17 allows a user 9, either the primary user or the dependent user, to access and review the dependent account. In the case of a primary user, the user 9 can access the account, review the transaction history, edit the account limit, edit the merchants or products on the blocked/approved list, or edit other limits. In the case of a dependent user, the user 9 can access the account, review the transaction history, view the account limit, view the transaction account limits on merchants, products, or other limits through the privacy and security offered by the online banking application 17.
As illustrated by block 256 in
As illustrated by block 258, the primary user may also set an allocation limit for the transaction amount limit in block 256. The allocation limit may limit the amount of a transaction that can be applied to a particular dependent account. For example, continuing with the example provided for block 256, while there may be a $300 transaction amount limit for “Store 1”, the primary user may only want to apply a portion of the $300 transaction amount limit using a first dependent account. As such, the allocation limit may only be $200 for transactions with Store 1. As such, while the primary user allows the dependent user to make a purchases up to $300 at “Store 1” (e.g., electronics store), the primary user only wants to allow the dependent user to apply $200 from the transaction to the dependent account. In this way, the primary user can allow the dependent user to enter into transactions and pay a portion of the transactions, but may also limit the total amount of the transactions applied to the dependent account. In continuing with the example, the primary user may also set a limit for a specific product or products that may be purchased by the dependent user regardless of the store. For example, “Product 1” (e.g., TV) may have a transaction amount limit of $200; however, the allocation limit may only allow $150 of the purchase of “Product 1” to be allocated to the dependent account.
As illustrated by block 260 in
As illustrated by block 262 of
As illustrated by block 274 when the transaction is allowed a determination is made if the allocation limit is met or violated. As such, the transaction amount is compared to the allocation limit, and if it is below or equals the allocation limit the transaction amount is applied to the dependent account, as illustrated by block 276. However, when the allocation limit is not met a payment deficiency is determined related to the difference between the transaction amount and the allocation limit, as illustrated by block 278 of
When the allocation limit is violated the transaction may be handled at the point of sale, or otherwise may be handled on the back end by the financial institution. For example, at the merchant (e.g., at a physical store, or online through a website or application) when the transaction is allowed, but the allocation limit is not met only a portion of the transaction up to the allocation limit is charged to the dependent account and the remainder of the transaction amount is requested by the merchant at the time of the sale. As such, the dependent user entering the transaction may be required to complete the payment by providing another form of payment other than the dependent account. For example, the dependent user may pay the remaining transaction amount by paying cash, using a gift card, using another account (e.g., credit card, debit card, or the like) or using another dependent account or another account of another user associated with the dependent user. As such, in this embodiment the payment is completed by the merchant up front and the two or more accounts or payments are assessed by the merchant.
In other embodiments of the invention when the transaction amount is met but the allocation limit is not met the transaction may be allowed by the financial institution. The financial institution may pay the full amount of the transaction, and debit the one or more dependent accounts and/or alternate accounts at the time of the purchase or at a later point in time. For example, at the time of the transaction the financial institution may pay the full amount of the transaction using the dependent account, and thereafter charge the transaction amount over the allocation limit to another account that the dependent customer has preauthorized (e.g., an alternate account for payments may be stored for the dependent account), or the financial institution may prompt the dependent user for an alternate account from which to assess the amount of the transaction over the allocation limit.
In one example, the dependent user may purchase “Product 1” and other products from “Store 1.” Based on the dependent account limits the dependent user can purchase up to $300 at “Store 1,” including “Product 1” up to $200, however only $150 of “Product 1” is allocated to the dependent account. As such, in one embodiment when “Product 1” is purchased from “Store 1” the transaction is allowed and the dependent account is debited $150 up to the allocation limit and “Store 1” requires that the dependent user provide an additional payment for the remaining $50. In other embodiments when “Product 1” is purchased from “Store 1” the transaction is allowed by the financial institution and the dependent account is debited $150 up to the allocation limit, while another alternate account that has been preauthorized by the dependent user or the primary user is debited for the remaining $50. In still other embodiments, when “Product 1” is purchased from “Store 1” the transaction is allowed by the financial institution and the dependent account is debited $200 up to the transaction amount, and the financial institution either prompts the user with a notification asking the dependent user from which account the $50 over the allocation limit should be debited. Transactions may occur at the merchant side or at the financial institution side in a number of different ways that have been generally discussed herein, or otherwise not specifically discussed herein, but which should be understood by one of ordinary skill in the art.
The network 2 may be a global area network (GAN), such as the Internet, a wide area network (WAN), a local area network (LAN), or any other type of network or combination of networks. The network 2 may provide for wireline, wireless, or a combination of wireline and wireless communication between devices on the network.
As illustrated in
The processing device 14 is operatively coupled to the communication device 12 and the memory device 16. The processing device 14 uses the communication device 12 to communicate with the network 2 and other devices on the network 2, such as, but not limited to, the dependent account system 20, other bank systems 5, merchant systems 7, and user computer systems 30. As such, the communication device 12 generally comprises a modem, server, or other device for communicating with other devices on the network 2.
As further illustrated in
As further illustrated in
As illustrated in
As further illustrated in
As illustrated in
The other bank systems 5 are operatively coupled to the online banking system 10, dependent account system 20, merchant systems 7, and user computer systems 30 through the network 2. The other bank systems 5 have devices the same or similar to the devices described for the online banking system 10, dependent account system 20, and user computer systems 30 (i.e. communication device, processing device, memory device with computer-readable instructions, datastore, or the like). Thus, the other bank systems 5 communicate with the online banking system 10, dependent credit system 20, merchant systems 7, and/or user computer systems 30 in the same or similar way as previously described with respect to each system. The other bank systems 5, in some embodiments, are comprised of systems and devices that store and access account information or other information within or outside of the bank.
The merchant systems 7 are operatively coupled to the online banking systems 10, dependent account systems 20, user computer systems 30, and other bank systems 5 through the network 2. The merchant systems 7 have devices the same or similar to the devices described for the online banking system 10, dependent credit system 20, and user computer systems 30 (i.e. communication device, processing device, memory device with computer-readable instructions, datastore, or the like). Thus, the merchant systems 7 communicate with the online banking system 10, dependent credit system 20, user computer systems 30, and/or other bank systems 5 in the same or similar way as previously described with respect to each system. The merchant systems 7 can be computer systems that incorporate scanners, manual input devices, or other data reading devices that can read and capture information embedded in credit cards or other payment devices through magnetic strips, radio frequency identification tags, other wireless transmitters, other scanable features, manually inputted information, or the like. In other embodiments of invention the merchant systems 7 include applications that allow purchases to occur over the network 2.
The information captured by the merchant systems 7 from the accounts and payment devices allows the merchant systems 7 to charge the accounts of the user 9. For example, the merchant systems 7 can be registers located in a store, Internet websites that are accessed by the user computer systems 30 remotely, or the like, which allow the users 9 to make purchases from the merchant using the dependent account, and/or other alternate accounts. Information related to the dependent account is captured at the store, on the website, or through an application, and transferred to the dependent account system 20.
It is understood that the systems and devices described herein illustrate one embodiment of the invention. It is further understood that one or more of the systems, devices, or the like can be combined in other embodiments and still function in the same or similar way as the embodiments described herein.
Any suitable computer-usable or computer-readable medium may be utilized. The computer usable or computer readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires; a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), or other tangible optical or magnetic storage device.
Computer program code/computer-readable instructions for carrying out operations of embodiments of the present invention may be written in an object oriented, scripted or unscripted programming language such as Java, Pearl, Smalltalk, C++ or the like. However, the computer program code/computer-readable instructions for carrying out operations of the invention may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages.
Embodiments of the present invention described above, with reference to flowchart illustrations and/or block diagrams of methods or apparatuses (the term “apparatus” including systems and computer program products), will be understood to include that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a particular machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create mechanisms for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions, which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. Alternatively, computer program implemented steps or acts may be combined with operator or human implemented steps or acts in order to carry out an embodiment of the invention.
U.S. patent application Ser. No. ______ to Schwalb, entitled “Purchase Limits with Primary Account Holder Control,” and filed concurrently herewith, is hereby incorporated by reference in its entirety.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations, modifications, and combinations of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.