Patent Grant
11188887
Embodiments of the present disclosure relate generally to the field of data access management.
Many online transactions involve a customer providing the customer's payment information (e.g., a credit card number, expiration date, and Card Verification Value (“CVV”)) to a third party such as a merchant. The third party then uses the payment information provided by the customer to process a payment for the transaction. Additionally, in some cases, the third party stores the customer's payment information to be used in further online transactions.
One embodiment relates to a computer-implemented method performed by a computing system. The method includes gathering payment history data for a payment account, held by a customer with an accounts provider, by at least one of data mining the payment history data from a database associated with the accounts provider or screen scraping the payment history data, wherein the payment account is associated with payment information. The method also includes identifying a subset of the payment history data that relates to online payments, analyzing the subset of the payment history data to identify characteristics of the online payments made from the payment account, and, based on the characteristics, determining one or more third parties that are likely storing the payment information. The method further includes displaying a list of the one or more third parties to the customer.
Another embodiment relates to a system. The system includes a network interface, an accounts database configured to store account information, and one or more processors. The one or more processors are configured for gathering payment history data for a payment account, held by a customer, with an accounts provider, by at least one of data mining the payment history from a database associated with the accounts provider or screen scraping the payment history data, wherein the payment account is associated with payment information. The one or more processors are also configured for identifying a subset of the payment history data that relates to online payments, analyzing the subset of the payment history data to identify characteristics of the online payments made from the payment account, and, based on the characteristics, determining one or more third parties that are likely storing the payment information. The one or more processors are further configured for displaying a list of the one or more third parties to the customer.
Another embodiment relates to a computer-implemented method performed by a computing system. The method includes gathering payment history data for a payment account held by a customer with an accounts provider, by at least one of data mining the payment history data from a database associated with the accounts provider or screen scraping the payment history data, wherein the payment account is associated with payment information. The method also includes identifying a subset of the payment history data that relates to online payments, analyzing the subset of the payment history data to identify characteristics of the online payments made from the payment account, and, based on the characteristics, determining one or more third parties that are likely storing the payment information. The method also includes displaying a list of the one or more third parties to the customer. The method further includes receiving, from a third party, a payment request initiated by the customer, the payment request associated with a transaction between the customer and the third party, generating a one-time use token associated with the payment account, transmitting the one-time use token to the third party, and processing a payment from the payment account to the third party using the one-time use token.
Referring to the Figures generally, various, systems, methods, and apparatuses for payment information access management are described herein. More particularly, systems and methods are described for allowing a customer to view which third parties have the customer's payment information saved and further allowing a customer to (a) update payment information with third parties and/or (b) make future payments with third parties using a secure payment system provided by the customer's payment account(s) provider.
An example implementation is described as follows. A customer holds one or more payment accounts (e.g., a demand deposit account, a credit card account, etc.) with a payment accounts provider. The provider determines third parties that likely have saved payment information relating to the customer's account(s) based on payment history data for the customer that is stored by the provider. Additionally, in some arrangements, the provider interfaces with other sources of payment histories for the customer (e.g., an online profile for the customer showing the customer's payment history with a different accounts provider with which the customer holds another payment account, a peer-to-peer payment system with which the customer has an account, etc.), gathers additional payment history data for the customer, and further determines third parties that likely have saved payment information for the customer based on the additional payment history data. The provider then provides the customer with a list of the third parties that likely have saved payment information for the customer, for example, through a web-based graphical user interface.
According to various embodiments, the provider further offers functionalities to the customer such that the customer is able to manage access to the customer's payment information by third parties. In some embodiments, the provider provides the customer with an option to use a “secure payment service” offered by the provider for making payments to third parties enrolled in the secure payment service. To use the secure payment service, the customer selects an enrolled third party and indicates to the provider that the customer would like to use the secure payment service to make future payments, using one or more of the customer's payment accounts, to the selected third party. In response, the customer or the provider notifies the selected third party that the customer has opted to use the secure payment service for the third party. Subsequently, when the customer initiates a request for a payment to be made to the third party, rather than the customer providing the third party with the customer's payment information or the third party using saved payment information for the customer to process the payment, the third party indicates to the provider that the customer has requested a payment. The provider then provides a one-time use token associated with one of the customer's payment accounts to the third party. The third party and the provider use the token to process the payment from the customer's account.
Additionally, in some embodiments, the provider provides the customer with an option to update payment information that is stored with the various third parties. For example, if the customer loses a credit card associated with a credit card account held with the provider and the provider must change the customer's credit card account number, the customer has the option to send the updated credit card number to various third parties that the provider has determined are likely storing the customer's payment information. As another example, if the customer updates the customer's billing address with the provider, the customer has the option to send the updated billing address to the various third parties. In some arrangements, the provider only updates the customer's payment information with one or more third parties the provider has determined are likely storing the customer's payment information in response to a customer request. In other arrangements, the provider automatically updates the payment information with the various third parties.
Embodiments described herein solve several technical problems. For one, while various websites, applications, programs, etc. gather a customer's payment information for purposes of processing a payment from the customer, it can be difficult for the customer to know and remember which entities have the customer's payment information saved. The customer may need to know where the customer's payment information is saved, for example, for security reasons (e.g., if data storage for a third party the customer has made purchases from in the past is compromised, the customer needs to know if the entity had the customer's payment information saved so that the customer can take steps to prevent the payment information from being used for fraudulent purposes) or because the customer needs to update the customer's stored payment information (e.g., if the customer is reissued a credit card, the customer needs to update the expiration date and CVV that are stored by various third parties so that the customer can continue to make purchases using those third parties). Accordingly, the systems and methods described herein are directed to determining which third parties likely have a customer's payment information saved. Additionally, the systems and methods described herein are directed to presenting the customer with an interface configured to present a list of these third parties. In this way, the present systems and methods allow the customer to easily view in one place the third parties that have the customer's payment information saved such that the customer can take steps, for example, to delete the customer's payment information stored with entities the customer feels are likely not storing the customer's payment information with adequate security.
Moreover, as noted above, when a customer has updated payment information, the customer must currently update the payment information individually with each entity that has the customer's payment information saved. For example, if the customer moves and changes his or her billing address, the customer is reissued a credit card with a new expiration date and CVV, or the customer loses his or her credit card and must be assigned a new credit card number, the customer must manually change the payment information on file for various entities the customer makes purchases from and risks having transactions denied until the payment information is updated. Embodiments of the systems and methods described herein are thus further configured to update the customer's payment information with the various entities storing the customer's payment information, either automatically or upon a request from the customer. This functionality, for example, removes the possibility that the customer will have a payment request denied because the entity had outdated payment information stored for the customer.
In turn, the present systems and methods improve the functioning of the various computer systems involved in processing transaction payments for the customer. For example, if the customer inadvertently submits a request for a payment to be made to a third party using outdated payment information for the customer, the payment request will ultimately be denied by the customer's provider. The same is true if the customer has a reoccurring payment set up for a third party, and a request for the reoccurring payment is made before the customer updates the customer's payment information for the reoccurring payment. In these situations, the third party's computing systems and the provider's computing systems used for payment processing end up processing unproductive transactions, which lowers the available computer bandwidth for these computing systems and requires their processors to perform unnecessary transaction processing. Accordingly, because the present systems and methods allow the customer to easily view which third parties have the customer's payment information saved and update the customer's payment information with these third parties, these unnecessary transactions are avoided, and the functionality of the computing systems involved in processing transactions for the customer is therefore increased.
Furthermore, some third parties storing the customer's payment information may not have adequate protections on their data storage such that the customer's payment information is at risk of being stolen. Alternatively, some third parties may store the customer's payment information for ease of future transactions with the customer but may wish to decrease their liability against the possibility of the payment information being stolen. Accordingly, as described above, embodiments of the present systems and methods described herein are further directed to a secure payment service that third parties and customers can opt into and thereby carry out transactions using a one-time payment token provided by the customer's accounts provider. The secure payment service described herein thus obviates the need for third parties to store the customer's payment information, thereby decreasing the likelihood that the customer's payment information will be stolen and thus decreasing the third parties' liability, while allowing transactions to be easily carried out between a customer and third parties. Further, because the secure payment service described herein allows third parties to easily carry out transactions without storing the customer's payment information, the third parties' payment processing computing systems will require less data storage capacity and security protocols, thereby increasing the functioning of these payment processing computing systems.
Referring now to
In the environment 100, data communication between the customer device 102, provider computing system 106, and the one or more third party payment systems 108 is facilitated by the network 104. In some arrangements, the network includes the Internet. In other arrangements or combinations, the network 104 includes a local area network or a wide area network. The network 104 may be facilitated by short and/or long range communication technologies including Bluetooth transceivers, Bluetooth beacons, RFID transceivers, NFC transceivers, Wi-Fi transceivers, cellular transceivers, wired network connections, etc.
Still referring to
As shown in
The network interface circuit 122 is programmed to facilitate connection of the customer device 102 to the network 104. As such, using the network interface circuit 122, the customer may communicate with other systems or devices in the environment 100, such as the provider computing system 106 and/or one or more of the third party payment systems 108. Data passing through the network interface circuit 122 may be encrypted such that the network interface circuit 122 is a secure communication module.
The input/output circuit 124 is structured to receive from and provide communication(s) to the customer associated with the customer device 102. In this regard, the input/output circuit 124 is structured to exchange data, communications, instructions, etc. with input/output components of the customer device 102. Accordingly, in various embodiments, the input/output circuit 124 includes an input/output device, such as the display 120 or a keyboard. In other embodiments, the input/output circuit 124 includes communication circuitry for facilitating the exchange of data, values, messages, and the like between an input/output device and the components of the customer device 102. In yet other embodiments, the input/output circuit 124 includes machine-readable media for facilitating the exchange of information between an input/output device and components of the customer device 102. In still other embodiments, the input/output circuit 124 includes any of a combination of hardware components, communication circuitry, and machine-readable media.
As described above, the provider computing system 106 is associated with an accounts provider, such as a financial institution (e.g., a bank, a credit card issuer, etc.), with which the customer holds one or more accounts (e.g., demand deposit accounts, credit card accounts, etc.). As shown in
The network interface circuit 130 is programmed to facilitate connection of the provider computing system 106 to the network 104. As such, using the network interface circuit 130, the provider computing system 106 is able to communicate with other systems or devices in the environment 100, such as the customer device 102 and the third party payment systems 108. Data passing through the network interface circuit 130 may be encrypted such that the network interface circuit 130 is a secure communication module.
The payment information storage determination circuit 132 is configured to determine which third parties likely have a customer's payment information saved. In some arrangements, the payment information storage determination circuit 132 is configured to make this determination based on payment history data saved in the provider computing system 106 (e.g., in the customer accounts database 138) for each of the accounts the customer holds with the accounts provider associated with the provider computing system 106. In these arrangements, the payment information storage determination circuit 132 is programmed to mine the stored payment history data for a given account and perform analytics on the payment history data to identify third parties that are likely storing the customer's payment information.
For example, in various arrangements, the analytics are directed to first identifying a subset of the payment history data relating to online payments made from the customer's account, as opposed to payments made in brick-and-mortar locations (e.g., by removing data relating to payments requested at point-of-sale devices from the mined payment history data). The analytics are next directed to identifying characteristics of the online payments made from the payment account and determining the third parties likely storing the customer's payment information based on the identified characteristics. As an illustration, determining the third parties likely storing the customer's payment information may include (a) identifying third parties that the customer makes recurring payments to from the account (e.g., based on a determination that payments are always made from the account to the third party on the same day of the month and in the same amount), (b) identifying third parties that the customer frequently makes payments to (e.g., based on a determination that a certain number of payments have been made from the account to the third party within a certain period of time), (c) identifying third parties that the customer has made payments to and that are known to save other customers' payment information, (d) identifying third parties that always save customer payment information (e.g., based on a determination at least one payment has been made from the account to a third party, such as a ridesharing company, that requires payment information to be saved before the customer can use the third party's services), (e) identifying third parties via which the customer has made payments (e.g., based on a determination that a payment method used to make payments from the account is a third party peer-to-peer payment service that stores payment information), and so on from the online payment history data.
Moreover, in certain arrangements, the payment information storage determination circuit 132 performs analytics that also take into consideration various preferences the customer has configured for the account. In one example, the payment information storage determination circuit 132 is programmed to perform analytics that identify a series of recurring payments made from the customer's account to a third party and compare the payments with the customer's bill pay settings. If the third party is an automatic bill payee for the account, the analytics determine that the third party is not likely storing the customer's payment information, as it is unlikely that the customer would set the third party as a bill payee if the third party was storing the customer's payment information.
In other arrangements, the payment information storage determination circuit 132 is configured to determine which third parties are likely storing the customer's payment information for accounts the customer holds with the provider associated with the provider computing system 106 and with other accounts providers. As an example, the customer provides the provider computing system 106 with the customer's login credentials for a website having additional payment history information for the customer, such as credentials for the banking website for another accounts provider with which the customer holds one or more accounts, credentials for a peer-to-peer payment system through which the customer makes payments, and so on. The payment information storage determination circuit 132 is then programmed to use the customer's login credentials to access the website.
The payment information storage determination circuit 132 is further configured to perform screen scraping on the website to gather payment history data for accounts the customer holds with both the accounts provider associated with the provider computing system 106 and other accounts providers. In various arrangements, the payment information storage determination circuit 132 is structured to perform the screen scraping by capturing the website's screen input for displaying payment history data to the customer (e.g., on a browser) and processing the screen input to isolate and extract payment history data from the screen input. However, in other arrangements, the payment information storage determination circuit 132 gathers the payment history data from the website using other data scraping methods, such as through report mining (e.g., by capturing reports including payment history data and processing the reports to extract the payment history data). The payment information storage determination circuit 132 is programmed to subsequently analyze the gathered payment history data similarly to payment history data stored in the provider computing system 106 (e.g., through data mining and analytics as described above) to identify third parties likely storing the customer's payment information.
In another example, the payment information storage determination circuit 132 is programmed to gather payment history information for the customer that is stored at a different accounts provider or other payment service system affiliated with the provider computing system 106 (e.g., a peer-to-peer payment system that is also associated with the provider). The payment information storage determination circuit 132 is then programmed to perform data mining and analytics on the gathered payment history information as described above to determine third parties likely storing the customer's payment information.
The payment information storage determination circuit 132 is also configured to present to the customer a list of the third parties determined to be likely storing the customer's payment information. In various embodiments, the payment information storage determination circuit 132 is programmed to interface with the customer device 102 (e.g., through Application Programming Interfaces (“APIs”)) and present the list of third parties via a graphical user interface displayed on the customer device 102 (e.g., on the display 120). In one example, the customer accesses an online customer profile associated with the provider computing system 106 via the customer device 102, and the payment information storage determination circuit 132 is programmed to display the list of third parties on the customer profile. In another example, the customer device 102 is a smartphone running a mobile banking application thereon. The payment information storage determination circuit 132 is programmed to interface with the mobile banking application and display the list of third parties to the customer as one of the graphical user interfaces associated with the mobile banking application.
The third party updating circuit 134 is configured to update the customer's payment information with third parties that have been determined as likely storing the customer's payment information. In some arrangements, the third party updating circuit 134 is configured to automatically update these third parties when the customer's payment information changes. As an example, for a credit card account, the third party updating circuit 134 is configured to automatically update third parties storing the customer's payment information when the customer is reissued a credit card with a new expiration date and CVC, when the customer's credit card is lost or stolen and the accounts provider must issue the customer a new credit card, when the customer changes his or her billing address, and so on. In other arrangements, the third party updating circuit 134 is configured to only update payment information with third parties in response to a request from the customer. For example, in one embodiment, the third party updating circuit 134 is programmed provide a graphical user interface to the customer on the customer device 102 including a button that the customer can press, in response to which the provider computing system 106 will provide the updated payment information to the third party. In some embodiments, in order to update the customer's payment information with the third party, the provider computing system 106 must have a preexisting relationship with the third party such that the provider computing system 106 can transmit the updated payment information to the third party via a secure communication channel.
Furthermore, in certain arrangements, the third party updating circuit 134 is configured to automatically transmit a notification to a third party instructing the third party to delete the stored payment information for the customer in response to a determination by the provider computing system 106 that the third party is likely fraudulent or unsafe. In one example, the provider computing system 106 is configured to use feedback from online communities (e.g., Yelp, Google reviews) to determine that a third party is likely fraudulent. In another example, the provider computing system 106 is configured to use feedback from other customers to determine that a third party is likely fraudulent. Responsive to a determination by the provider computing system 106 that a given third party is likely fraudulent, the third party updating circuit 134 is programmed to notify the third party to delete the customer's payment information and also notify the customer that the third party is likely fraudulent.
The secure payment circuit 136 is configured to provide a secure payment service for customers and third parties. Third parties can enroll in the secure payment service, and the customer can then select for which third parties the customer would like to use the secure payment service option with one or more of the customer's payment accounts. The customer then notifies, or the secure payment circuit 136 is programmed to notify, the third party that the secure payment service option has been activated by the customer for the third party. Then, rather than the customer having to provide payment information to a third party in order to make a payment, the third party contacts the provider computing system 106 directly to receive payment information for the customer. In response, the secure payment circuit 136 is programmed to transmit a one-time use token representing the customer's payment account that has been activated for the secure payment service to the third party. The third party and the provider computing system 106 are then able to process the payment from the customer's account using the token. In some arrangements, the secure payment service is only available for reoccurring or subscription payments to third parties. In other arrangements, the secure payment service is available for any type of payment to a third party, including a one-time payment.
Thus, as discussed above, the secure payment circuit 136 is configured to allow third parties to enroll in the secure payment service. For example, the secure payment circuit 136 is configured to set up a secure communication channel with third parties that express a desire to enroll in the secure payment service to the accounts provider associated with the computing system 106. In some arrangements, the secure payment circuit 136 is configured to communicate directly with the third parties enrolled in the secure payment service (e.g., via a direct, secure communication channel between the provider computing system 106 and the third party). In other arrangements, the secure payment circuit 136 is configured to communicate indirectly with the third parties enrolled in the secure payment service, such as via a card network.
As further discussed above, the secure payment circuit 136 is also configured to allow customers to opt into and out of the secure payment service. In various embodiments, the secure payment circuit 136 is configured to interface with the customer device 102 and provide graphical user interfaces (e.g., via the display 120) enabling the customer to opt into and out of the secure payment service (e.g., as shown in
In some embodiments, the customer is presented the option, via the graphical user interfaces, to activate the secure payment service for the enrolled third parties determined to be likely storing the customer's payment information. In other embodiments, additionally or alternatively, the customer is able to generally select enrolled third parties and use the secure payment service with the selected third parties. In one example, the graphical user interfaces include a list of enrolled third parties that the customer can scroll through and select (e.g., by clicking on the names of the enrolled third parties, by checking a box next to the third parties). The secure payment circuit 136 is programmed to then activate the secure payment service for these selected third parties.
Additionally, in some arrangements, after the customer activates the secure payment service for a given third party (e.g., a third party associated with a third party payment system 108), the customer notifies the third party that the customer has activated the secure payment service for the third party. The third party then verifies the activation with the provider computing system 106. Alternatively, in other arrangements, the secure payment circuit 136 is configured to notify the third party that the customer has activated the secure payment service for the third party.
After the secure payment service has been activated between a customer and a third party, when the provider computing system 106 subsequently receives a “secure payment” request initiated by the customer (e.g., via a third party payment system 108) for fulfillment through the secure payment service, the secure payment circuit 136 is configured to identify the customer account from which the payment should be made. In some embodiments, the third party payment system 108 provides identifying information for the customer with the secure payment request, such as an email, a password, a personal identification number (“PIN”), a scan of a driver's license, and so on. The secure payment circuit 136 is programmed to use the identifying information to identify the customer and the customer account from which the payment should be made. In some arrangements, the identifying information corresponds to a specific customer account, and the secure payment circuit 136 is programmed to identify the customer account based just on the received identifying information. In other arrangements, the identifying information corresponds to a customer with multiple accounts at the accounts provider associated with the provider computing system 106 that are activated for the secure payment service with the third party. The secure payment circuit 136 is thus programmed to identify the customer account to be used for the payment based on, for example, preconfigured payment settings entered by the customer or purchase information about the transaction also transmitted by the third party payment system 108 (e.g., based on the transaction being for airline tickets, the customer's travel credit card is selected for the transaction).
Alternatively, in other embodiments, the third party payment system 108 identifies the customer to the provider computing system 106. For example, the third party payment system 108 identifies the customer based on login credentials provided by the customer in making the payment request. The secure payment circuit 136 is programmed to then identify the customer account for the transaction based on the identification of the customer by the third party payment system 108 and, in some arrangements, further based on purchase information also transmitted by the third party payment system 108 with the payment request.
Once the customer account to be used for the payment has been identified, the secure payment circuit 136 is configured to create a one-time use token representing the customer account. For example, the secure payment circuit 136 is programmed to generate a random number and store the random number or alphanumeric string in association with the customer account in a token vault (e.g., in the customer accounts database 138). As another example, the secure payment circuit 136 is programmed to use a cryptographic algorithm to generate a token based on the customer account number (e.g., a hash of the customer's primary account number (“PAN”)). The secure payment circuit 136 is programmed to then transmit the one-time use token to the third party payment system 108 (e.g., either directly or via a card network). Subsequently, the secure payment circuit 136 is programmed to decode the token and retrieve the customer account number as part of processing the payment from the customer's account. For example, the secure payment circuit 136 is programmed to use the token vault or decrypt the token hash to identify the customer account number. The secure payment circuit 136 is configured to then authorize the payment for the transaction and charge the customer's account (e.g., remove funds from the account, decrease the amount of credit available from the account). If the third parties later issues the customer a refund for the transaction (e.g., because the customer returned an item purchased from the third party), the secure payment circuit 136 is similarly configured to receive the refund request, identify the token originally used in the transaction, and decode the token to identify the customer account used for the transaction and process the refund.
In some arrangements, the secure payment circuit 136 is configured to only allow the customer to opt into or out of the secure payment service as a whole (e.g., once the customer opts in, the secure payment service is used for all of the customer's transactions with the enrolled third parties listed for the customer). In other arrangements, the secure payment circuit 136 is configured to allow the customer to opt into and out of the secure payment service for specific third parties. For example, the payment information storage determination circuit 132 is configured to provide graphical user interfaces to the customer that list the third parties likely storing the customer's payment information saved and display a toggle switch next to each third party that is enrolled in the secure payment service. Accordingly, the customer can activate or deactivate the secure payment service option for each eligible third party by toggling the switch.
Additionally, in some embodiments, when the customer opts into the secure payment service with a third party, the secure payment circuit 136 is programmed to send a notification to the customer reminding the customer that the customer can delete the customer's payment information stored with the third party. Alternatively, the secure payment circuit 136 is programmed to notify the third party that the third party can delete the customer's saved payment information. As discussed above, the fact that the third party can delete the customer's saved payment information once the third party has enrolled in the secure payment service and the customer has activated the secure payment service for the third party is advantageous to both the customer and the third party. By doing so, the third party's data storage requirements are lessened, and the third party does not run the risk of a data breach occurring where the customer's payment information is leaked. The customer likewise does not have to worry about the security of the customer's payment information stored with the third party or the necessity of updating the customer's saved payment information with the third party in the future. As such, notifying the customer or the third party to delete the customer's saved payment information helps ensure that the customer and the third party take advantage of these benefits of the secure payment service.
Furthermore, in some embodiments, the secure payment circuit 136 is configured to activate or deactivate the secure payment service on the customer's behalf. For example, in one embodiment, if the provider computing system 106 makes a determination that a third party storing the customer's payment information is likely to suffer a data security breach (e.g., because the third party does not use sufficient security protocols to protect customer payment information), the secure payment circuit 136 is configured to automatically activate the secure payment service for the third party. The secure payment circuit 136 is further configured to notify the third party to delete the stored payment information for the customer. In this way, the customer can continue carrying out transactions with the third party without the risk of the customer's payment information being compromised. Alternatively, if the provider computing system 106 makes a determination that a third party the customer has been making automatic, reoccurring payments to using the secure payment service is likely fraudulent (e.g., based on an independent determination by the provider computing system 106 and/or based on online community input that the third party is likely fraudulent), the secure payment circuit 136 is configured to deactivate the secure payment service such that the customer can no longer make automatic payments to the third party. The secure payment circuit 136 is further configured to notify the customer that the third party is likely fraudulent.
The customer accounts database 138 is configured to retrievably store account information for various customers of the accounts provider associated with the provider computing system 106. For example, in various embodiments, the customer accounts database 138 stores payment information for customers, such as account numbers, account types, account balances, transaction histories, and billing or contact addresses. In particular, the customer accounts database 138 is configured to store payment history data for various customers from which lists of third parties likely storing the customers' payment information can be determined. The customer accounts database 138 is also configured to store payment history data for payment accounts held by various customers with other accounts providers that is gathered by the payment information storage determination circuit 132. Additionally, the customer accounts database 138 is configured to store various customer preferences relating to the payment information access management systems and methods described herein. For example, the customer accounts database 138 is configured to store whether and for which third parties a customer has activated the secure payment service. Further, in some arrangements, the customer accounts database 138 includes a token vault, which identifies the account associated with a given one-time use token (e.g., the token vault includes token-to-PAN mapping) generated as part of the secure payment service.
As shown in
In various embodiments, each third party payment system 108 includes a network interface circuit 150, a payment processing circuit 152, and a customer payment information database 154. The network interface circuit 150 is programmed to facilitate connection of the third party payment system 108 to the network 104. As such, the third party payment system 108 may communicate with other systems or devices in the environment 100, such as the customer device 102 and/or the provider computing system 106. Data passing through the network interface circuit 150 may be encrypted such that the network interface circuit 150 is a secure communication module.
The payment processing circuit 152 is configured to process payments initiated by customers for transactions. Accordingly, in various arrangements, the payment processing circuit 152 is configured to gather payment information from a customer or use saved payment information for the customer to process a transaction payment. Alternatively, if the third party is enrolled in the secure payment service, the payment processing circuit 152 is configured to transmit a secure payment request to the provider computing system 106 (e.g., via a secure communication channel, via a card network) and receive a one-time use payment token from the provider computing system 106 representing the customer's account number. In some embodiments, the payment processing circuit 152 is programmed to only process a payment for the customer using the secure payment service in response to the customer requesting that the payment be made using the secure payment service (e.g., during an online checkout, by the customer clicking a button indicating that the payment should be made using the secure payment service). Otherwise, the payment processing circuit 152 is programmed to use saved payment information for the customer or request that the customer provide payment information to the third party payment system 108. In other embodiments, when a customer enters into a transaction with the third party, the payment processing circuit 152 is programmed to determine whether the customer or the provider computing system 106 has notified the third party payment system 108 that the customer has activated the secure payment service for the third party (e.g., by checking customer profile data stored in the customer payment information database 154). If the customer has activated the secure payment service for the third party, the payment processing circuit 152 is programmed to then automatically use the secure payment service provided by the provider computing system 106 to process the payment for the customer.
In some arrangements, when using the secure payment service to process a payment, the payment processing circuit 152 is further configured to gather identifying information for the customer such that the customer can be identified to the provider computing system 106 and/or the provider computing system 106 can identify the customer account from which the payment should be made. For example, in various embodiments, the payment processing circuit 152 is programmed to gather a username and password, a PIN, a scan of a driver's license or other form of identification, and so on from the customer. The payment processing circuit 152 is programmed to then transmit the identifying information to the provider computing system 106 (e.g., either directly or via a card network) along with purchase information. In other arrangements, the payment processing circuit 152 is configured to authenticate the customer (e.g., with a username and password combination) and transmit an identification of the customer to the provider computing system 106 along with purchase information.
As discussed above, in response to receiving the request for a payment via the secure payment service, the provider computing system 106 transmits a one-time use token representing the customer's account to be used for the payment, which the payment processing circuit 152 is configured to receive. The payment processing circuit 152 is then configured to use the token to complete the transaction. Additionally, if the customer later requests a refund for the transaction (e.g., the customer returns an item purchased as part of the transaction), the payment processing circuit 152 is, for example, configured to identify the token used in the transaction and transmit the refund request and token to the provider computing system 106, which processes the refund.
Referring now to
A determination of which third parties are likely storing customer payment information is made at 204. For example, data analytics is used on the payment history data to identify a subset of the payment history data directed to online payments. Data analytics is also used to identify characteristics of the online payments (e.g., frequency of payments, timing of payments, amounts of payments, methods of payments, and the identities of third parties to which payments have been made) and, based on the characteristics, third parties likely storing the customer's payment information.
A list of the third parties likely storing the customer's payment information is presented at 206. In various embodiments, graphical user interfaces are displayed on the customer device 102 to present the list of third parties to the customer, as discussed in more detail above and as illustrated in
A customer request to update payment information saved by one or more of the third parties is received at 208. Subsequently, the updated payment information is transmitted to the one or more third parties at 210. In various embodiments, a graphical user interface is presented to the customer whereby the customer can make selections to update payment information with third parties determined to be likely storing the customer's payment information. In some arrangements, the customer can select the third parties to which the updated payment information should be provided. In other arrangements, the customer can select that all third parties likely storing the customer's payment information should be provided the updated payment information. In still other arrangements, the customer can provide a preference to the provider computing system 106 that some or all of the third parties likely storing the customer's payment information should be provided with updated payment information whenever the customer's payment information changes. As such, the third parties are automatically provided with updated payment information whenever payment information changes occur (e.g., the customer's billing address changes, the customer is issued a new credit card). Alternatively, some or all of the third parties likely storing the customer's payment information are provided with updated payment information for the customer even without a selection from the customer.
Referring now to
Subsequently, analytics are performed on the payment history data to identify third parties likely storing the customer's payment information. To begin with, whether non-brick-and-mortar payments are included in the payment history data is determined at 304. In certain arrangements, metadata for the payments included in the payment history data is examined to determine if online payments have been made to third parties. For example, an online payment is identified when the metadata indicates that the payment is an online payment, that the payment was made using a payment service (e.g. PayPal®, Venmo®, etc.), that the payment was made to a third party that can only be paid online, etc. If only brick-and-mortar payments are identified, payment history data is again gathered at 302. If instead non-brick-and-mortar payments are identified, the subset of non-brick-and-mortar payments is extracted from the payment history data at 306.
Once the subset of non-brick-and-mortar payments is extracted, various characteristics of the non-brick-and-mortar payments made from the payment account are identified and used to determine third parties likely storing the customer's payment information. Examples of the characteristics are presented in method 300. To begin with, whether recurring online payments have been made from the account to a third party is determined at 308. Recurring payments may be defined, for example, as payments made on the same day of the month in the same amount for a certain number of months or payments made on the same day of the week in the same amount for a certain number of weeks. If a third party is identified as a recipient of recurring payments, the third party is determined to be likely storing the customer's payment information at 310.
After identifying third parties likely storing the customer's payment information at 310, or identifying that recurring payments have not been made to any third party, whether frequent payments have been made from the account to a third party is determined at 312. As an example, frequent payments may be defined as a certain number of payments being made within a certain time period to the third party (e.g., five payments made in a month). As another example, frequent payments may be defined based on the customer's history of using the payment account (e.g., a certain percentage of the customer's payments from the account have been made to the third party). If a third party is identified as a recipient of frequent payments, the third party is determined to be likely storing the customer's payment information at 314.
After identifying third parties likely storing the customer's payment information at 314, or identifying that frequent payments have not been made to any third party, whether payments have been made to a third party that is known to store other customers' payment information is determined at 316. For example, a database may store a list of third parties determined to be likely storing a certain number of other customer's information. The subset of customer payment history data is thus compared to the list to identify the third parties common to the list and the data. If a third party known to store other customers' payment information is identified as a recipient of payments from the account, the third party is determined to be likely storing the customer's payment information at 318. In some arrangements, the third party is only determined to be likely storing the customer's payment information if a certain number of payments are made to the third party. In other arrangements, the third party is determined to be likely storing the customer's payment information based at least partially on how often the third party is known to store payment information (e.g., if only a few payments have been made from the account to a third party that is highly likely to store payment information, the third party is still determined to be likely storing the customer's payment information).
After identifying third parties likely storing the customer's payment information, or identifying that no payments or that fewer than a certain threshold of payment have been made to third parties known to store other customers' payment information, whether payments have been made to a third party known to always store payment information is determined at 320. As an example, a list is maintained of third parties that require storing payment information for a customer before the customer can use a service provided by the third party (e.g., a ride sharing service). The subset of payment history data is then compared to the list to identify the third parties common to the list and the data. If a third party known to always store payment information is identified, the third party is determined to be likely storing the customer's payment information at 322.
After identifying third parties likely storing the customer's payment information, or identifying that no payments have been made to third parties known to always store payment information, whether payments have been made via third party payment services is determined at 324. For example, whether the customer has made a payment from the account through a peer-to-peer payment system (e.g., PayPal®, Venmo®, etc.) is identified. If a third party payment system is identified in the payment history data, the third party is determined to be likely storing the customer's payment information at 326.
After identifying third parties likely storing the customer's payment information, or identifying that no payments have been made via third party payment systems, a list of the third parties (if any) identified at 310, 314, 318, 322, and 326 is compiled at 328 (e.g., the identities of third parties likely storing the customer's information are stored in the customer accounts database 138 in connection with the customer). A determination of whether a request for the list has been received from the customer is made at 330. If a request has been received, then the list of the third parties likely storing the customer's payment information is presented to the customer at 332. Subsequently, the method 300 is then repeated such that additional payment history data is gathered and analyzed as described herein. The method 300 is likewise repeated if a request for the list of third parties likely storing the customer's payment information has not been received.
It should be understood, however, that method 300 is an example method. In other embodiments, different analyses may be applied to the payment history data to identify third parties likely storing the customer's payment information. Moreover, in certain embodiments, at least some of the analyses discussed with reference to method 300 may be combined. For example, in another embodiment, the method 300 of determining third parties likely storing the customer's payment information includes a step of determining whether frequent payments have been made to a third party known to store other customers' payment information.
Referring now to
In response to the updated payment information, a determination is made as to whether there is a stored preference, from the customer, for automatically updating the customer's payment information saved by a third party at 406. In one example, the customer uses a graphical user interface to indicate whether the customer would like certain third parties or all third parties with saved payment information for the customer to be automatically updated when the customer's payment information is modified, and the customer's preference is accordingly stored. Thus, at 406, the customer's stored preference is retrieved.
If the customer has indicated a preference to automatically update a third party, the updated payment information is transmitted to the third party at 408. If the customer has not indicated a preference to a third party (e.g., because there is no stored preference for the customer, because the customer has indicated a preference to update other third parties but not the given third party, etc.), whether the customer has manually selected that the third party be provided the updated payment information is determined at 410. As an example, the customer uses a graphical user interface to indicate that the customer would like a given third party to receive updated payment information (e.g., as shown in
Referring now to
Input from the customer indicating that the customer would like to use the provider's secure payment service is received at 508. In various embodiments, graphical user interfaces are presented to the customer whereby the customer can activate the secure payment service for various third parties. In some embodiments, the customer can use the graphical user interfaces to select which third parties the secure payment service should be used with for one or more of the customer's accounts. In some arrangements, the customer can select third parties determined to be likely storing the customer's payment information. Moreover, in other arrangements, the customer can select third parties not determined to be likely storing the customer's payment information (e.g., by accessing a list of the third parties enrolled in the secure payment service, by searching for third parties enrolled in the secure payment service in a search box). Alternatively, in other embodiments, the customer can select that the secure payment service be used with all third parties likely storing the customer's payment information, with all third parties the customer makes reoccurring payments to, and so on.
The third party is notified that the customer has activated the secure payment service with the third party at 510. Accordingly, the third party payment system 108 is able to store this customer preference (e.g., in the customer payment information database 154) such that, when the customer requests a payment in the future, the third party payment system 108 contacts the provider computing system 106 for a one-time use token. Alternatively, in other embodiments, the third party is not directly notified of the customer's activation of the secure payment service for the third party. Rather, when the customer enters into a transaction with the third party, the customer informs the third party that the customer would like to carry out the transaction using the provider's secure payment service.
A secure payment request is received from the third party payment system 108 at 512. In some embodiments, the provider computing system 106 receives the secure payment request via a secure communication channel between the provider computing system 106 and the third party payment system 108. In other embodiments, the provider computing system 106 communicates with the third party payment system 108 via an intermediary (e.g., a card network).
A payment account or other account held by the customer to be used for the payment to the third party is then identified at 514. In some arrangements, identifying information for the customer is transmitted with the secure payment request. The customer, and thus the customer's account to be used for the transaction, is identified based on the transmitted identifying information. Alternatively, in other embodiments, the customer is authenticated by the third party payment system 108, which identifies the customer to the provider computing system 106. The customer account to be used for the transaction payment is thus based on the identification of the customer by the third party payment system 108. Further, in certain embodiments, if the customer has more than one payment account associated with the provider, once the customer is identified the customer account to be used for the transaction payment is selected based on preconfigured payment settings, purchase information for the transaction transmitted with the secure payment request (e.g., the amount of the transaction, what is being purchased in the transaction), and so on.
A one-time use token representing the customer account is transmitted to the third party payment system 108 at 516. In various embodiments, the token is generated by assigning a random number to the customer account, by outputting a cryptographic hash based on the customer account number, and so on, as discussed above.
Finally, a payment is processed using the one-time use payment token at 518. For example, the provider computing system 106 receives the payment token from the third party payment system 108, either directly or via a card network. The token is then decoded (e.g., by looking up the associated customer account using the token vault, by decrypting the token), and, assuming that the customer account has sufficient available funds or credit, a payment to the third party is authorized from the customer account.
Referring now to
In response to receiving the payment request, whether the third party has authenticated the customer is determined at 604. In one example, the third party authenticates the customer based on login credentials provided by the customer in making the request. The third party then includes the identification of the customer and an indication that the customer has been authenticated in the payment request. If the third party has authenticated the customer, the customer is identified based on the authentication at 610. However, if the third party has not authenticated the customer, whether the third party has provided identifying information for the customer is determined at 606. As an example, the third party requests from the customer and includes in the payment request biographical or other personal information about the customer such as an email, a password, a PIN, a scan of a driver's license or other identification card, an identification number, and so. If identifying information is included in the payment request, the customer is identified at 610. In some arrangements, the customer is also authenticated at 610. In some examples, a two-factor authentication process is carried out (e.g., the provider computing system 106 sends a text to the customer's phone, and the provider computing system 106 only proceeds with method 600 if the customer responds to the text within a certain amount of time). If identifying information is not included in the payment request, more information about the customer is requested from the third party at 608.
Once the customer is identified, a determination of whether the customer has activated the secure payment service for the third party is made at 612. If the customer has not activated the secure payment service, the customer is asked to activate the secure payment service for the third party at 614. For example, the customer is sent a notification, such as an email or a text message, with a link to a web site whereby the customer can activate the secure payment service for the third party (e.g., as shown in
Subsequently, a determination is made as to whether the customer activates the secure payment service for the third party within a certain amount of time from the transaction request at 616. If the customer does not activate the secure payment service for the third party within a certain amount of time, the third party and/or the customer are instructed to retry the transaction when the customer has activated the secure payment service or to complete the transaction normally at 618 (e.g., with the customer entering credit card information into an online checkout system for the third party or with the third party using stored payment information for the customer to complete the transaction). If the customer later activates the secure payment service for the third party and the transaction is reattempted, the method 600 is restarted at 602. Alternatively, if the customer and/or the third party elect to complete the transaction normally, the transaction is processed normally at 620 (e.g., by receiving payment card information via an acquirer and a card network, authorizing the transaction, and transferring funds to the acquirer).
If the customer has already activated the secure payment service for the third party, or if the customer activates the secure payment service within a certain amount of time, a determination as to whether the customer has activated the secure payment service for the third party for more than one payment account held by the customer is made at 622. If the secure payment service has been activated for only one account, a one-time use payment token is transmitted to the third party (e.g., via a secure communication channel) for the activated account at 632.
If instead the secure payment service has been activated for more than one account, a determination is made at 624 as to whether the customer has identified the account to use for the transaction (e.g., whether the customer identified the account to use when initiating the transaction with the third party, and the third party transmitted the account identification in the payment request). If the customer has identified the account to use, a one-time use payment token representing the identified account is transmitted to the third party at 632. Otherwise, a determination as to whether stored preferences exist for determining which payment account to use for the transaction at 626. If there are stored preferences for the customer, the preferences are used to identify the account to use for the transaction at 628. For example, if the customer has provided preferences regarding the account that should be used for certain transaction amounts, certain transaction types, certain transaction locations, and so on, the preferences are compared to information about the requested transaction transmitted with the payment request. A determination is then made as to which payment account to use for the transaction based on the results of the comparison (e.g., the payment account with the most matches to the preferences is used for the transaction). As another example, if the customer has indicated that a certain payment account is the default account except for certain transaction types, the payment account is then used for the transaction unless the payment request indicates that it is one of the certain transaction types.
On the other hand, if the customer has not provided preferences for determining which payment account to use (or if, in certain arrangements, the preferences are inadequate for determining which payment account to use), the payment request is used to determine which payment account to use for the transaction at 630. As an illustration, in one example, the customer activates the secure payment service for the third party for a debit account and a credit account the customer holds with an accounts provider. The credit account is then used for the transaction unless the transaction amount indicated in the payment request is greater than the credit remaining for the customer's credit card account. In that case, the customer's debit account is instead used for the transaction.
Once the account to use for the transaction is identified based on the customer's preferences or determined using the payment request, a one-time use token representing the identified account is transmitted to the third party at 632. After the third party receives the one-time use token, the transaction is processed using the one-time use token at 634.
Referring now to
In
In the example of
As shown in row 722, the provider computing system 106 has determined (e.g., via screen scraping) that Merchant B is storing the payment information for a credit card that the customer holds with a second accounts provider termed “Accounts Provider B” (e.g., an accounts provider not affiliated with the provider computing system 106). Row 722 also shows the customer that Merchant B is enrolled in the secure payment service but that the customer has not activated the secure payment service for Merchant B and provides a button in column 714 that the customer can press to activate the secure payment service for Merchant B. Similarly, the provider computing system 106 has determined (e.g., via screen scraping) that Airline A is storing the payment information for the customer's Accounts Provider B credit card, as shown in row 724. However, as illustrated in column 714, Airline A is not enrolled in the secure payment service, so the customer is not provided with a button that the customer can press to activate the secure payment service for Airline A. Instead, row 724 shows the customer a message informing the customer that the customer receives 5% cash back when the customer uses the Accounts Provider A credit card on travel. Additionally, in both row 722 and row 724, and unlike with row 720, the customer is not provided a button in column 716 whereby the customer can update the customer's payment information with Merchant B, as the payment information stored with Merchant B and Airline A is not related to Accounts Provider A.
As illustrated in row 726, the provider computing system 106 has also determined (e.g., both via searching the customer's payment history data stored in the customer accounts database 138 and via screen scraping) that the Auction Website is storing the payment information for the customer's Accounts Provider A credit card and Accounts Provider B credit card. Additionally, because the Auction Website is enrolled in the secure payment service, the customer is provided with a button in column 714 whereby the customer can activate the secure payment service for future transactions with the Auction Website. Further, the customer is provided with a button in column 716 that the customer can press to update the customer's Accounts Provider A credit card payment information with the Auction Website.
As shown in rows 728 and 730, the provider computing system 106 has further determined that the Rent Payment Company and the Utilities Company are storing payment information relating to the customer's checking account. While the Rent Payment Company is not enrolled in the secure payment service, the Utilities Company is enrolled in the service, and as shown in column 714, the customer has activated the secure payment service for the Utilities Company. Additionally, for the Utilities Company, the column 714 includes an asterisk that points to a message 732 at the bottom of the third party storage page 706, which indicates to the customer that once the customer has activated the secure payment service for a third party, Accounts Provider A recommends that the customer delete the customer's payment information stored with the third party (e.g., because the secure payment service obviates the need for the third party to store the customer's payment information, which reduces security risks connected with a data breach with the third party). For both rows 728 and 730, the table 708 also includes a button in column 716 that the customer can press to update the customer's payment information (e.g., payment information relating to the customer's checking account with Accounts Provider A) with the Rent Payment Company and the Utilities Company, respectively.
Referring now to
The table 742 includes a column 746 providing a list of the enrolled third parties for the customer (e.g., included in the list of third parties likely storing the customer's payment information in table 708 and/or added by the customer using the “Add third party” button 744). The table 742 also includes a column 748 providing buttons that the customer can toggle to activate/deactivate the secure payment service for each of the customer's payment accounts. Accordingly, the column 748 includes two sub-columns: a sub-column 750 for activating/deactivating the secure payment service for the customer's checking account (i.e., “Checking Account XXXXXX1234”) and a sub-column 752 for activating/deactivating the secure payment service for the customer's Accounts Provider A credit card (i.e., “Credit Card XXXX-XXXX-XXXX-5678”).
In the example of
Moreover, as shown in
More specifically, as illustrated in
As shown in row 758, the secure payment service can also be activated for Merchant C with the customer's checking account, though the secure payment service is not activated. However, the secure payment service for Merchant C has been activated with the customer's Accounts Provider A credit card. For example, in some arrangements, the secure payment service for Merchant C has been activated with the customer's Accounts Provider A credit card because the secure payment service was automatically activated for Merchant C with the customer's Accounts Provider A credit card (e.g., when Merchant C was added to the table 742) and the customer never deactivated the secure payment service. Alternatively, in other arrangements, the secure payment service for Merchant C is activated with the customer's Accounts Provider A credit card because the customer activated the secure payment service (e.g., by toggling the button shown in sub-column 752 for row 758 from “Not Activated” to “Activated”). Similarly, row 760 shows that the secure payment service for Merchant D can only be activated with the customer's Accounts Provider A credit card and has been activated for Merchant D with the customer's Accounts Provider A credit card.
Row 762 shows that the customer can only activate the secure payment service for the Auction Website with the customer's Accounts Provider A credit card but that the secure payment service has not been activated for the Auction Website. Conversely, as shown in row 764, the customer can only activate the secure payment service for the Utilities Company using the customer's checking account, and the secure payment service has been activated for the Utilities Company. The fact that the secure payment service has not been activated for the Auction Website but has been activated for the Utilities Company is also reflected in rows 728 and 730, respectively, of table 708 shown in
Those of skill in the art will appreciate, however, that
It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”
As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein. For example, a circuit as described herein may include one or more transistors, logic gates (e.g., NAND, AND, NOR, OR, XOR, NOT, XNOR, etc.), resistors, multiplexers, registers, capacitors, inductors, diodes, wiring, and so on.
The “circuit” may also include one or more processors communicatively coupled to one or more memories or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory). Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.
An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.
It should also be understood that a “network interface circuit,” as used herein, includes any of a cellular transceiver Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Long-Term Evolution (LTE), etc.), a wireless network transceiver (e.g., 802.11X, ZigBee, or Bluetooth), or a combination thereof (e.g., both a cellular transceiver and a Bluetooth transceiver). In some arrangements, a network interface circuit includes hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, the network interface circuit includes cryptography capabilities to establish a secure or relatively secure communication session between the device including the network interface and other devices of the environment 100 via the network 104. In this regard, personal information about clients, payment data, and other types of data is encrypted and transmitted to prevent or substantially prevent the threat of hacking.
Any foregoing references to currency or funds are intended to include fiat currencies, non-fiat currencies (e.g., precious metals), and math-based currencies (often referred to as cryptocurrencies). Examples of math-based currencies include Bitcoin, Litecoin, Dogecoin, and the like.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule-based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps, and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions, and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.
This application claims priority to U.S. Provisional Patent Application No. 62/588,756 entitled “SYSTEMS AND METHODS FOR PAYMENT INFORMATION ACCESS MANAGEMENT,” filed Nov. 20, 2017, and incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5485510 | Colbert | Jan 1996 | A |
| 5573457 | Watts et al. | Nov 1996 | A |
| 5737423 | Manduley | Apr 1998 | A |
| 5999978 | Angal et al. | Dec 1999 | A |
| 6047268 | Bartoli et al. | Apr 2000 | A |
| 6105006 | Davis et al. | Aug 2000 | A |
| 6188309 | Levine | Feb 2001 | B1 |
| 6193152 | Fernando et al. | Feb 2001 | B1 |
| 6408330 | Delahuerga | Jun 2002 | B1 |
| 6422462 | Cohen | Jul 2002 | B1 |
| 6494367 | Zacharias | Dec 2002 | B1 |
| 6575361 | Graves et al. | Jun 2003 | B1 |
| 6717592 | Gusler et al. | Apr 2004 | B2 |
| 6845906 | Royer et al. | Jan 2005 | B2 |
| 6865547 | Brake, Jr. et al. | Mar 2005 | B1 |
| 6879965 | Fung et al. | Apr 2005 | B2 |
| 6910021 | Brown et al. | Jun 2005 | B2 |
| 6980969 | Tuchler et al. | Dec 2005 | B1 |
| 7014107 | Singer et al. | Mar 2006 | B2 |
| 7016877 | Steele et al. | Mar 2006 | B1 |
| 7107243 | McDonald et al. | Sep 2006 | B1 |
| 7219833 | Cantini et al. | May 2007 | B2 |
| 7225156 | Fisher et al. | May 2007 | B2 |
| 7249099 | Ling | Jul 2007 | B2 |
| 7264154 | Harris | Sep 2007 | B2 |
| 7319986 | Praisner et al. | Jan 2008 | B2 |
| 7331518 | Rable | Feb 2008 | B2 |
| 7347361 | Lovett | Mar 2008 | B2 |
| 7359880 | Abel et al. | Apr 2008 | B2 |
| 7383988 | Slonecker, Jr. | Jun 2008 | B2 |
| 7392224 | Bauer et al. | Jun 2008 | B1 |
| 7398248 | Phillips et al. | Jul 2008 | B2 |
| 7451395 | Brants et al. | Nov 2008 | B2 |
| 7512563 | Likourezos et al. | Mar 2009 | B2 |
| 7552088 | Malcolm | Jun 2009 | B2 |
| 7571142 | Flitcroft et al. | Aug 2009 | B1 |
| 7587365 | Malik et al. | Sep 2009 | B2 |
| 7653597 | Stevanovski et al. | Jan 2010 | B1 |
| 7685037 | Reiners et al. | Mar 2010 | B2 |
| 7689502 | Lilly et al. | Mar 2010 | B2 |
| 7698221 | Blinn et al. | Apr 2010 | B2 |
| 7707082 | Lapstun et al. | Apr 2010 | B1 |
| 7712655 | Wong | May 2010 | B2 |
| 7753265 | Harris | Jul 2010 | B2 |
| 7778932 | Yan | Aug 2010 | B2 |
| 7818319 | Henkin et al. | Oct 2010 | B2 |
| 7873573 | Realini | Jan 2011 | B2 |
| 7937325 | Kumar et al. | May 2011 | B2 |
| 7941534 | De La Huerga | May 2011 | B2 |
| 7949572 | Perrochon et al. | May 2011 | B2 |
| 7954704 | Gephart et al. | Jun 2011 | B1 |
| 8090346 | Cai | Jan 2012 | B2 |
| 8099109 | Altman et al. | Jan 2012 | B2 |
| 8127982 | Casey et al. | Mar 2012 | B1 |
| 8160933 | Nguyen et al. | Apr 2012 | B2 |
| 8175938 | Olliphant et al. | May 2012 | B2 |
| 8196131 | Von Behren et al. | Jun 2012 | B1 |
| 8245909 | Pletz et al. | Aug 2012 | B2 |
| 8249983 | Dilip et al. | Aug 2012 | B2 |
| 8255323 | Casey et al. | Aug 2012 | B1 |
| 8266031 | Norris et al. | Sep 2012 | B2 |
| 8266205 | Hammad et al. | Sep 2012 | B2 |
| 8280786 | Weiss et al. | Oct 2012 | B1 |
| 8280788 | Perlman | Oct 2012 | B2 |
| 8296228 | Kloor | Oct 2012 | B1 |
| 8297502 | McGhie et al. | Oct 2012 | B1 |
| 8301566 | Mears | Oct 2012 | B2 |
| 8332294 | Thearling | Dec 2012 | B1 |
| 8359531 | Grandison et al. | Jan 2013 | B2 |
| 8360952 | Wissman et al. | Jan 2013 | B2 |
| 8364556 | Nguyen et al. | Jan 2013 | B2 |
| 8396808 | Greenspan | Mar 2013 | B2 |
| 8407136 | Bard et al. | Mar 2013 | B2 |
| 8407142 | Griggs | Mar 2013 | B1 |
| 8423349 | Huynh et al. | Apr 2013 | B1 |
| 8473394 | Marshall | Jun 2013 | B2 |
| 8489894 | Comrie et al. | Jul 2013 | B2 |
| 8543506 | Grandcolas et al. | Sep 2013 | B2 |
| 8589335 | Smith et al. | Nov 2013 | B2 |
| 8595074 | Sharma et al. | Nov 2013 | B2 |
| 8595098 | Starai et al. | Nov 2013 | B2 |
| 8625838 | Song et al. | Jan 2014 | B2 |
| 8630952 | Menon | Jan 2014 | B2 |
| 8635687 | Binder | Jan 2014 | B2 |
| 8655310 | Katzer et al. | Feb 2014 | B1 |
| 8655719 | Li et al. | Feb 2014 | B1 |
| 8660926 | Wehunt et al. | Feb 2014 | B1 |
| 8682753 | Kulathungam | Mar 2014 | B2 |
| 8682802 | Kannanari | Mar 2014 | B1 |
| 8700729 | Dua | Apr 2014 | B2 |
| 8706625 | Vicente et al. | Apr 2014 | B2 |
| 8712839 | Steinert et al. | Apr 2014 | B2 |
| 8725601 | Ledbetter et al. | May 2014 | B2 |
| 8762211 | Killian et al. | Jun 2014 | B2 |
| 8762237 | Monasterio et al. | Jun 2014 | B2 |
| 8781957 | Jackson et al. | Jul 2014 | B2 |
| 8781963 | Feng et al. | Jul 2014 | B1 |
| 8793190 | Johns et al. | Jul 2014 | B2 |
| 8794972 | Lopucki | Aug 2014 | B2 |
| 8851369 | Bishop et al. | Oct 2014 | B2 |
| 8868458 | Starbuck et al. | Oct 2014 | B1 |
| 8880047 | Konicek et al. | Nov 2014 | B2 |
| 8887997 | Barret et al. | Nov 2014 | B2 |
| 8924288 | Easley et al. | Dec 2014 | B1 |
| 8954839 | Sharma et al. | Feb 2015 | B2 |
| 9076134 | Grovit et al. | Jul 2015 | B2 |
| 9105021 | Tobin | Aug 2015 | B2 |
| 9195984 | Spector et al. | Nov 2015 | B1 |
| 9256871 | Anderson et al. | Feb 2016 | B2 |
| 9256904 | Haller et al. | Feb 2016 | B1 |
| 9372849 | Gluck et al. | Jun 2016 | B2 |
| 9390417 | Song et al. | Jul 2016 | B2 |
| 9396491 | Isaacson et al. | Jul 2016 | B2 |
| 9489694 | Haller et al. | Nov 2016 | B2 |
| 9514456 | England et al. | Dec 2016 | B2 |
| 9519934 | Calman et al. | Dec 2016 | B2 |
| 9558478 | Zhao | Jan 2017 | B2 |
| 9569473 | Holenstein et al. | Feb 2017 | B1 |
| 9576318 | Caldwell | Feb 2017 | B2 |
| 9646300 | Zhou et al. | May 2017 | B1 |
| 9647855 | Deibert et al. | May 2017 | B2 |
| 9690621 | Kim et al. | Jun 2017 | B2 |
| 9699610 | Chicoine et al. | Jul 2017 | B1 |
| 9792636 | Milne | Oct 2017 | B2 |
| 9792648 | Haller et al. | Oct 2017 | B1 |
| 9849364 | Tran et al. | Dec 2017 | B2 |
| 9853959 | Kapczynski et al. | Dec 2017 | B1 |
| 9858576 | Song et al. | Jan 2018 | B2 |
| 9978046 | Lefebvre et al. | May 2018 | B2 |
| 10032146 | Caldwell | Jul 2018 | B2 |
| 10044647 | Karp et al. | Aug 2018 | B1 |
| 10050779 | Alness et al. | Aug 2018 | B2 |
| 10115155 | Haller et al. | Oct 2018 | B1 |
| 10157420 | Narayana et al. | Dec 2018 | B2 |
| 10187483 | Golub et al. | Jan 2019 | B2 |
| 10275602 | Bjorn et al. | Apr 2019 | B2 |
| 10402817 | Benkreira et al. | Sep 2019 | B1 |
| 10402818 | Zarakas et al. | Sep 2019 | B2 |
| 10417396 | Bawa et al. | Sep 2019 | B2 |
| 10423948 | Wilson et al. | Sep 2019 | B1 |
| 10460395 | Grassadonia | Oct 2019 | B2 |
| 10521798 | Song et al. | Dec 2019 | B2 |
| 10650448 | Haller et al. | May 2020 | B1 |
| 10963589 | Fakhraie et al. | Mar 2021 | B1 |
| 20010001856 | Gould et al. | May 2001 | A1 |
| 20010032183 | Landry | Oct 2001 | A1 |
| 20010051920 | Joao et al. | Dec 2001 | A1 |
| 20020016749 | Borecki et al. | Feb 2002 | A1 |
| 20020035539 | O'Connell | Mar 2002 | A1 |
| 20020038289 | Lawlor et al. | Mar 2002 | A1 |
| 20020095386 | Maritzen et al. | Jul 2002 | A1 |
| 20020143655 | Elston et al. | Oct 2002 | A1 |
| 20020169720 | Wilson et al. | Nov 2002 | A1 |
| 20030046246 | Klumpp et al. | Mar 2003 | A1 |
| 20030061163 | Durfield | Mar 2003 | A1 |
| 20030097331 | Cohen | May 2003 | A1 |
| 20030172040 | Kemper et al. | Sep 2003 | A1 |
| 20030195847 | Felger | Oct 2003 | A1 |
| 20030200179 | Kwan | Oct 2003 | A1 |
| 20030216997 | Cohen | Nov 2003 | A1 |
| 20030217001 | McQuaide et al. | Nov 2003 | A1 |
| 20040054591 | Spaeth et al. | Mar 2004 | A1 |
| 20040073903 | Melchione et al. | Apr 2004 | A1 |
| 20040078325 | O'Connor | Apr 2004 | A1 |
| 20040090825 | Nam et al. | May 2004 | A1 |
| 20040128243 | Kavanagh et al. | Jul 2004 | A1 |
| 20040148259 | Reiners et al. | Jul 2004 | A1 |
| 20040178907 | Cordoba | Sep 2004 | A1 |
| 20040225606 | Nguyen et al. | Nov 2004 | A1 |
| 20040263901 | Critelli et al. | Dec 2004 | A1 |
| 20050010483 | Ling | Jan 2005 | A1 |
| 20050014705 | Cheng et al. | Jan 2005 | A1 |
| 20050039041 | Shaw et al. | Feb 2005 | A1 |
| 20050060233 | Bonalle et al. | Mar 2005 | A1 |
| 20050114705 | Reshef et al. | May 2005 | A1 |
| 20050131815 | Fung et al. | Jun 2005 | A1 |
| 20050199714 | Brandt et al. | Sep 2005 | A1 |
| 20050224587 | Shin et al. | Oct 2005 | A1 |
| 20050228750 | Olliphant et al. | Oct 2005 | A1 |
| 20050273431 | Abel et al. | Dec 2005 | A1 |
| 20060046745 | Davidson | Mar 2006 | A1 |
| 20060059110 | Madhok et al. | Mar 2006 | A1 |
| 20060184456 | De Janasz | Aug 2006 | A1 |
| 20060202012 | Grano et al. | Sep 2006 | A1 |
| 20060235795 | Johnson et al. | Oct 2006 | A1 |
| 20060278698 | Lovett | Dec 2006 | A1 |
| 20070083463 | Kraft | Apr 2007 | A1 |
| 20070100773 | Wallach | May 2007 | A1 |
| 20070112673 | Protti | May 2007 | A1 |
| 20070123305 | Chen et al. | May 2007 | A1 |
| 20070143831 | Pearson et al. | Jun 2007 | A1 |
| 20070203836 | Dodin | Aug 2007 | A1 |
| 20070226086 | Bauman et al. | Sep 2007 | A1 |
| 20070255653 | Tumminaro et al. | Nov 2007 | A1 |
| 20070266257 | Camaisa et al. | Nov 2007 | A1 |
| 20080000052 | Hong et al. | Jan 2008 | A1 |
| 20080005037 | Hammad et al. | Jan 2008 | A1 |
| 20080017702 | Little et al. | Jan 2008 | A1 |
| 20080021787 | MacKouse | Jan 2008 | A1 |
| 20080029608 | Kellum et al. | Feb 2008 | A1 |
| 20080052226 | Agarwal et al. | Feb 2008 | A1 |
| 20080086398 | Parlotto | Apr 2008 | A1 |
| 20080115104 | Quinn | May 2008 | A1 |
| 20080149706 | Brown et al. | Jun 2008 | A1 |
| 20080154772 | Carlson | Jun 2008 | A1 |
| 20080191878 | Abraham | Aug 2008 | A1 |
| 20080208726 | Tsantes et al. | Aug 2008 | A1 |
| 20080229383 | Buss et al. | Sep 2008 | A1 |
| 20080244724 | Choe et al. | Oct 2008 | A1 |
| 20080260119 | Marathe et al. | Oct 2008 | A1 |
| 20080283590 | Oder et al. | Nov 2008 | A1 |
| 20080301043 | Unbehagen | Dec 2008 | A1 |
| 20090005269 | Martin et al. | Jan 2009 | A1 |
| 20090007231 | Kaiser et al. | Jan 2009 | A1 |
| 20090055269 | Baron | Feb 2009 | A1 |
| 20090055642 | Myers et al. | Feb 2009 | A1 |
| 20090112763 | Scipioni et al. | Apr 2009 | A1 |
| 20090132351 | Gibson | May 2009 | A1 |
| 20090205014 | Doman et al. | Aug 2009 | A1 |
| 20090228381 | Mik et al. | Sep 2009 | A1 |
| 20090287603 | Lamar et al. | Nov 2009 | A1 |
| 20090319638 | Faith et al. | Dec 2009 | A1 |
| 20100036769 | Winters et al. | Feb 2010 | A1 |
| 20100036906 | Song et al. | Feb 2010 | A1 |
| 20100063906 | Nelsen et al. | Mar 2010 | A1 |
| 20100082487 | Nelsen | Apr 2010 | A1 |
| 20100094735 | Reynolds et al. | Apr 2010 | A1 |
| 20100100470 | Buchanan et al. | Apr 2010 | A1 |
| 20100114768 | Duke et al. | May 2010 | A1 |
| 20100132049 | Vernal et al. | May 2010 | A1 |
| 20100228671 | Patterson | Sep 2010 | A1 |
| 20100274691 | Hammad et al. | Oct 2010 | A1 |
| 20100312700 | Coulter et al. | Dec 2010 | A1 |
| 20110023129 | Vernal et al. | Jan 2011 | A1 |
| 20110035318 | Hargrove et al. | Feb 2011 | A1 |
| 20110035596 | Attia et al. | Feb 2011 | A1 |
| 20110106698 | Isaacson et al. | May 2011 | A1 |
| 20110176010 | Houjou et al. | Jul 2011 | A1 |
| 20110178929 | Durkin et al. | Jul 2011 | A1 |
| 20110191239 | Blackhurst et al. | Aug 2011 | A1 |
| 20110196791 | Dominguez | Aug 2011 | A1 |
| 20110202462 | Keenan | Aug 2011 | A1 |
| 20110218849 | Rutigliano et al. | Sep 2011 | A1 |
| 20110247055 | Guo et al. | Oct 2011 | A1 |
| 20110276479 | Thomas | Nov 2011 | A1 |
| 20110307826 | Rivera et al. | Dec 2011 | A1 |
| 20120030109 | Dooley Maley et al. | Feb 2012 | A1 |
| 20120041881 | Basu et al. | Feb 2012 | A1 |
| 20120046994 | Reisman | Feb 2012 | A1 |
| 20120047072 | Larkin | Feb 2012 | A1 |
| 20120096534 | Boulos et al. | Apr 2012 | A1 |
| 20120101938 | Kasower | Apr 2012 | A1 |
| 20120124658 | Brudnicki et al. | May 2012 | A1 |
| 20120158590 | Salonen | Jun 2012 | A1 |
| 20120214577 | Petersen et al. | Aug 2012 | A1 |
| 20120227094 | Begen et al. | Sep 2012 | A1 |
| 20120239417 | Pourfallah et al. | Sep 2012 | A1 |
| 20120240235 | Moore | Sep 2012 | A1 |
| 20120254038 | Mullen | Oct 2012 | A1 |
| 20120259782 | Hammad | Oct 2012 | A1 |
| 20120265682 | Menon | Oct 2012 | A1 |
| 20120270522 | Laudermilch et al. | Oct 2012 | A1 |
| 20120296725 | Dessert et al. | Nov 2012 | A1 |
| 20130031006 | McCullagh et al. | Jan 2013 | A1 |
| 20130046690 | Calman et al. | Feb 2013 | A1 |
| 20130055378 | Chang et al. | Feb 2013 | A1 |
| 20130080219 | Royyuru et al. | Mar 2013 | A1 |
| 20130091452 | Sorden et al. | Apr 2013 | A1 |
| 20130103391 | Millmore et al. | Apr 2013 | A1 |
| 20130117696 | Robertson et al. | May 2013 | A1 |
| 20130132854 | Raleigh et al. | May 2013 | A1 |
| 20130151405 | Head et al. | Jun 2013 | A1 |
| 20130173402 | Young et al. | Jul 2013 | A1 |
| 20130174244 | Taveau et al. | Jul 2013 | A1 |
| 20130218758 | Koenigsbrueck et al. | Aug 2013 | A1 |
| 20130226813 | Voltz | Aug 2013 | A1 |
| 20130254115 | Pasa et al. | Sep 2013 | A1 |
| 20130346302 | Purves et al. | Dec 2013 | A1 |
| 20130346306 | Kopp | Dec 2013 | A1 |
| 20130346310 | Burger et al. | Dec 2013 | A1 |
| 20140006209 | Groarke | Jan 2014 | A1 |
| 20140019352 | Shrivastava | Jan 2014 | A1 |
| 20140040144 | Plomske et al. | Feb 2014 | A1 |
| 20140053069 | Yan | Feb 2014 | A1 |
| 20140067503 | Ebarle Grecsek et al. | Mar 2014 | A1 |
| 20140067683 | Varadarajan | Mar 2014 | A1 |
| 20140076967 | Pushkin et al. | Mar 2014 | A1 |
| 20140108263 | Ortiz et al. | Apr 2014 | A1 |
| 20140114855 | Bajaj et al. | Apr 2014 | A1 |
| 20140123312 | Marcotte | May 2014 | A1 |
| 20140129357 | Goodwin | May 2014 | A1 |
| 20140129448 | Aiglstorfer | May 2014 | A1 |
| 20140143886 | Eversoll et al. | May 2014 | A1 |
| 20140149368 | Lee et al. | May 2014 | A1 |
| 20140172707 | Kuntagod et al. | Jun 2014 | A1 |
| 20140198054 | Sharma et al. | Jul 2014 | A1 |
| 20140200957 | Biggs | Jul 2014 | A1 |
| 20140207672 | Kelley | Jul 2014 | A1 |
| 20140237236 | Kalinichenko et al. | Aug 2014 | A1 |
| 20140248852 | Raleigh et al. | Sep 2014 | A1 |
| 20140258104 | Harnisch | Sep 2014 | A1 |
| 20140258110 | Davis et al. | Sep 2014 | A1 |
| 20140279309 | Cowen et al. | Sep 2014 | A1 |
| 20140279474 | Evans et al. | Sep 2014 | A1 |
| 20140306833 | Ricci | Oct 2014 | A1 |
| 20140337188 | Bennett et al. | Nov 2014 | A1 |
| 20140344149 | Campos | Nov 2014 | A1 |
| 20140344153 | Raj et al. | Nov 2014 | A1 |
| 20140344877 | Ohmata et al. | Nov 2014 | A1 |
| 20140357233 | Maximo et al. | Dec 2014 | A1 |
| 20140372308 | Sheets | Dec 2014 | A1 |
| 20140379575 | Rogan | Dec 2014 | A1 |
| 20150019944 | Kalgi | Jan 2015 | A1 |
| 20150026026 | Calman et al. | Jan 2015 | A1 |
| 20150026049 | Theurer et al. | Jan 2015 | A1 |
| 20150026057 | Calman et al. | Jan 2015 | A1 |
| 20150032625 | Dill et al. | Jan 2015 | A1 |
| 20150032626 | Dill et al. | Jan 2015 | A1 |
| 20150032627 | Dill et al. | Jan 2015 | A1 |
| 20150039457 | Jacobs et al. | Feb 2015 | A1 |
| 20150046338 | Laxminarayanan et al. | Feb 2015 | A1 |
| 20150046339 | Wong et al. | Feb 2015 | A1 |
| 20150082042 | Hoornaert et al. | Mar 2015 | A1 |
| 20150100477 | Salama et al. | Apr 2015 | A1 |
| 20150106239 | Gaddam et al. | Apr 2015 | A1 |
| 20150112870 | Nagasundaram et al. | Apr 2015 | A1 |
| 20150121500 | Venkatanaranappa et al. | Apr 2015 | A1 |
| 20150134700 | MacKlem et al. | May 2015 | A1 |
| 20150149357 | Ioannidis et al. | May 2015 | A1 |
| 20150178724 | Ngo et al. | Jun 2015 | A1 |
| 20150180836 | Wong et al. | Jun 2015 | A1 |
| 20150186856 | Weiss et al. | Jul 2015 | A1 |
| 20150193764 | Haggerty et al. | Jul 2015 | A1 |
| 20150193866 | Van Heerden et al. | Jul 2015 | A1 |
| 20150199679 | Palanisamy et al. | Jul 2015 | A1 |
| 20150199689 | Kumnick et al. | Jul 2015 | A1 |
| 20150213435 | Douglas et al. | Jul 2015 | A1 |
| 20150220999 | Thornton et al. | Aug 2015 | A1 |
| 20150221149 | Main et al. | Aug 2015 | A1 |
| 20150229622 | Grigg et al. | Aug 2015 | A1 |
| 20150248405 | Rudich et al. | Sep 2015 | A1 |
| 20150254647 | Bondesen et al. | Sep 2015 | A1 |
| 20150254655 | Bondesen et al. | Sep 2015 | A1 |
| 20150286834 | Ohtani et al. | Oct 2015 | A1 |
| 20150312038 | Palanisamy | Oct 2015 | A1 |
| 20150319158 | Kumnick | Nov 2015 | A1 |
| 20150319198 | Gupta et al. | Nov 2015 | A1 |
| 20150339663 | Lopreiato et al. | Nov 2015 | A1 |
| 20150339664 | Wong et al. | Nov 2015 | A1 |
| 20150379508 | Van | Dec 2015 | A1 |
| 20160026997 | Tsui et al. | Jan 2016 | A1 |
| 20160028550 | Gaddam et al. | Jan 2016 | A1 |
| 20160028735 | Francis et al. | Jan 2016 | A1 |
| 20160036790 | Shastry et al. | Feb 2016 | A1 |
| 20160042381 | Braine et al. | Feb 2016 | A1 |
| 20160063497 | Grant, IV | Mar 2016 | A1 |
| 20160078428 | Moser et al. | Mar 2016 | A1 |
| 20160092696 | Guglani et al. | Mar 2016 | A1 |
| 20160092870 | Salama et al. | Mar 2016 | A1 |
| 20160092872 | Prakash et al. | Mar 2016 | A1 |
| 20160092874 | O'Regan et al. | Mar 2016 | A1 |
| 20160098692 | Johnson et al. | Apr 2016 | A1 |
| 20160109954 | Harris et al. | Apr 2016 | A1 |
| 20160119296 | Laxminarayanan et al. | Apr 2016 | A1 |
| 20160125409 | Meredith et al. | May 2016 | A1 |
| 20160140221 | Park et al. | May 2016 | A1 |
| 20160155156 | Gopal et al. | Jun 2016 | A1 |
| 20160171483 | Luoma et al. | Jun 2016 | A1 |
| 20160189121 | Best et al. | Jun 2016 | A1 |
| 20160239437 | Le et al. | Aug 2016 | A1 |
| 20160260176 | Bernard et al. | Sep 2016 | A1 |
| 20160267467 | Rutherford et al. | Sep 2016 | A1 |
| 20160294879 | Kirsch | Oct 2016 | A1 |
| 20160314458 | Douglas et al. | Oct 2016 | A1 |
| 20160321669 | Beck et al. | Nov 2016 | A1 |
| 20160328522 | Howley | Nov 2016 | A1 |
| 20160358163 | Kumar et al. | Dec 2016 | A1 |
| 20160379211 | Hoyos et al. | Dec 2016 | A1 |
| 20170004506 | Steinman et al. | Jan 2017 | A1 |
| 20170011389 | McCandless et al. | Jan 2017 | A1 |
| 20170024393 | Choksi et al. | Jan 2017 | A1 |
| 20170068954 | Hockey et al. | Mar 2017 | A1 |
| 20170078299 | Castinado et al. | Mar 2017 | A1 |
| 20170078303 | Wu | Mar 2017 | A1 |
| 20170091759 | Selfridge et al. | Mar 2017 | A1 |
| 20170132633 | Whitehouse | May 2017 | A1 |
| 20170147631 | Nair et al. | May 2017 | A1 |
| 20170161724 | Lau | Jun 2017 | A1 |
| 20170249478 | Lovin | Aug 2017 | A1 |
| 20170344991 | Mark et al. | Nov 2017 | A1 |
| 20170352028 | Vridhachalam et al. | Dec 2017 | A1 |
| 20170364898 | Ach et al. | Dec 2017 | A1 |
| 20180005323 | Grassadonia | Jan 2018 | A1 |
| 20180006821 | Kinagi | Jan 2018 | A1 |
| 20180025145 | Morgner et al. | Jan 2018 | A1 |
| 20180053200 | Cronin et al. | Feb 2018 | A1 |
| 20180088909 | Baratta et al. | Mar 2018 | A1 |
| 20180158137 | Tsantes et al. | Jun 2018 | A1 |
| 20180270363 | Guday et al. | Sep 2018 | A1 |
| 20190007381 | Isaacson et al. | Jan 2019 | A1 |
| 20190171831 | Xin | Jun 2019 | A1 |
| 20190197501 | Senci et al. | Jun 2019 | A1 |
| 20190220834 | Moshal et al. | Jul 2019 | A1 |
| 20190228173 | Gupta et al. | Jul 2019 | A1 |
| 20190318122 | Hockey et al. | Oct 2019 | A1 |
| 20190333061 | Jackson et al. | Oct 2019 | A1 |
| 20190347442 | Marlin et al. | Nov 2019 | A1 |
| 20190356641 | Isaacson | Nov 2019 | A1 |
| 20190362069 | Park et al. | Nov 2019 | A1 |
| 20190370798 | Hu et al. | Dec 2019 | A1 |
| 20190392443 | Piparsaniya et al. | Dec 2019 | A1 |
| 20200005347 | Boal | Jan 2020 | A1 |
| 20200074552 | Shier et al. | Mar 2020 | A1 |
| 20200090179 | Song et al. | Mar 2020 | A1 |
| 20200118114 | Benkreira et al. | Apr 2020 | A1 |
| 20200118133 | Schmidt et al. | Apr 2020 | A1 |
| 20200286057 | Desai | Sep 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2 441 156 | Feb 2008 | GB |
| 20160015375 | Feb 2016 | KR |
| WO-9013096 | Nov 1990 | WO |
| WO-0072245 | Nov 2000 | WO |
| WO-03038551 | May 2003 | WO |
| WO-2004081893 | Sep 2004 | WO |
| WO-2004090825 | Oct 2004 | WO |
| WO-2009151839 | Dec 2009 | WO |
| WO-2012054148 | Apr 2012 | WO |
| WO-2015103443 | Jul 2015 | WO |
| WO-2015135131 | Sep 2015 | WO |
| WO-2018005635 | Jan 2018 | WO |
| Entry |
|---|
| IEEE Xplore; 2009 First Asian Himalayas International Conference on Internet: Emergence of Payment Systems in the age of Elcetronic Commerce.; The state off Art. Author S Singh Nov. 1, 2009 pp. 1-18 (Year: 2009). |
| Microsoft, “Automatically summarize a document”, 2016. 3 pages. |
| Cronian, Darrin “Credit card companies Freeze Spending whilst Abroad”, published Jun. 9, 2007, Available at: http://www.travel-rants.com/2007/06/09/credit-card-companies-freeze-spending-whilst-abroad/. |
| Austin Telco Federal Credit Union, “Lost or Stolen Cards”, www.atfcu.org/lost-stolen-cards.htm; Apr. 9, 2004. 6 pages. |
| BancFirst, “Lost Card”, https://www.bancfirst.com/contact.aspx, Oct. 28, 2003. 1 page. |
| Eastern District of Virginia United States Bankruptcy Court, “CM/ECF Internet Credit Card Payment Guide”, https://www.vaeb.uscourts.gov/wordpress/?page_id=340, Mar. 16, 2005. 12 pages. |
| Fort Knox Federal Credit Union, “Lost or Stolen VISA Card”, http://www.fortknoxfcu.org/loststolen.html, Feb. 1, 2001. 2 pages. |
| Merrick Bank, “Reporting Lost or Stolen Card Help”, http://www.merrickbank.com/Frequent-Asked-Questions/Report-Stolen-Card.aspx, Aug. 9, 2004. 1 page. |
| RBL Bank, “If Your Card is Lost or Stolen”, http://www.rblbank.com/pdfs/CreditCard/FAQs.pdf, Oct. 1, 2002. 2 pages. |
| State Employees Credit Union, “Lost or Stolen Account Info”, https://www.secumd.org/advice-planning/money-and-credit/privacy-fraud-protection/lost-or-stolen-account-info.aspx, May 20, 2005. 2 pages. |
| Union Bank & Trust, “Report Lost or Stolen Cards”, http://www.ubt.com/security-fraud/report-lost-or-stolen-cards, Jul. 10, 2005. 13 pages. |
| Asb, “How to command your cards with ASB Card Control” Apr. 20, 2015, https://www.youtube.com/watch?v=O1sfxvVUL74 (Year: 2015). |
| Authorize.Net. Authorize.Net Mobile Application: iOS User Guide. Sep. 2015. Authorize.Net LLC. Ver.2.0, 1-23. https://www.authorize.net/content/dam/anet-redesign/documents/iosuserguide.pdf (Year: 2015). |
| Co-Op Think, Rachna Ahlawat at Co-Op Think—Evolution Sessions from THINK14, Dec. 22, 2014, 26:22 https://www.youtube.com/watch?v=yEp-qfZoPhl (Year: 2014). |
| Fiserv. CardValet: Mobile Application Training. Fiserv, Inc. 1-93. https://www.westernbanks.com/media/1664/ cardvalet-application .pdf (Year: 2015). |
| IP.com Search Query; May 5, 2020 (Year: 2020). |
| Konsko: “Credit Card Tokenization: Here's What You Need to Know”, Credit Card Basics, Credit Card—Advertisement Nerdwallet (Year: 2014). |
| Notre Dame FCU “Irish Card Shield: How to Control Transaction Types” Jan. 15, 2016, 0:27, https://youtube.com/watch?v=0eZG1c6Bn38 (Year: 2016). |
| PCM Credit Union, “CardValet Tutorial” Jun. 24, 2015, https://www.youtube.com/watch?v=uGPh9Htw0Wc (Year: 2015). |
| Purchasing charges ahead. (1994). Electronic Buyers' News,, 68. Retrieved from https://dialog.proquest.com/professional/docview/681599288?accountid=131444 on Nov. 13, 2020 (Year: 1994). |
| Number | Date | Country | |
|---|---|---|---|
| 62588756 | Nov 2017 | US |
