According to some embodiments, a transaction processing system for evaluating transactions between a customer and a merchant comprises a transaction tracker, an account selection engine, and a performance module. The transaction tracker is operable to identify a transaction executed by a customer using a transaction device, the transaction device being operable to execute a transaction with a point of sale receiver associated with the merchant by providing an account number for a first account of the plurality of accounts. The account selection engine is operable to receive information identifying at least one characteristic of the transaction and select a recommended account based on the at least one characteristic. The performance module is operable to compare the first account with the recommended account to determine whether the customer would have received a financial benefit by executing the transaction using the recommended account instead of the first account.
|
6. A system comprising:
a memory that stores information identifying:
a transaction executed by a customer using a transaction device, the customer being associated with a plurality of accounts, the transaction device executes a transaction with a point of sale receiver associated with the merchant by providing an account number for a first account of the plurality of accounts; and
a merchant name, a merchant category, a product name, a product category, and an amount of the transaction; and
a processor coupled to the memory, the memory including executable instructions that upon execution cause the system to:
determine a plurality of selection rules associated with the customer;
determine user criteria selected by the customer, the user criteria comprising one or more weights of the plurality of selection rules;
select a recommended account based on the merchant name, the merchant category, the product name, the product category, the amount of the transaction, the selection rules, and the user criteria;
compare the first account with the recommended account;
based on the comparison of the first account with the recommended account, determine that the recommended account is the same as the first account used for the transaction;
determine that enabling a rewards program associated with the first account provides the customer with a financial benefit;
based on the determination that enabling the rewards program associated with the first account provides the customer with the financial benefit, propose enabling the rewards program associated with the first account;
compare the user criteria selected by the customer and default criteria; and
based on comparing the user criteria selected by the customer and default criteria, propose changing the user criteria.
1. A transaction processing system for evaluating transactions between a customer and a merchant, the customer being associated with a plurality of accounts, the system comprising:
a transaction tracker that identifies a transaction executed by a customer using a transaction device, the transaction device being operable to execute a transaction with a point of sale receiver associated with the merchant by providing an account number for a first account of the plurality of accounts;
an account selection engine that:
receives information identifying a merchant name, a merchant category, a product name, a product category, and an amount of the transaction;
determines a plurality of selection rules associated with the customer;
determines user criteria selected by the customer, the user criteria comprising one or more weights of the plurality of selection rules; and
selects a recommended account based on the merchant name, the merchant category, the product name, the product category, the amount of the transaction, the selection rules, and the user criteria; and
a performance module that:
compares the first account with the recommended account;
based on the comparison of the first account with the recommended account, determines that the recommended account is the same as the first account used for the transaction;
determines that enabling a rewards program associated with the first account provides the customer with a financial benefit;
based on the determination that enabling the rewards program associated with the first account provides the customer with the financial benefit, proposes enabling the rewards program associated with the first account;
compares the user criteria selected by the customer and default criteria; and
based on comparing the user criteria selected by the customer and default criteria, proposes changing the user criteria.
10. A computerized method for evaluating transactions between a customer and a merchant, the customer being associated with a plurality of accounts, the method comprising:
identifying, by a processor, a transaction executed by a customer using a transaction device, the transaction device being operable to execute a transaction with a point of sale receiver associated with the merchant by providing an account number for a first account of the plurality of accounts;
identifying, by the processor, a merchant name, a merchant category, a product name, a product category, and an amount of the transaction;
determining, by the processor, a plurality of selection rules associated with the customer;
determining, by the processor, user criteria selected by the customer, the user criteria comprising one or more weights of the plurality of selection rules;
selecting, by the processor, a recommended account based on the merchant name, the merchant category, the product name, the product category, the amount of the transaction, the selection rules, and the user criteria;
comparing the first account with the recommended account;
based on the comparison of the first account with the recommended account, determining, by the processor, that the recommended account is the same as the first account used for transaction;
determining, by the processor, that enabling a rewards program associated with the first account provides the customer with a financial benefit;
based on the determination that enabling the rewards program associated with the first account provides the customer with the financial benefit, proposing, by the processor, enabling the rewards program associated with the first account;
comparing, by the processor, the user criteria selected by the customer and default criteria; and
based on comparing the user criteria selected by the customer and default criteria, proposing, by the processor, changing the user criteria.
2. The transaction processing system of
3. The transaction processing system of
4. The transaction processing system of
5. The transaction processing system of
receives a plurality of account statuses of the customer for the plurality of accounts; and
selects the recommended account by comparing the plurality of account statuses with the plurality of account requirements, the plurality of account requirements comprising at least one of the following requirements: minimum account balance, maximum account balance, and amount of time between the time of the transaction and a time payment is due.
7. The system of
8. The system of
9. The system of
11. The computerized method of
12. The computerized method of
13. The computerized method of
14. The computerized method of
receiving, by an interface, a plurality of account statuses of the customer for the plurality of accounts; and
selecting, by the processor, the recommended account by comparing the plurality of account statuses with the plurality of account requirements, the plurality of account requirements comprising at least one of the following requirements: minimum account balance, maximum account balance, and amount of time between the time of the transaction and a time payment is due.
15. The transaction processing system of
16. The system of
17. The computerized method of
|
|||||||||||||||||||||||||||
The present disclosure relates to transactions between merchants and customers and, more specifically, to transaction devices and processing systems.
A merchant is a provider of goods or services. Merchants may provide goods or services to customers or to other merchants. A retailer is a merchant that provides goods or services to customers. A wholesaler is a merchant that provides goods or services to other merchants. A merchant execute transactions with customers or other merchants at a facility with point-of-sale equipment.
According to some embodiments, a transaction processing system for evaluating transactions between a customer and a merchant comprises a transaction tracker, an account selection engine, and a performance module. The transaction tracker is operable to identify a transaction executed by a customer using a transaction device, the transaction device being operable to execute a transaction with a point of sale receiver associated with the merchant by providing an account number for a first account of the plurality of accounts. The account selection engine is operable to receive information identifying at least one characteristic of the transaction and select a recommended account based on the at least one characteristic. The performance module is operable to compare the first account with the recommended account to determine whether the customer would have received a financial benefit by executing the transaction using the recommended account instead of the first account.
Certain embodiments of the invention may provide one or more technical advantages. A technical advantage of one embodiment may include the capability to reduce security risks associated with transactions with a merchant. A technical advantage of one embodiment may include the capability to generate a temporary-use number that limits a criminal's opportunity to execute transactions against an account without the account holder's authorization. A technical advantage of one embodiment may include the capability to provide a single transaction device with the ability to execute transactions from multiple accounts. A technical advantage of one embodiment may include the capability to select an account number from among multiple accounts for use in a transaction. A technical advantage of one embodiment may include the capability to evaluate transactions between a customer and a merchant.
Various embodiments of the invention may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.
For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:
It should be understood at the outset that, although example implementations of embodiments of the invention are illustrated below, the present invention may be implemented using any number of techniques, whether currently known or not. The present invention should in no way be limited to the example implementations, drawings, and techniques illustrated below. Additionally, the drawings are not necessarily drawn to scale.
An enterprise may include any individual, business, or organization. One example of an enterprise may include a financial enterprise. A financial enterprise may include any individual, business, or organization that engages in financial activities, which may include, but are not limited to, banking and investment activities such as maintaining accounts (e.g., transaction accounts, savings accounts, credit accounts, investment accounts, insurance accounts, portfolios, etc.), receiving deposits, crediting accounts, debiting accounts, extending credit to account holders, purchasing securities, providing insurance, and supervising a client's portfolio.
A financial enterprise may provide a variety of financial products and services. Examples of financial products and services may include, but are not limited to, account services such as maintaining accounts, receiving deposits, crediting accounts, debiting accounts, extending credit, purchasing securities, providing insurance, and portfolio management. A financial enterprise may provide financial products and services to clients. For example, a financial enterprise may maintain an account for a client. Examples of an account may include, but are not limited to, a prepaid account, a checking account, a savings account, and a credit account (such as a credit card account). The client may perform a variety of activities using the account, including executing transactions, contributing funds to the account, withdrawing funds from the account, managing the account, and being responsible or liable for account transactions.
Another example of an enterprise may include a merchant. A merchant may provide goods and services to customers. The merchant and customer may be clients of the same or different financial enterprises. The customer may acquire goods and services by agreeing to a transaction with the merchant. Pursuant to this transaction, the customer may be obligated to transfer funds to the merchant. One or more financial enterprises may assist the merchant and customer with completing the transaction. For example, if the customer intends to use a credit card issued by the customer's financial enterprise, the customer may present the credit card to the merchant as part of a request to acquire goods or services. The merchant may submit the request to the merchant's financial enterprise, sometimes known as the “acquirer” or “acquiring bank.” The merchant's financial enterprise may send a request to the customer's financial enterprise, sometimes known as the “issuer” or “issuing bank,” to authorize the transaction. In this example, the customer's financial enterprise may provide an authorization code to the merchant's financial institution if valid credit is available, and the merchant's financial institution may authorize the merchant to complete the transaction. After the transaction is complete, the merchant may receive the funds from the customer's financial enterprise through the merchant's financial enterprise, and the customer's financial enterprise may receive reimbursement from the customer when the customer pays the credit card bill.
In this example, the customer selects a credit card and presents the credit card to the merchant. The customer may have additional credit cards issued by the same or different financial enterprises, as well as other accounts such as a checking account, a savings account, and a prepaid account. The customer may execute transactions from these accounts using items such as a card or a checkbook. In order for the customer to execute transactions using these different accounts, the customer may be required to carry an item such as a card or checkbook for each different account. Carrying multiple cards and/or checkbooks may force the customer to carry a thick wallet or a heavy purse. In addition, the customer may not have the necessary information available to make an informed decision on which card or checkbook to use. For example, the customer may not know the account balances and due dates associated with each account. Teachings of certain embodiments recognize that providing a single transaction device with the ability to recommend accounts and execute transactions using multiple accounts may improve the customer's shopping experience.
Each of the customer's accounts may have an account number. An account number may include any number (or other combination of characters) that may be used to identify an account during a transaction. Typical accounts have a single, permanent number that identifies the account. Returning to the previous credit card example, the credit card may include a credit card number that identifies the credit account associated with the credit card. In this example, the credit card number may be provided on the front of the card and encoded in a magnetic strip on the back of the card. If the customer wants to change the credit card number, the customer's financial enterprise may require the customer to open a new credit card account and/or request a new credit card.
Accounts having a single, permanent account number present potential security risks. If a criminal discovers the permanent account number, the criminal may be able to execute transactions against the account without the customer's authorization. Accordingly, teachings of certain embodiments recognize that obfuscating the permanent account number may reduce security risks. For example, a transaction device may generate an obfuscated account number associated with the permanent account number. This obfuscated account number be a temporary-use number that limits the criminal's opportunity to execute transactions against the account without the customer's authorization.
Transaction processing system 100 may be implemented on one or more computer systems 910 and may include and/or communicate across one or more networks 30. Computer systems 910 and networks 30 are described in greater detail below with regard to
Users 5 may include any individual, group of individuals, entity, machine, and/or mechanism that interacts with transaction processing system 100. Users 5 are described in greater detail below with regard to
Transaction device 110 is a device associated with a customer for executing transactions. Transaction device 110 enables the customer to provide financial information to a merchant as part of a transaction. In some embodiments, transaction device 110 is a handheld device, such as a spending card or a handheld electronic device. Examples of a handheld electronic device may include a digital assistant, such as a personal digital assistant or an enterprise digital assistant; a mobile phone, such as a smartphone or feature phone; a portable computer, such as a laptop computer or tablet device; a portable media player; a portable game console; a digital camera, such as a digital still camera or digital video camera; and a personal navigation device.
In the example of
One example of a POS interface 210 may include a data stripe. A data stripe may be operable to communicate transaction information to a data stripe reader. Data stripes may include magnetic stripes, such as those found on credit or debit cards, dynamic programmable stripes such as those found on dynamic cards, or any other storage medium operable to communicate account data to a data stripe reader. In one embodiment, a data strike may be enabled to communicate account data for one account to a data stripe reader. In other embodiments, a data stripe may communicate different account data for different transactions. For example, a data stripe may communicate account data associated with a plurality of accounts, such as one or more credit, debit, checking, savings, or other accounts. In some embodiments, the data stripe is a programmable data stripe, wherein the account data communicated by data stripe is dynamic and can be changed at any time.
Another example of a POS interface 210 may include a wireless transmitter. In this example, POS interface 210 may wirelessly transmit account information to POS receiver 142. POS interface 210 may transmit account information using any suitable communication technique, including, but not limited to, near-field communication, Bluetooth communication, radio-frequency identification (RFID) communication, wireless network communication (e.g., IEEE 802.11 communication), and cellular network communication. POS interface 210 may transmit account information across a network such as network 930 of
Another example of a POS interface 210 may include a barcode generator. In this example, POS interface 210 may generate a barcode readable by a bar code scanner. In some embodiments, POS interface 210 may be operable to display a unique barcode for different transactions. Each unique barcode may represent different account data, such as different account numbers. In some embodiments, account data communicated by the barcode generator may be dynamic and may be changed at any time.
In the example of
Some embodiments of transaction device 110, however, may not include a customer interface 114 such as a keypad or touchpad. For example, in one embodiment, account selection engine 170 may automatically select an account from a plurality of accounts without receiving a selection from the customer through the transaction device. As one example, the POS interface 210 may have near-field communication capability, and the customer may initiate a transaction by providing transaction device 110 near a merchant's near-field communication reader. In this example, transaction device 110 may provide an account number to the merchant without the customer inputting an account selection to the transaction device.
In the example of
The obfuscated account number may be provided to the merchant instead of the permanent account number. Teachings of certain embodiments recognize that obfuscating the permanent account number may reduce security risks. For example, a temporary-use number that limits the criminal's opportunity to execute transactions against the account without the customer's authorization. As one example, the obfuscated account number may be limited to a single transaction. In this example, a criminal working at the merchant's location may be unable to use the obfuscated account number for a second, unauthorized transaction.
In the example of
In
In some embodiments, obfuscation engine 120 may provide a obfuscated number in response to a request from transaction device 110. For example, transaction device 110 may request an obfuscated number when the customer engages in a transaction. In this example, transaction device 110 may transmit the request across a network such as network 930 of
In some circumstances however, transaction device 110 is not connected to obfuscation engine 120 across a network such as network 930 of
In some embodiments, obfuscated number generator 116 may generate obfuscated numbers based on state information. For example, obfuscated number generator 116 may generate obfuscated numbers unique to a particular period of time or time of day. As another example, obfuscated number generator 116 may generate obfuscated numbers unique to a particular transaction device 110. Teachings of certain embodiments recognize that generating obfuscated numbers based on state information may improve security.
In some embodiments, obfuscated number generator 116 may apply rules to prevent obfuscated number generating 116 from assigning the same obfuscated number to multiple permanent numbers, accounts, customers, and/or transaction devices. For example, obfuscated number generator 116 may apply rules such that each obfuscated number is unique to a particular permanent number, account, customer, and/or transaction device. Obfuscated number generator 116 may also consult a list of previously-assigned obfuscated numbers to determine whether the generated obfuscated number is unique. In some embodiments, a generated obfuscated number may become available to be reassigned once the obfuscated number has been used in a transaction.
In some embodiments, obfuscated number generator 116 generates obfuscated numbers by creating new combinations of numbers. In other embodiments, obfuscated number generator 116 generates obfuscated numbers by retrieving an obfuscated number from a list of available obfuscated numbers. For example, obfuscation engine 120 may be associated with an enterprise that owns a group of obfuscated numbers, such as a group of obfuscated credit card numbers. In this example, obfuscation engine 120 may select an obfuscated number from the group of obfuscated credit card numbers.
Obfuscation repository 130 stores obfuscation mapping data 132. Obfuscation mapping data 132 stores the relationship between obfuscated account numbers and permanent account numbers. For example, when obfuscated number generator 116 generates a new obfuscated account number, obfuscated number generator 116 informs obfuscation repository 130 of the relationship between the new obfuscated account number and the permanent account number. When the customer presents the obfuscated account number to the merchant, a party such as the merchant's bank may retrieve the associated permanent account number from the obfuscated mapping data 132.
Merchant 140 represents a provider of goods or services. In the example of
Authorization provider 150 provides authorization to merchant 140 to complete the transaction. In some circumstances, authorization provider 150 may be associated with a financial enterprise, such as the acquiring bank of merchant 140. In some embodiments, authorization provider 150 communicates with obfuscation repository 130 to identify the permanent account number for an obfuscated account number received by merchant 140. In some circumstances, authorization from authorization provider 150 confirms that authorization provider 150 will pay merchant 140 for the transaction executed with the customer.
Account manager 160 maintains accounts of the customer. In some circumstances, account manager 160 may be associated with a financial enterprise, such as the issuing bank of the customer. In the example embodiment, account manager 160 maintains three accounts 162, 164, and 166. Examples of accounts 162, 164, and 166 may include, but are not limited to, transaction accounts, savings accounts, credit accounts, investment accounts, and insurance accounts.
Account manager 160 may also provide approval of a transaction to authorization provider 150. In some embodiments, authorization provider 150 communicates with obfuscation repository 130 to identify the permanent account number for an obfuscated account number received by merchant 140. In some circumstances, approval from account manager 160 confirms that account manager 160 will pay authorization provider 150 for the transaction executed with the customer. Account manager 160 may provide this approval, for example, if account manager 160 determines that the selected account has sufficient funds or credit available.
Account selection engine 170 recommends an account to the customer for a transaction. In some embodiments, account selection engine 170 may receive information identifying characteristics of a proposed transaction from transaction device 110 and use this information to identify a recommended account. Examples of characteristics may include, but are not limited to, the customer, the merchant (e.g., merchant name, merchant category), the amount, the goods and/or services to be sold (e.g., product name, product category), and the day and/or time of the proposed transaction.
Account selection engine 170 may identify a recommended account based on the characteristics of the proposed transaction. Account selection engine 170 may, for example, compare the characteristics to selection criteria. Examples of selection criteria may include, but are not limited to, amount of rewards associated with using an account, amount of fees associated with an account, and amount of owed interest associated with an account, amount of earned interest associated with an account. Account selection 170 may also, for example, compare the characteristics to account statuses associated with each account. Examples of account statuses may include, but are not limited to, minimum account balance, maximum account balance, and amount of time between the time of the transaction and the time payment is due on the account.
In some embodiments, account selection engine 170 may identify a recommend account by applying selection rules 172. Selection rules 172 may identify which accounts should be recommended depending on various combinations of proposed-transaction characteristics, selection criteria, and account statuses. One example rule may state that a particular account is recommended for fuel purchases because that particular account offers 3% cash back on fuel purchases. Another example rule may state that a particular account is recommended for international purchases because that particular account offers reduced foreign transaction fees. Another example rule may state that a particular account is recommended because payment is not due for a long time from the time of the transaction. Another example rule may state not to use a particular account if the customer is reaching the maximum balance owed on that account. Another example rule may state to use a particular account if the customer is required to use the particular account a certain number of times in order to receive better services, such as better interest rates or better rewards. In some embodiments, account selection engine 170 may also consider administrative preferences, such as costs or benefits to the financial institution or the speed of payment clearance.
In some circumstances, multiple rules may result in a contradiction. For example, one rule may recommend a first account because of the first account's rewards program, but a second rule may recommend a second account because payment is due on the second account later than on the first account. Accordingly, teachings of certain embodiments recognize the capability to prioritize and/or weight rules to resolve conflicts. For example, account selection engine 170 may prioritize payment due dates over reward programs and therefore prioritize the second rule over the first rule.
In some embodiments, each rule may be placed in a category, and categories of rules may be prioritized over others. In one example, rule categories may include mandatory rules, preferential rules, and optimal rules. In this example, mandatory rules can never be broken, preferential rules should not be broken, and optimal rules should be applied when possible. An example of a mandatory rule might be that the customer cannot exceed the maximum balance on a particular account. An example of a preferential rule might be that lower-interest credit card accounts should be prioritized over higher-interest credit card accounts. An example of an optimal rule might be that airline rewards programs should be prioritized over cash-back rewards programs.
In some circumstances, rules, prioritizations, and weights may be unique to a particular customer or groups of customers. Returning to the previous example, account selection engine 170 may prioritize rewards programs over payment due dates if the customer is a mass affluent customer with available resources to meet shorter payment due dates. In this example, account selection engine 170 may determine that the customer is a mass affluent customer, for example, by reviewing the individual resources of the customer or by identifying the customer as having been previously classified as a mass affluent customer. Account selection engine 170 might apply a different prioritization, for example, if the customer was classified in a different category such as teenager or low-income.
In some circumstances, the customer may provide user criteria that instructs account selection engine 170 on how to apply rules. For example, the customer may instruct account selection engine 170 to prioritize rewards programs with airline travel bonuses if the customer is planning on taking a vacation. As another example, the customer may instruct account selection engine 170 to prioritize credit card interest rate over rewards programs.
In the example of
Management module 180 enables the customer or another user 5 to manage and evaluate various aspects of transaction processing system 100. In the example of
Transaction tracker 184 presents information regarding transactions of the customer, such as transaction amount, merchant, and goods and/or services sold. Performance interface 186 evaluates the customer's transactions to determine whether the customer would have received a financial benefit by using a different account than the one used during the transaction. For example, performance interface 186 may compare the account used in a transaction identified by transaction tracker 184 with an account recommended for the transaction by account selection engine 170. Performance interface 186 may inform the customer, for example, that using the recommended account may save the customer money.
In some embodiments, performance interface 186 may compare the account used in a transaction with accounts not currently held by the customer. For example, performance interface 186 may recommend new accounts that would have saved or earned the customer money had the customer used the account on previous transactions. As one example, performance interface 186 may recommend that the customer enroll for a new credit card with cash rewards on fuel purchases if the customer spent certain amounts of money on fuel purchases.
In some embodiments, performance interface 186 may compare the account used in a transaction with a changed version of the same account used in the transaction. For example, performance interface 186 may recommend that the customer change the account if the change would have saved or earned the customer money. As one example, performance interface 186 may recommend that the customer enable a rewards program on an existing account if the rewards program would have saved or earned the customer money.
In some embodiments, performance interface 186 may report evaluations of the customer's transactions on a transaction-by-transaction basis. In some embodiments, performance interface 186 may provide summaries of these evaluations, such as summaries of the customer's transactions over a certain period of time. In some embodiments, performance interface 186 may identify a list of proposed changes or additions, such as changes to the customer's accounts and/or selection rules 172. In these embodiments, performance interface 186 may also identify an amount of savings or earnings associated with each proposed change or addition. An example of performance interface 186 is described in greater detail with regard to
In some embodiments, performance interface 186 may evaluate the customer's user criteria. For example, performance interface 186 may compare performance using the customer's user criteria with default criteria and recommend changes to the customer's user criteria. As one example, the customer may believe that interest rate should be prioritized, but the customer may not be aware that the customer would earn more money by prioritizing rewards programs because the customer routinely pays off owed accounts before interest becomes due.
In operation, according to one example embodiment, transaction device 110 transmits a transaction proposal 10 to account selection engine 170. Transaction proposal 10 identifies characteristics of a proposed transaction. Examples of characteristics may include, but are not limited to, the customer, the merchant (e.g., merchant name, merchant category), the amount, the goods and/or services to be sold (e.g., product name, product category), and the day and/or time of the proposed transaction.
Account selection engine 170 provides an account recommendation 12 in response to transaction proposal 10. In some embodiments, account selection engine 170 may identify a recommend account by applying selection rules 172. Selection rules 172 may identify which accounts should be recommended depending on various combinations of proposed-transaction characteristics, selection criteria, and account statuses. In this example, account selection engine 170 recommends account 162.
An account may be selected for a transaction between transaction device 110 and merchant 140. In one example, the account identified by account recommendation 12 is automatically selected without input from the customer. In another example, transaction device 110 presents account recommendation 12 to the customer and allows the customer to either accept the account recommendation 12 or select an alternative account. In another example, transaction device 110 allows the customer to select an account without informing the customer of account recommendation 12. In this example, the recommended account 162 is also the selected account.
After account 162 is selected, transaction device 110 transmits obfuscation request 14 to obfuscated number generator 116. Obfuscation request 14 represents a request for an obfuscated account number for the selected account 162. Obfuscated number generator 116 provides an obfuscated account number 16. Obfuscated account number 16 is a temporary-use number associated with the selected account 162.
Transaction device 110 transmits obfuscated account number 16 and a transaction request 18 to merchant 140. Transaction request 18 represents a request to execute a transaction between the customer and merchant 140. For example, transaction request 18 may represent a request of the customer to acquire goods and/or services from merchant 140. In this example, transaction request 18 specifies that the customer will fund the requested transaction by providing funds from the selected account 162 associated with obfuscated account number 16.
In this example, merchant 140 transmits obfuscated account number 16 and an authorization request 20 to authorization provider 150. Authorization request 20 represents a request for authorization to execute the requested transaction. For example, authorization provider 150 may be associated with a financial enterprise, such as the acquiring bank of merchant 140. In this example, merchant 140 may seek authorization from authorization provider 150 because authorization provider 150 may be responsible for accepting payments for products or services on behalf of merchant 140. For example, an acquiring bank may accept credit and debit card payments on behalf of merchant 140.
Authorization module 150 may grant or deny authorization to merchant 140 depending on whether authorization module 150 expects that the customer will transfer funds from the selected account 162. Authorization module 150 may base this expectation on approval from account manager 160.
In this example, authorization provider 150 transmits obfuscated account number 16 and an account number request 22 to obfuscation repository 130. Account number request 22 represents a request to determine the permanent account number associated with obfuscated account number 16. Obfuscation repository 130 consults mapping data 132 to identify the account number 24 associated with obfuscated account number 16. In this example, account number 24 is the permanent account number of selected account 162. Obfuscation repository 130 transmits account number 24 to authorization provider 150.
Authorization provider 150 transmits account number 24 and an approval request 26 to account module 160. Approval request 26 represents a request to approve a transaction from selected account 162 on behalf of the customer. Account manager 160 may approve the transaction, for example, if account 162 has sufficient funds and/or credit available to complete the transaction. Account manager 160 may also require some level of authentication showing that the customer is in fact the holder of account 162. For example, account manager 160 may require authorization criteria, such as a passcode or verification from merchant 140 that the customer's identity matches the identity of the holder of account 162.
In this example, account manager 160 approves the transaction by transmitting an approval 28 to authorization module 150. Authorization module 150 then transmits authorization 30 to merchant 140 based on receipt of approval 28. Merchant 140 then executes the transaction with the customer. Merchant 140 may reconcile the transaction and receive funds from account 162 through authorization module 150 and account manager 160. For example, account manager 160 may provide funds from account 162 to authorization module 150, which then provides the funds to merchant 140.
In this example, customer interface 114 presents a recommended account field 222, an account selection field 224, and an execute transaction field 226 to user 5. Recommended account field 222 presents a recommended account for the customer. In some embodiments, recommended account field 222 may display the account recommended by account selection engine 170. Account selection field 224 provides an interface for receiving an account selection from user 5. In this example, account selection field 224 allows user 5 to select an account other than the recommended account shown in recommended account field 222. Execute transaction field 226 provides an interface for receiving instructions from user 5 to execute a transaction using the account selected in account selection field 224.
Another example of a POS interface 210 may include a wireless transmitter. In this example, POS interface 210 may wirelessly transmit account information to POS receiver 142. POS interface 210 may transmit account information using any suitable communication technique, including, but not limited to, near-field communication, Bluetooth communication, radio-frequency identification (RFID) communication, wireless network communication (e.g., IEEE 802.11 communication), and cellular network communication. POS interface 210 may transmit account information across a network such as network 930 of
The example mapping table 300 features four accounts 320, 322, 324, and 326. Account 320 is a credit card account, account 322 is a debit card account, account 326 is a checking account, and account 328 is a line-of-credit account. In this example, each account has both a permanent account number and an obfuscated account number. In some embodiments, accounts 320, 322, 324, and 326 may be maintained by account manager 160 of
User criteria interface 400 may allow user 5 to provide comparative weightings between various rules or other priorities. For example, interest rate criterion field 410 provides an input for user 5 to change the prioritization of interest rate when recommending an account. For example, prioritizing interest rate may instruct account selection engine 170 to prioritize those accounts with optimal interest rates. Payment deadlines field 420 provides an input for user 5 to change the prioritization of payment deadlines when recommending an account. For example, prioritizing payment deadlines may instruct account selection engine 170 to prioritize those accounts with later payment deadlines. Rewards points field 430 provides an input for user 5 to change the prioritization of rewards points when recommending an account. For example, prioritizing rewards points may instruct account selection engine 170 to prioritize those accounts that offer better rewards for a transaction. Maximum balance field 440 provides an input for user 5 to change the prioritization of maximum balance when recommending an account. For example, prioritizing maximum balance may instruct account selection engine 170 to prioritize those accounts that have outstanding balances lower than their required maximum balances. Minimum balance field 450 provides an input for user 5 to change the prioritization of minimum balance when recommending an account. For example, prioritizing minimum balance may instruct account selection engine 170 to prioritize those accounts with outstanding balances greater than their required minimum balances.
Amount field 510 identifies the amount actually spent by the customer during a transaction. Account field 520 identifies the account actually used by the customer during a transaction. Recommended account field 530 identifies the account recommended by account selection engine 170. In some circumstances, recommended account field 530 and account field 520 may identify the same account if the customer used the recommended account. In other circumstances, recommended account field 530 and account field 520 may identify different accounts if the customer did not use the recommended account. If the customer did not use the recommended account, potential savings field 540 identifies the savings the customer could have received by using the recommended account. In some embodiments, potential savings field 540 may identify the potential savings as a monetary value, a rewards points value, and/or a textual explanation of the potential savings.
Users 5 may include any individual, group of individuals, entity, machine, and/or mechanism that interacts with computer systems 910. Examples of users 5 include, but are not limited to, a teenager, parent, manager, executive, review board, accountant, engineer, technician, contractor, agent, and/or employee. Users 5 may be associated with an organization. An organization may include any social arrangement that pursues collective goals. One example of an organization is a family. Another example of an organization is a business. A business is an organization that provides goods or services, or both, to consumers, governmental entities, and/or other businesses.
Computer system 910 may include processors 912, input/output devices 914, communications links 916, and memory 918. In other embodiments, computer system 910 may include more, less, or other components. Computer system 910 may be operable to perform one or more operations of various embodiments. Although the embodiment shown provides one example of computer system 910 that may be used with other embodiments, such other embodiments may utilize computers other than computer system 910. Additionally, embodiments may also employ multiple computer systems 910 or other computers networked together in one or more public and/or private computer networks, such as one or more networks 30.
Processors 912 represent devices operable to execute logic contained within a medium. Examples of processor 912 include one or more microprocessors, one or more applications, and/or other logic. Computer system 910 may include one or multiple processors 912.
Input/output devices 914 may include any device or interface operable to enable communication between computer system 910 and external components, including communication with a user or another system. Example input/output devices 914 may include, but are not limited to, a mouse, keyboard, display, and printer.
Communication links 916 are operable to facilitate communication between computer system 910 and another element of a network, such as other computer systems 910. Communication links 916 may connect to any number and combination of wireline and/or wireless networks suitable for data transmission, including transmission of communications. Communication links 916 may, for example, communicate audio and/or video signals, messages, Internet Protocol packets, frame relay frames, asynchronous transfer mode cells, and/or other suitable data between network addresses. Communication links 916 connect to a computer network or a variety of other communicative platforms including, but not limited to, a public switched telephone network (PSTN); a public or private data network; one or more intranets; a local area network (LAN); a metropolitan area network (MAN); a wide area network (WAN); a wireline or wireless network; a local, regional, or global communication network; an optical network; a satellite network; a cellular network; an enterprise intranet; all or a portion of the Internet; other suitable network interfaces; or any combination of the preceding.
Memory 918 represents any suitable storage mechanism and may store any data for use by computer system 910. Memory 918 may comprise one or more tangible, computer-readable, and/or computer-executable storage medium. Examples of memory 918 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), database and/or network storage (for example, a server), and/or other computer-readable medium.
In some embodiments, memory 918 stores logic 920. Logic 920 facilitates operation of computer system 910. Logic 920 may include hardware, software, and/or other logic. Logic 920 may be encoded in one or more tangible, non-transitory media and may perform operations when executed by a computer. Logic 920 may include a computer program, software, computer executable instructions, and/or instructions capable of being executed by computer system 910. Example logic 920 may include any of the well-known OS2, UNIX, Mac-OS, Linux, and Windows Operating Systems or other operating systems. In particular embodiments, the operations of the embodiments may be performed by one or more computer readable media storing, embodied with, and/or encoded with a computer program and/or having a stored and/or an encoded computer program. Logic 920 may also be embedded within any other suitable medium without departing from the scope of the invention.
Various communications between computers 910 or components of computers 910 may occur across a network, such as network 930. Network 930 may represent any number and combination of wireline and/or wireless networks suitable for data transmission. Network 930 may, for example, communicate Internet Protocol packets, frame relay frames, asynchronous transfer mode cells, and/or other suitable data between network addresses. Network 930 may include a public or private data network; one or more intranets; a local area network (LAN); a metropolitan area network (MAN); a wide area network (WAN); a wireline or wireless network; a local, regional, or global communication network; an optical network; a satellite network; a cellular network; an enterprise intranet; all or a portion of the Internet; other suitable communication links; or any combination of the preceding. Although the illustrated embodiment shows one network 930, teachings of certain embodiments recognize that more or fewer networks may be used and that not all elements may communicate via a network. Teachings of certain embodiments also recognize that communications over a network is one example of a mechanism for communicating between parties, and any suitable mechanism may be used.
Modifications, additions, or omissions may be made to the systems and apparatuses described herein without departing from the scope of the invention. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order. Additionally, operations of the systems and apparatuses may be performed using any suitable logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.
Although several embodiments have been illustrated and described in detail, it will be recognized that substitutions and alterations are possible without departing from the spirit and scope of the present invention, as defined by the appended claims.
To aid the Patent Office, and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims to invoke paragraph 6 of 35 U.S.C. §112 as it exists on the date of filing hereof unless the words “means for” or “step for” are explicitly used in the particular claim.
Ronca, James G., Zanzot, Mark D., Griggs, Christopher R., Gibson, Lisa
| Patent | Priority | Assignee | Title |
| 10089646, | Apr 10 2012 | ALIASWIRE, INC | Systems, devices, and methods for managing a payment transaction |
| 10867344, | Dec 23 2019 | Futures Partners LLC | Systems and methods for commodity exchanges |
| 10922671, | Apr 10 2012 | ALIASWIRE, INC | Systems, devices, and methods for managing a payment transaction |
| 11328286, | Mar 15 2013 | CARDWARE, INC | Multi-function electronic payment card and device system |
| 11620634, | Mar 15 2013 | CARDWARE, INC | Multi-function smart tokenizing electronic payment device |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Sep 13 2011 | RONCA, JAMES G | Bank of America Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027148 | /0274 | |
| Sep 13 2011 | ZANZOT, MARK D | Bank of America Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027148 | /0274 | |
| Sep 13 2011 | GIBSON, LISA | Bank of America Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027148 | /0274 | |
| Sep 14 2011 | GRIGGS, CHRISTOPHER R | Bank of America Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027148 | /0274 | |
| Sep 23 2011 | Bank of America Corporation | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Feb 05 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Jan 21 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Date | Maintenance Schedule |
| Aug 11 2018 | 4 years fee payment window open |
| Feb 11 2019 | 6 months grace period start (w surcharge) |
| Aug 11 2019 | patent expiry (for year 4) |
| Aug 11 2021 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Aug 11 2022 | 8 years fee payment window open |
| Feb 11 2023 | 6 months grace period start (w surcharge) |
| Aug 11 2023 | patent expiry (for year 8) |
| Aug 11 2025 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Aug 11 2026 | 12 years fee payment window open |
| Feb 11 2027 | 6 months grace period start (w surcharge) |
| Aug 11 2027 | patent expiry (for year 12) |
| Aug 11 2029 | 2 years to revive unintentionally abandoned end. (for year 12) |