Patent Grant
11823205
The present disclosure relates generally to the field of tokenization. More particularly, the present disclosure relates to systems and methods for storing and managing electronic tokens.
Tokenization is often used to replace sensitive information with a non-sensitive equivalent having limited extrinsic value (i.e., an electronic token). The electronic token may then be resolved by a central entity in order to derive the sensitive information. For instance, an electronic token may be used in place of credit card information to initiate payment activity. A merchant receiving such an electronic payment token may provide the token to a central entity and receive account information for processing the payment based on the token. Along with providing improved security for electronic transactions, electronic tokens may also provide enhanced transaction efficiency, increase service transparency, and enable various third party payment methods.
Various financial networks utilize tokenization for card accounts to initiate secured payments via tokens. Upon issuing the token, the financial network may store the issued token and any associated card account information within a storage location (i.e., a token vault). However, the data structure for each storage location is not consistent and the functionality varies between financial networks. Thus, it may be difficult for the financial networks and associated financial institutions to access authorized information stored across multiple storage locations, such as to provision a token or perform token life cycle management actions. Further, storage locations supported by the financial networks may not support tokenization of non-card domains, such as demand deposit accounts (DDAs) or Automated Clearing House (ACH) transactions.
One embodiment of the present disclosure relates to a computer system. The computer system includes a token repository configured to store payment tokens, and a server system. The server system includes a processor and instructions stored in non-transitory machine-readable media, the instructions configured to cause the server system to receive a request to provision a payment token based on a financial product, wherein the request includes information related to the financial product, provision a payment token based on the token request, including authenticating the financial product based on the financial product information and generating the payment token upon authenticating the financial product, wherein the payment token is useable to make a payment via the financial product, and store the payment token in the token repository.
Another embodiment of the present disclosure relates to a computer system. The computer system includes a token repository configured to store payment tokens, and a server system. The server system includes a processor and instructions stored in non-transitory machine-readable media, the instructions configured to cause the server system to receive information related to a payment token stored in the token repository, update the status of the stored payment token based on the information, and upon updating the status of the payment token, send a notification to a user of the payment token indicating that the status of the stored payment token has been updated.
Another embodiment of the present disclosure relates to a computer system. The computer system includes a token repository configured to store a payment token, and a server system. The server system includes a processor and instructions stored in non-transitory machine-readable media, the instructions configured to cause the server system to receive a request to authorize a transaction from a requesting entity, wherein the transaction was initiated based on the stored payment token, and wherein the payment token includes encrypted information related to a financial product, authorize the transaction based on the payment token and authorization rules stored in memory of the computer system, including de-tokenizing the payment token to identify the financial product information, and upon authorizing the transaction, send the financial product information to the requesting entity, wherein the financial product information is useable by the requesting party to process the transaction.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the disclosure will become apparent from the description, the drawings, and the claims, in which:
Before turning to the figures which illustrate example embodiments, it should be understood that the application is not limited to the details or methodology set forth in the following description or illustrated in the figures. It should also be understood that the phraseology and terminology employed herein is for the purpose of description only and should not be regarded as limiting.
Referring generally to the Figures, a token management system is shown. The token management system includes a token vault computer system. The token vault computer system is configured to manage and store electronic tokens. The token vault computer system may also be configured to provision electronic tokens based on information provided to the token vault computer system. The token vault computer system may be configured to provision tokens (e.g., payment tokens) based on payment information (e.g., a personal account number, a credit card number, etc.) related to a customer financial product. Provisioning the payment token may include authenticating the associated financial product, determining eligibility of the financial product for tokenization, generating the token based on the provided payment information, and linking the generated token to the associated financial product. The token vault computer system may also be configured to provision tokens based on non-payment information, such as a customer address, social security number, date of birth, or any other information.
In example embodiments, the payment tokens may be utilized to facilitate payments to merchants. In example embodiments, payment tokens may be surrogate values that replace the primary account number (PAN) associated with a payment card, such as a credit card, debit card, stored value card, etc. Payment tokens may pass basic validation rules of an account number. Hence, the payment token for a credit card in many respects “looks like” a real credit card number, but in fact is only a token. As part of the token generation process, steps are taken such that the generated payment token does not have the same value as or conflict with a real primary account number (e.g., a real credit card number). Payment tokens may be provisioned to various locations for use in various types of payment scenarios, including remote storage at a merchant (e.g., a card-on-file database) for on-line transactions with the merchant, a secure storage element (“secure element”) located in a payment card for a point-of-sale transaction using the payment card, local device storage (e.g., internal memory of a mobile device) for a mobile/digital wallet transaction, and so on.
In example embodiments, to process payment transactions, a payment is processed using a payment token in lieu of a primary account number (e.g., the 16-digit account number on the front of a credit card). The merchant obtains the payment token from a customer device or from the payment card, and then submits the payment token through a payment network to a computing system associated with a card network (e.g., Visa®, MasterCard®, American Express®, Discover®, Diners Club®, etc.). The card network computing system (e.g., network association computer system) de-tokenizes the payment token to obtain the PAN, i.e., replaces the payment token for its associated PAN value based on the payment token-to-PAN mapping information stored in a token database (sometimes referred to as a “token vault”). The card network computing system then transmits the PAN to the card issuer (e.g., the customer's financial institution) for processing in a manner similar to a traditional credit card transaction. For example, the card issuer may approve the transaction, in which case the transaction with the merchant is completed and payment to the merchant is made. The token database may also maintain other information that may be used to apply restrictions or other controls during transaction processing.
In example embodiments, processing payment transactions using such payment tokens provides enhanced security in connection with the payment card transactions. The payment tokens may be limited to use, e.g., only in connection with a specific merchant or a specific channel (e.g., payment via a specific mobile wallet). For example, in the event of a data breach at a merchant, the risk of subsequent fraud is reduced because only the payment tokens are exposed instead of primary account numbers. In this example, the payment tokens are merchant-specific and therefore cannot be used at other merchants. Although the examples provided herein relate primarily to the use of payment tokens (which may be used to originate payment transactions), the systems and methods described herein may also be used with non-payment tokens (which may be used for ancillary processes, such as loyalty tracking).
The token vault computer system may also be configured to manage the life cycle of each stored token. As part of the life cycle management, the token vault computer system may be configured to activate, de-activate, suspend, resume, and expire the stored token. The token vault computer system may also be configured to authorize a transaction using the token. The token vault computer system may authorize a transaction based on the token and other information related to an associated financial product. Once authorized, the token vault computer system may de-tokenize (e.g., resolve) the token and provide account information to the requesting party in order to process the transaction.
The token vault computer system may also include a token repository for storing the tokens. The token vault computer system may automatically store tokens generated by the token vault computer system in the token repository. The token vault computer system may also receive tokens that are generated by other entities and store the third party tokens in the token repository. The token vault computer system may convert the received third party tokens to a format similar to the generated payment tokens prior to storing the third party tokens in the token repository.
Referring to
The token management system 100 may include, among other systems, a token vault computer system 110, a network association computer system 130, an account holder computer system 140, an account issuer computer system 150, and a merchant computer system 160. In one embodiment, the systems are each owned and operated by a separate entity. In other embodiments, two or more systems may be combined or two or more systems may be owned or operated by a single entity. The systems may communicate through network 170. The network 170 may be a single communication network configured to communicatively connect each of the systems, or the network 170 may include a plurality of networks each connecting two or more systems. The network 170 may include one or more of the Internet, a cellular network, Wi-Fi, Wi-Max, a proprietary banking network, or any other type of wired or wireless network.
The systems may each include a computer system (e.g., one or more servers each with one or more processing circuits), each of which include a processor and memory. The processors may be implemented as application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. The memory may be one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memory may be or include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory may include data base components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory may be communicably connected to the processor and include computer code or instructions for executing one or more processes described herein.
The token vault computer system 110 is configured to at least provision, store, and manage electronic tokens. The token vault computer system 110 may be provided by a financial institution, such as a bank offering a variety of financial accounts. In an example embodiment, the token vault computer system 110 is provided by the account issuer computer system 150. In some embodiments, the token vault computer system 110 is at least partially provided by the network association computer system 130, and any operations herein attributed to the token vault computer system 110 may be performed by the account issuer computer system 150 and/or network association computer system 130. The token vault computer system 110 may be configured to communicate with any of the network association computer system 130, account holder computer system 140, account issuer computer system 150, and merchant computer system 160, and may be configured to communicate with each of these systems via a separate and secure network.
It should be noted that the operations attributed to the token vault computer system 110, including the operations attributed to the token provisioning logic 112, transaction authorization logic 114, life cycle management logic 116, token inquiry logic 118, and token notification logic 120, may be performed by the network association computer system 130. including authenticating the token request, determining token eligibility, generating the token, providing terms and conditions for the token, assigning the token to an entity or financial product, and generating limited use keys for the token.
The token vault computer system 110 includes token provisioning logic 112, transaction authorization logic 114, life cycle management logic 116, token inquiry logic 118, and token notification logic 120. Such logic may be implemented in a machine (e.g., one or more networked computer servers) comprising machine-readable media having instructions stored therein which are executed by the machine to perform the operations described herein. For instance, such logic may be implemented and executed to manage electronic tokens as part of the token vault computer system 110. It should be noted that the token vault computer system 110 may be operated by the account issuer computer system 150. For instance, the account issuer computer system 150 may issue one or more financial accounts or products to an account holder, and the token vault computer system 110 may be operated by the account issuer computer system 150 and configured to manage various tokens related to those financial accounts. In other embodiments, the token vault computer system 110 may be operated separately from the account issuer computer system 150. In these embodiments, the token vault computer system 110 may be operated by a separate financial institution from the account holder and configured to provision and manage various tokens related to the financial accounts or products issued by the account issuer computer system 150.
The token provisioning logic 112 may be executed to provision a token. The token may be provisioned based on a tokenization request received at the token vault computer system 110. The tokenization request may be received from a user (i.e., an account holder, customer, etc.) of the token vault computer system 110, including via the account holder computer system 140. The tokenization request includes information that may be used to provision the token, including any data or information which is requested to be tokenized (i.e., replaced by a unique identifier). The token provisioning logic 112 is configured to tokenize payment information (i.e., account information for a financial product) and non-payment information (e.g., personal information, preferences, etc.). The tokenization request may also include information identifying the requestor or other information that may be used to authenticate the token.
The token provisioning logic 112 may provision a payment token based on payment information provided with the token request. The payment token may then be used in lieu of actual account information (i.e., information that has been tokenized) to initiate a payment from an associated financial product (e.g., credit card account, demand deposit account, line of credit, etc.). Provisioning a token based on payment information for a financial product may include authenticating the associated financial product, determining eligibility of the financial product and/or the token, generating the token, and linking the token to the financial product. The provisioned token may be intended to replace sensitive account information for the associated financial product, such as an account number, card number, or other identifying information. For instance, an account holder (i.e., the account holder computer system 140) may request a payment token from the token vault computer system 110 in order to make a payment using a customer financial product associated with the token vault computer system 110 (e.g., provided by the account issuer computer system 150).
The token provisioning logic 112 may also be configured to authenticate a tokenization request as part of the token provisioning, including authenticating an associated financial product (e.g., verifying that the financial product is associated with the account holder or other requesting party). In an example embodiment, the token vault computer system 110 receives a request from the account holder computer system 140 to provision a payment token associated with a financial product (e.g., credit card, debit card, checking account, etc.) of the account holder. In this embodiment, the token provisioning logic 112 is configured to authenticate the financial product prior to generating the payment token. The financial product may have been issued or provided by the token vault computer system 110, the account issuer computer system 150, or another financial entity. The tokenization request may include an original payment credential related to the financial product or other data that may be used by the token provisioning logic 112 to authenticate the product. The token provisioning logic 112 may also request additional information from the requesting party (e.g., the account holder) to authenticate the financial product. In other embodiments, the token provisioning logic 112 is configured to send communication to the issuer of the financial product (e.g., account issuer computer system 150) requesting an authentication confirmation. The token vault computer system 110 may also store authentication rules or other information that may be used by the token provisioning logic 112 to authenticate the financial product. Similarly, the token provisioning logic 112 may also authenticate the token requestor or any other associated entity, as well as any other (non-payment) information received as part of the request.
The token provisioning logic 112 may also be configured to determine token eligibility based on the token request, which may include whether a particular token is available for use. In an example embodiment, the provisioned token is intended to be a unique identifier for the tokenized information. In this embodiment, the token provisioning logic 112 may determine that a particular token is ineligible if an identical token has been used previously and/or if an identical token is currently active. The token provisioning logic 112 may then select a new unique identifier. The token provisioning logic 112 may also determine eligibility of the information for tokenization. For instance, the token provisioning logic 112 may determine whether a particular financial product can be tokenized to generate a payment token. For instance, the token provisioning logic 112 may be configured to determine the type of financial product (e.g., credit card, debit card, bank account, etc.) based on the request and determine token eligibility based on the type of financial product. Token eligibility may also be based on the issuing entity, the account holder, the requesting party, the type of transaction associated with a payment token, or other information that may be exchanged as part of a financial transaction. The token provisioning logic 112 may also request additional information from the requesting party in order to determine token eligibility.
In an example embodiment, the token vault computer system 110 stores eligibility rules for determining token eligibility, and the token provisioning logic 112 is configured to determine token eligibility based on the eligibility rules. The eligibility rules may be determined by the token vault computer system 110. The eligibility rules may also be determined by an issuer of a financial product, by a user providing the information, or another authorized party described herein. In other embodiments, the token provisioning logic 112 is configured to request confirmation of token eligibility from a separate entity. For instance, the token provisioning logic 112 may receive confirmation of token eligibility from the issuer of the financial product (e.g., the account issuer computer system 150).
Upon authenticating the information provided in the tokenization request and confirming token eligibility, the token provisioning logic 112 may be configured to generate the token. The token may be a unique identifier that replaces any sensitive or otherwise protected information with non-sensitive (e.g., non-financial) information. A payment token, for instance, is a non-financial identifier that replaces financial product information and may be used, pending activation, as a payment credential to initiate a payment using the financial product. The token may be unique to a particular requestor, token vault, financial product, token issuer, financial product issuer, account holder, and/or transaction. In an example embodiment, a payment token is generated based on a financial product such that the payment token does not have the same value as and does not otherwise conflict with the primary account number (PAN) associated with the financial product, or the PAN of another account holder. In some embodiments, the generated payment token is useable on a mobile device (e.g., tablet, cellular phone, smart watch, etc.) to make a payment. For instance, the payment token may be generated for use within a mobile wallet associated with one or more financial products. In these embodiments, the payment token may also be unique to the mobile device, such that a payment token is generated per card, per device, and per requestor (e.g., account holder).
The token generated by the token provisioning logic 112 may be any type of token, code, or other identifier that may be exchanged between two or more parties in order to securely transmit sensitive information. The token may be generated based on the particular requirements of the token, which may be provided by any of the parties described herein, including the token requestor. A payment token, for instance, may be a code or other identifier suitable for use as a payment credential, such as a numerical code, a barcode, a quick response (QR) code, or an RF signal. The token provisioning logic 112 may include one or more tokenization algorithms configured to generate the payment token. In an example embodiment, the payment token is a tokenized sixteen digit number. For instance, where the financial product is a credit or debit card account, the tokenized sixteen digit number may be used as a payment credential in place of the original sixteen digit number of the credit or debit card.
In one embodiment, the payment token has a unique BIN (e.g., the first four digits of the original card number), but retains the same last four digits as the original card number in order to accurately match the payment token to the account holder (i.e., the product owner). In this embodiment, the remaining numbers may be generated by the token provisioning logic 112 using various tokenization algorithms. In another embodiment, the payment token is a surrogate value for a PAN that is consistent with ISO 8583 message requirements. In this embodiment, the payment token may be a 13 to 19-digit numeric value that is compliant with basic validation rules of an account number.
The token provisioning logic 112 may also be configured to provide (e.g., retrieve) any terms and conditions associated with a generated token in response to a tokenization request. The terms and conditions may be provided to the token requestor. The token vault computer system 110 may require the requestor to consent to the terms and conditions prior to generating the payment token. The terms and conditions may be stored at the token vault computer system 110, such as being stored in the token history 124 or other memory of the token vault computer system 110. The terms and conditions may provide how a payment token may be used, for instance, such as by specifying a type or number of transactions allowed, a preferred method of payment, an expiration date for the token, or any other use restrictions. The token provisioning logic 112 may also be configured to provide graphics associated with the payment token based on the tokenization request.
The token provisioning logic 112 may also be configured to link (i.e., assign) a generated token to a particular entity or financial product. For instance, a payment token may be linked to an associated financial product such that the payment token may be re-used in a future transaction to make a payment using the same financial product. The payment token may also be linked to the financial product such that the financial product and/or the account holder must be authenticated in order to use the payment token in a transaction. The payment token may also be linked to any of the token requestor, an account holder, an associated merchant, a financial institution, or any other entity or product described herein.
The token provisioning logic 112 may also be configured to generate limited use keys (LUKs) as part of the token provisioning. For instance, the token provisioning logic 112 may generate an LUK based on the tokenization request. LUKs are payment tokens that are available for a limited use. The LUKs generated by the token provisioning logic 112 may be derived from or based on a master domain key (e.g., the payment token) that is associated with the financial product. The LUKs may be generated such that they expire or become unusable based on determined thresholds. For instance, each LUK may have a time to live (TTL) before the LUK expires and can no longer be used as a payment credential. The LUKs may also be set to expire based on a threshold transaction velocity (i.e., speed by which funds are transmitted) or a threshold number of transactions. The token vault computer system 110 may be configured to determine these thresholds based on any number of factors, including the financial product and the account holder. The token vault computer system 110 may also be configured to refresh or replenish any expired LUKs as may be necessary or desired.
In an example embodiment, the financial product relates to a payment card having
The transaction authorization logic 114 may be executed to authorize a transaction in which a token is used. For instance, the token vault computer system 110 may receive a payment token from a recipient of the payment token such as merchant computer system 160 in order to validate the payment token and provide payment details based on the payment token. In particular, the transaction authorization logic 114 is configured to validate the payment token based on authorization rules. For instance, the transaction authorization logic 114 may validate that the payment token was generated by the token vault computer system 110 (i.e., the token provisioning logic 112) or another issuing entity (e.g., account issuer computer system 150). The transaction authorization logic 114 may also validate the payment token by verifying that the payment token was received from the account holder computer system 140 or another entity to which the payment token was issued by the token vault computer system 110. The transaction authorization logic 114 may also validate a token based on information received with the token. For instance, the transaction authorization logic 114 may validate the token by matching a passkey (or other information) that is received with the token to similar information stored at the token vault computer system 110 and associated with the token.
The authorization rules used by the transaction authorization logic 114 may be included as part of the transaction authorization logic 114 or stored in the token vault computer system 110 (e.g., in token history 124) and retrieved by the transaction authorization logic 114 to validate the payment token and authorize the transaction. The authorization rules may be determined by the token vault computer system 110. For instance, the authorization rules may be generated based on the payment token by the token provisioning logic 112 when the payment token is generated. The authorization rules may also be based on the financial product, the account holder, or any other information related to the payment token and described herein. The authorization rules may also be received and stored by the token vault computer system 110 from another entity, such as the issuer of the financial product where the issuer is an entity other than the token vault computer system 110. For instance, the transaction authorization logic 114 may be configured to request the authorization rules from an issuing entity upon receiving the payment token from a party requesting authorization.
The transaction authorization logic 114 may be configured to de-tokenize a payment token during authorization of the transaction. For instance, the transaction authorization logic 114 may de-tokenize the payment token to determine a primary account number (PAN) or other original account information upon validating the payment token. The transaction authorization logic 114 may then provide the de-tokenized original account information to the entity requesting the authorization, such as the merchant computer system 160 or the network association computer system 130, so that the requesting entity may proceed with processing the transaction. The transaction authorization logic 114 may be configured to encrypt the original account information prior to prevent unwanted use of the original account information. In other embodiments, such as where the token vault computer system 110 is the issuer of the financial product, the token vault computer system 110 may process the transaction based on the original account information derived from the payment token.
The life cycle management logic 116 may be executed to perform various actions related to the life cycle of the token. The actions may transition the token through various states of the token life cycle. For instance, the life cycle management logic 116 may be configured to activate, de-activate, suspend, resume, update, or expire the token once the token is provisioned. The life cycle management logic 116 may be configured to perform any of these actions in response to a request from the token requestor or the owner of the token (i.e., an account holder), or a party to the transaction having the necessary authorization. When the token is updated or a life cycle action is performed in response to a request, the life cycle management logic 116 may be configured to send confirmation of the update to the party requesting the update. The life cycle management logic 116 may also be configured to automatically perform any of the actions described herein, such as in response to another event or action. The life cycle management logic 116 is configured to send a notification to the token requestor (e.g., the account holder) when the payment token is updated or a life cycle action is performed based on a non-request action or event. The token may be stored in the token repository 122 and all actions performed by the life cycle management logic 116 may be performed at the token repository 122. All actions performed by the life cycle management logic 116 and all changes to the token may be recorded and stored at the token history 124.
The life cycle management logic 116 may also be configured to activate the token. The token vault computer system 110 may be configured to provide token-related information in exchange for the activated token. For instance, once provisioned, a payment token may require activation so that the payment token is useable to make a payment. The token vault computer system 110 may accept the activated payment token in exchange for payment information required to process a payment. In some embodiments, the token may also be automatically activated by the token provisioning logic 112 upon provisioning the token. Once the payment token is activated, the life cycle management logic 116 may also be configured to de-activate the payment token such that the payment token is no longer useable for making a payment. A token may be permanently or temporarily de-activated. When the token is de-activated, the token may not be useable to receive token-related information from the token vault computer system 110. For instance, the life cycle management logic 116 may be used to temporarily de-activate (i.e., suspend) a token. The life cycle management logic 116 is also configured to re-activate (i.e., resume) a suspended token. When re-activated, a payment token, for instance, is again active and may be used to make a payment. The life cycle management logic 116 is also configured to expire the token. The token may be expired based on various event or time-based thresholds, such as a number of uses, or a time since provisioning or after first use. The token may be expired based on a preference of the account holder, for instance. When the token is expired, the life cycle management logic 116 may renew the payment token or the payment token may be de-activated.
The life cycle management logic 116 is also configured to update the token, which may include updating any information associated with the token. For instance, the life cycle management logic 116 may be configured to update a payment token by updating the payment information on which the payment token is based. The payment token may also be updated to be associated with a new or additional financial product. Updating the token may also include replacing the token with a new token. For instance, the token may be updated with a new token after each use (e.g., after a payment is made using a payment token, after information is provided). Updating the payment token may also include updating the token expiration date. The life cycle management logic 116 may be configured to update the expiration date of the payment token based on use of the payment token or another event. Updating the payment token may also include performing any of the actions described herein in relation to the life cycle management logic 116.
The token inquiry logic 118 may be executed to process an inquiry related to the payment token. The token inquiry logic 118 is configured to provide an appropriate response to the inquiry. The inquiry may be received at the token vault computer system 110 from any of the network association computer system 130, the account holder computer system 140, the account issuer computer system 150, and the merchant computer system 160, any of which may be the token requestor or a holder of the payment token. The inquiry may be related to the current state of the payment token (e.g., active, expired, suspended, etc.). The inquiry may be related to a specific payment token or the inquiry may be a batch based on at least one of an account number or financial product (e.g., PAN), a token (e.g., TPAN), or an associated device. A batch inquiry may return information for each payment token having the provided characteristics. The token inquiry logic 118 is configured to receive the inquiry and search the token repository 122 for relevant payment tokens based on the inquiry. The token inquiry logic 118 then sends information related to the selected payment tokens (e.g., a current state) to the requesting party in response to the inquiry. The token inquiry logic 118 may request authenticating information from the requesting party prior to processing the inquiry. The token inquiry logic 118 may validate or authenticate the request based on information within the relevant payment token(s). In some embodiments, all actions described in relation to the token inquiry logic 118 may otherwise be performed, in whole or in part, by the token provisioning logic 112 and/or the life cycle management logic 116.
The token notification logic 120 may be executed to provide a notification related to a payment token. The token notification logic 120 may be configured to provide the same information as described in relation to the token inquiry logic 118, but the token notification logic 120 may provide the information in response to an action or event rather than a request. For instance, when the life cycle management logic 116 de-activates a payment token, the token notification logic 120 may send a notification to a relevant entity (e.g., a token requestor, an account holder, etc.) notifying the entity that the status of the payment token has changed. The token notification logic 120 may receive confirmation from the notified entity that the notification has been received. Any information related to the token notification logic 120 may be stored in the token history 124.
The token vault computer system 110 also includes token repository 122. The token repository 122 may include a storage system or other memory configured to receive and store payment tokens. Once a payment token is provisioned, the payment token may be stored in the token repository 122. The token repository 122 may be held by a financial institution and configured to store all payment tokens associated with the financial institution. In an example embodiment, the same financial institution provides the token vault computer system 110, including the logic described above, as well as the token repository 122 and the token history 124. The same financial institution may provide the financial product associated with the payment tokens stored in the repository 122.
The token repository 122 may be configured to store each payment token throughout the life cycle of the payment token. The payment tokens stored in the repository 122 may be generated by the token vault computer system 110 or generated elsewhere and converted by the token vault computer system 110 to match one or more characteristics of the generated payment tokens (i.e., payment tokens generated by the token provisioning logic 112). For instance, payment tokens that are not generated by the token vault computer system 110 may be converted such that all payment tokens stored within the repository 122 may be similarly searched (e.g., by token inquiry logic 118) in response to an inquiry.
The token vault computer system 110 also includes token history 124. The token history 124 includes memory configured to store information related to the payment tokens held by the token repository 122. The token history 124 may be stored in the token repository 122. The token history 124 includes a history of actions that are related to any payment tokens that have been stored in the token repository 122 or provisioned by the token provisioning logic 112. For instance, the token history 124 may include life cycle information for each of the stored payment tokens. The token history 124 may be used for responding to an inquiry, such as to determine a current state of a particular payment token. The token history 124 may also be utilized by the token provisioning logic 112 in generating a payment token. For instance, the token provisioning logic 112 may determine whether a particular payment token is unique based on information found within the token history 124.
Referring now to
At 202, a token requestor sends a request for a payment token to be provisioned based on a financial product. The token request may also include a request for terms and conditions related to the payment token and visual graphics for reading or displaying the payment token. The token request may include additional information that may be used to provision the payment token. The additional information may include identifying information that may be used to authenticate any of the requesting device, the token requestor, the account holder, and the financial product. In an example embodiment, the token request includes at least identifying information for the token requestor (e.g., a requestor ID) and a requesting device (i.e., device information). The token request may also any other information that is necessary or useful to provision the payment token, including to authenticate the token request and generate the payment token based on the financial product.
In an example embodiment, the token requestor is a merchant such as the merchant computer system 160. For instance, the merchant computer system 160 may send the request for the payment token in response to an account holder (i.e., the account holder computer system 140) initiating an online transaction with the merchant computer system 160. The merchant computer system 160 may receive identifying information from an account holder (i.e., user of the financial product) and send the identifying information with the token request for use in provisioning the payment token. The merchant computer system 160 may then receive the payment token based on the financial product and process the transaction without receiving sensitive account information from the account holder. In other embodiments, the token requestor may be the account holder computer system 140, the account issuer computer system 150, the network association computer system 130, or another entity related to the financial product or an associated transaction. In one embodiment, the token requestor may be a mobile wallet stored on a mobile device of the account holder. When the account holder (i.e., the user of the mobile device) adds a financial product to the mobile wallet or initiates a payment using the mobile wallet, the mobile device may send a token request to provision a payment token based on the financial product. The payment token may then be used by the mobile device to make a payment using the mobile wallet.
In the example embodiment, the token request is sent to the network association computer system 130. The network association computer system 130 may be provided by a network association (e.g., card association), which may be a network of issuing banks and acquiring banks that process payment cards of a specific brand. In the example embodiment, the network association computer system 130 is associated with the financial product being tokenized. For instance, the financial product may be a type of payment card that is processed by the network association. The token requestor may identify the network association and send the token request to the network association computer system 130 based on the financial product. In other embodiments, such as when the financial product is not associated with a particular network association, the token requestor may send the token request directly to the token vault computer system 110 to provision the payment token.
At 204, the network association computer system 130 sends the token request to the token vault computer system 110. The token request may be sent to the token vault computer system 110 based on the financial product. For instance, the token vault computer system 110 may be provided by a financial institution that provides the financial product associated with the token request. The token request may also be sent to the token vault computer system 110 based on the account holder. For instance, the account holder of the financial product may be a customer of the financial institution providing the token vault computer system 110. The account holder may also have other payment tokens stored at the token vault computer system 110.
At 206, the token vault computer system 110 (i.e., the token provisioning logic 112) determines the terms and conditions and the graphics associated with the payment token. The terms and conditions may specify how the payment token may be used to make a payment, storage procedures and security measures associated with the payment token, an expiration period for the payment token, and other terms and conditions that may be provided to the token requestor prior to or upon providing the generated payment token. The terms and conditions may be defined at the token vault computer system 110, such as by the token provisioning logic 112. The terms and conditions may be defined based on the financial product or based on any other information provided along with the token request.
The graphics associated with the payment token may include information related to how the payment token will be displayed. For instance, the payment token may be displayable (e.g., via a mobile device) in order to scan the payment token at a merchant point of sale device and initiate a payment. The graphics information may specify a mode of display for the payment token and may also include data or software required to display or otherwise manipulate the payment token. Similar to the terms and conditions, the graphics configuration may be defined at the token vault computer system 110, such as by the token provisioning logic 112.
At 208, the terms and conditions and graphics information are sent by the token vault computer system 110 to the network association computer system 130. At 210, the terms and conditions and graphics information are sent by the network association computer system 130 to the token requestor (i.e., the merchant computer system 160). In other embodiments, the terms and conditions and graphics information may be sent from the token vault computer system 110 directly to the token requestor. In an example embodiment, the terms and conditions for the payment token are provided to the token requestor prior to generating or providing the payment token. In this embodiment, the token requestor may be required to accept the associated terms and conditions prior to the payment token being generated or provided to the token requestor. The graphics information may also be provided to the token requestor prior to generating the payment token so that the token requestor may first confirm the ability to display the payment token having the provided graphics configuration. In other embodiments, the terms and conditions and graphics information may be provided upon providing the payment token to the token requestor.
At 212, the token vault computer system 110 (i.e., the token provisioning logic 112) determines token eligibility, which may include eligibility of the financial product for tokenization. The token vault computer system 110 may also authenticate the financial product. The token vault computer system 110 may determine eligibility of the token based on tokens that have been provisioned or are currently active. The token vault computer system 110 determines eligibility of the financial product for tokenization based on eligibility rules, which may be stored at the token vault computer system 110 (e.g., token repository 122, token history 124). The eligibility rules may be based on the particular financial product, the account holder, the token requestor, an expected use of the payment token, or any other information received as part of the token request or otherwise known. The eligibility rules may include a table that includes all financial products issued and associated with the token vault computer system 110. The table may provide an indication of whether a particular financial product is eligible for tokenization. The token provisioning logic 112 may be configured to determine eligibility by searching the table for the selected financial product based on any identifying information provided within the token request.
The token vault computer system 110 may also determine the eligibility of the financial product for tokenization by sending a request to the account issuer computer system 150. In an example embodiment, the request for an eligibility determination is sent to the account issuer computer system 150 at 212. In this embodiment, the account issuer computer system 150 may be the issuer of the financial product and may store eligibility rules specifying which of the financial products issued by the account issuer computer system 150 are eligible for tokenization. At 214, the account issuer computer system 150 may provide a determination of eligibility to the token vault computer system 110.
The token vault computer system 110 may also authenticate the payment token at 212. For instance, the token request may include an original payment credential related to the financial product or other data that may be used by the token provisioning logic 112 to authenticate the product. The token provisioning logic 112 may also request additional information from the token requestor to authenticate the financial product. In an example embodiment, the token vault computer system 110 stores authentication rules or other information that may be used to authenticate the financial product. In other embodiments, the token provisioning logic 112 is configured to send identifying information from the token request to the issuer of the financial product (e.g., account issuer computer system 150) and receive an authentication confirmation in response.
At 216, the token vault computer system 110 (i.e., token provisioning logic 112) is configured to filter the information within the token request. For instance, in some embodiments the payment token may include the name of a requesting device or a device storing an associated mobile wallet. The name may be encrypted within the payment token when the payment token is generated. In these embodiments, the token vault computer system 110 may be configured to filter any offensive words or characters from the device name so that the offensive characters are not received or interpreted by an entity receiving the payment token. The token vault computer system 110 may also be configured to filter any other offensive terms or characters that are to be included within the payment token. The filter settings may be determined by the token vault computer system 110 based on stored settings. The filter settings may also be determined based on inputs received from any of the entities in system 100. For instance, the merchant computer system 160 or the network association computer system 130 may specify any words or characters that should be filtered from the payment token.
At 218, the token vault computer system 110 (i.e., token provisioning logic 112) is configured to generate the payment token. The payment token may be generated after authenticating the financial product and determining that the financial product is eligible for tokenization. The payment token may be generated according to any coding convention described herein. The payment token may include any of the information described herein and related to the financial product, including any information received in the token request. Any information stored within the payment token may be encrypted by the token provisioning logic 112. The token requestor or another entity authorized to receive the encrypted information may be provided with a key or other information for decrypting the encrypted information. In one embodiment, the token provisioning logic 112 is also configured to activate the payment token upon generating the payment token.
At 220, the token vault computer system 110 may also be configured to generate limited use keys (LUKs). The token provisioning logic 112 may be configured to generate one or more LUKs based on the token request. The LUKs may be generated such that they expire or become unusable based on determined thresholds. For instance, each LUK may be configured to expire based on a set time period for expiration or based on a threshold transaction velocity (i.e., speed by which funds are transmitted) or number of transactions. The token vault computer system 110 may be configured to determine these thresholds based on any number of factors, including based on the financial product, the account issuer, the account holder, and an expected use for the payment token. The token vault computer system 110 may store settings, including expiration thresholds, for the LUKs at the token repository 122 and/or the token history 124.
At 222, the token vault computer system 110 (i.e., the token provisioning logic 112) may provide a notification to the account holder computer system 140. The notification may include information related to the payment token, such as any information found within the token request. The notification may also provide information related to generation of the payment token, including when the payment token was generated and/or activated, the associated financial product, the token requestor, the terms and conditions, any eligibility determination or authentication performed for the payment token, any LUKs that were generated based on the payment token or the token request, or any other information received or generated by the token vault computer system 110. The token provisioning logic 112 may provide the notification to the account holder computer system 140 and require confirmation by the account holder (i.e., system 140) prior to generating the payment token. The token provisioning logic 112 may also provide the notification when the payment token is generated and/or sent to another entity. In one embodiment, the same notification may be provided by the token notification logic 120.
At 224, the token vault computer system 110 may send the generated payment token to the network association computer system 130 (e.g., if the payment token is not generated by the system 130). However, in embodiments in which the network association computer system 130 generates the payment token, step 224 is not required. At 226, the network association computer system 130 sends the payment token to the token requester (i.e., the merchant computer system 160). In other embodiments, the token vault computer system 110 may send the generated payment token directly to the token requestor. Along with the payment token, the token vault computer system 110 may also send any associated terms and conditions, any graphics information for reading or displaying the payment token, and any LUKs that were generated with the payment token. In an example embodiment, the payment token has been activated and is available for use in making a payment.
As referenced above, the process 200 may also be utilized to provision a token based on non-payment information (e.g., to tokenize non-payment information). Any description herein related to the provisioning of payment tokens may be applied accordingly to the provisioning of tokens for non-payment information (i.e., non-payment tokens). Payment information may refer to information that may be used to initiate a process a payment, such as an account number, a card number, a routing number, and the like. Non-payment information refers to any information that is not payment information, and may particularly include personal information of an account holder such as address information (e.g., a shipping address for purchases), personal identification numbers (e.g., social security number, driver's license number, etc.), and other personal identifying information.
The token provisioning logic 112 and the process 200 may be utilized to provision a token based on any non-payment information so that the non-payment information may be securely transmitted between two or more parties. For instance, an account holder (i.e., the account holder computer system 140) may store at the token vault computer system 110 one or more non-payment tokens based on various non-payment information. The account holder may then provide the one of the non-payment tokens to a merchant (i.e., the merchant computer system 160). The merchant may then provide the non-payment token to the token vault computer system 110 in exchange for the de-tokenized (e.g., decrypted) non-payment information. The account holder may continue to update the stored token at the single-location token vault computer system 110 so that any third parties that have been provided the token are able to obtain the updated non-payment information without further communication by the account holder to any individual merchants or other parties.
In an example embodiment, an account holder may want for a merchant (i.e., the merchant computer system 160) to have access to the account holder's current shipping address at any time. The account holder may send a tokenization request to the token vault computer system 110 to request that the account holder's shipping address be tokenized. Once the token is provisioned, the account holder may then provide the token to the merchant. The merchant may then provide the token to the token vault computer system 110 in exchange for the account holder's current shipping address (or verification of the shipping address). By providing the token to the merchant, the account holder authorizes the merchant to obtain the account holder's shipping address and any other information related to the token. The tokens and the associated information are stored at the token vault computer system 110. The merchant stores only the token rather than having to store the related information.
The account holder may also request that the token be updated to change the shipping address or make additional information available to the merchant. Additional information may include a title of ownership, insurance information, personal identifying information, records of past transactions with the merchant, payment schedules, celebrated birthdays and holidays, upcoming transactions, and other information that may be useful to the merchant. The token vault computer system 110 is configured to manage the token, including updating the token according to requests received from the account holder. The merchant may request current information using the token at any time. The token vault computer system 110 may provide or verify the current information to the merchant in exchange for the token and/or additional value. The merchant may continually update the files and data attributes of its customer (i.e., the account holder) using the non-payment token.
The token vault computer system 110 is configured to store various preferences related to the tokens. For instance, the account holder may provide preferences related to each individual merchant that is provided with the token. For instance, the token vault computer system 110 may store for each token (a) the merchant(s) that have received the token and those that are allowed to have/use the token, (b) contract provisions that govern how the merchant is allowed to use the token and the related information, (c) attributes and/or rules regarding the specific data fields of the account holder that the merchant is allowed to retrieve when presenting the token to the token vault computer system 110, (d) rules regarding when access is revocable (e.g., access expires after 90 days), and (e) specific transaction use cases.
In another example embodiment, an account holder may securely provide sensitive information to an intended party via an intermediary. For instance, the account holder may be required to provide personal identifying information (e.g., a social security number) to an intermediary in order to obtain a background check or credit check, apply for a loan, apply to rent an apartment, and the like. The token vault computer system 110 may tokenize the personal identifying information at the request of the account holder. The account holder may then provide the provisioned token to the intermediary to provide to the intended party (e.g., a credit agency, a police department, a loan officer, etc.). The account holder may also update the preferences for the provisioned token so that the intended party, and not the intermediary, is provided access to the tokenized personal identifying information in exchange for the token. The token vault computer system 110 may then provide the personal identifying information to only the intended party, and not the intermediary, based on the preferences of the account holder. The token vault computer system 110 may require additional information to verify the identity of the intended party prior to releasing the personal identifying information. In this way, the token vault computer system 110 ensures that the intermediary does not have access to the sensitive information.
The token vault computer system 110 may also be configured to group certain non-payment information according to intended use. For instance, the token vault computer system 110 may automatically generate non-payment tokens based on information that is required when purchasing a car, when purchasing a home, when applying for college, when applying for rental housing, etc. The account holder may then provide these non-payment tokens to a third party, depending on the particular application, to more quickly and efficiently provide any required information.
Referring now to
In an example embodiment, the token vault computer system 110 receives an update request from the account issuer computer system 150. The update request is related to a payment token associated with a financial product issued by the account issuer computer system 150. At 304, the token vault computer system 110 is configured to update the payment token based on the update request. For instance, the token vault computer system 110 may receive the update request from the account issuer computer system 150 and determines an appropriate update for the payment token based on the request. As an example, the update request may indicate that the account holder has closed the credit card account (i.e., financial product) associated with the payment token. In this embodiment, the life cycle management logic 116 is configured to permanently de-activate the payment token. The life cycle management logic 116 may also be configured to suspend a payment token upon receiving an indication that the account holder is past due on a payment. In other embodiments, the token vault computer system 110 is configured to update the payment token absent an update request. In these embodiments, the life cycle management logic 116 may update the payment token based on an event or action determined by the token vault computer system 110. For example, the life cycle management logic 116 may expire a payment token based on exceeding a time threshold associated with the payment token.
Although the updates described herein are related to the life cycle of the payment token, at 304 the token vault computer system 110 may also be configured to otherwise update the payment token based on an inquiry. For instance, the token vault computer system 110 may receive an inquiry (e.g., from the account issuer computer system 150) of a payment token and update the payment token to indicate that the inquiry was received. The token vault computer system 110 may also provide information to the account issuer computer system 150 and/or another entity of system 100 based on the inquiry. Any information related to the payment token updates may be stored in the token history 124.
At 306, the token vault computer system 110 is configured to generate and send a notification to the account holder computer system 140. The notification may provide an indication that the payment token has been updated. The notification may be sent to the account holder based on settings related to the payment token and/or the account holder. For instance, the token vault computer system 110 may generate notification settings for each payment token and/or account holder. The notification settings may be generated based on the token request (i.e., when the payment token is provisioned). The notification settings may also be modified based on input received from the account holder. In some embodiments, the token vault computer system 110 may only send notifications to the account holder based on specified updates, such as when the payment token is de-activated or expired. The token vault computer system 110 may send the notification to a mobile device of the account holder, such as when the mobile device is associated with the payment token. In one embodiment, the notification may be sent using the token notification logic 120.
At 308, the token vault computer system 110 is configured to send a notification to the network association computer system 130. The token vault computer system 110 may identify the appropriate network association based on the payment token. The notification is based on the payment token and may provide an indication that the payment token has been updated. The notification sent to system 130 may be the same or similar to the notification sent to system 140. The notification may be sent to the network association computer system 130 based on settings related to the payment token and/or the network association. At 310, the network association computer system 130 delivers the notification to the merchant computer system 160. The network association computer system 130 may identify the merchant computer system 160 based on the payment token, including based on settings related to the payment token and stored at the token vault computer system 110. In other embodiments, the token vault computer system 110 sends the notification directly to the merchant computer system 160. In these embodiments, the token vault computer system 110 is configured to identify the merchant computer system 160 based on the payment token.
At 312, the merchant computer system 160 sends a confirmation to the network association computer system 130 that the notification has been received. At 314, the network association computer system 130 delivers the confirmation to the token vault computer system 110. In other embodiments, the token vault computer system 110 may receive the confirmation directly from the merchant computer system 160. The merchant computer system 160 may identify the network association computer system 130 and/or the token vault computer system 110 based on the notification and/or based on information stored on the payment token. Similarly, the network association computer system 130 may identify the token vault computer system 110 based on the notification and/or the payment token. At 316, the token vault computer system 110 stores the confirmation received from the merchant computer system 160. The confirmation may be stored in the token history 124. The token vault computer system 110 may also store a confirmation received from the account holder computer system 140 in the token history 124.
Referring now to
The payment token may be associated with the token vault computer system 110. In one embodiment, the payment token was provisioned by the token vault computer system 110. The payment token is also stored at the token vault computer system 110. The merchant computer system 160 may identify the network association computer system 130 and/or the token vault computer system 110 based on the payment token. Likewise, the network association computer system 130 may identify the token vault computer system 110 based on the payment token. For instance, an identity of any or all of the systems 110, 130, and 160 may be included within the payment token and any or all of the systems 110, 130, and 160 may be configured to at least partially decrypt the payment token to determine the identity.
The update request may include information related to the payment token, including a reason for updating the payment token. For instance, the update request may include one or more transactions performed using the payment token. The update request may also include an update related to the financial product associated with the payment token, such as a new account number or expiration date for the financial product. The update request may also include a new account holder for the financial product. At 306, the token vault computer system 110 is configured to update the payment token based on the update request. The token vault computer system 110 may update the status of the payment token, such as by activating, suspending, resuming, de-activating, or expiring the payment token based on the update request. The token vault computer system 110 may be configured to authenticate the update request based on the information received within the update request. For instance, the token vault computer system 110 may require authenticating credentials to be included within the update request in order to process the update.
At 408, the token vault computer system 110 stores the update request and any related information in the token history 124. The token vault computer system 110 may also store the updated payment token in the token repository 122. At 410, the token vault computer system 110 sends a response (e.g., confirmation) to the network association computer system 130, indicating that the payment token has been updated. The token vault computer system 110 may also send the updated payment token to the system 130 as part of the response. At 412, the network association computer system 130 delivers the response to the merchant computer system 160. In other embodiments, the token vault computer system 110 may deliver the response directly to the merchant computer system 160. Where the token requestor is not the account holder (i.e., account holder computer system 140), the token vault computer system 110 may also send a notification to the account holder computer system 140 indicating that the payment token has been updated.
In an example embodiment, the account holder may send a tokenization request to the token vault computer system 110 for a payment token related to a financial product of the account holder. The payment token provisioned by the computer system 110 may then be provided to online merchants rather than providing credit card information or other payment information. The online merchants may then be required to provide the payment token to the token vault computer system 110 to initiate a payment. The token vault computer system 110 is configured to authorize the transaction based on preferences provided by the account holder. The token vault computer system 110 also tracks every transaction and stores any related information for use by the account holder. The token vault computer system 110 also maintains a record of any data or information that is provided to the online merchants. The token vault computer system 110 may also report to the account holder any online merchants that have the account holder's payment information and/or payment token. The account holder may the restrict use based on the user preferences stored at the token vault computer system 110. The account holder may also delete or disable any payment tokens
The token vault computer system 110 may also provide an interface to the account holder for managing the stored tokens. In an example embodiment, the account holder accesses the token vault computer system 110 via an online interface or a mobile application. The account holder is able to request that a token be provisioned and manage any existing tokens stored at the token vault computer system 110 using the mobile application. The account holder may also adjust various user preferences related to the tokens using the mobile application.
The token vault computer system 110 may also be configured to collect data based on provisioned tokens and tokens that are provided to third parties. For instance, the token vault computer system 110 could provide a map showing geographic or virtual locations where the account holder has provided a token or where a token has been used. The token vault computer system 110 could also mine additional data related to the payment tokens, including purchases, preferences, and other transaction data that could be used to provide additional services and targeted products to the account holder.
Referring now to
At 504, the merchant computer system 160 sends the payment token to the network association computer system 130 based on the payment token. The payment token may include identifying information for the network association computer system 130 that is readable by the merchant computer system 160. In one embodiment, the merchant computer system 160 is configured to decrypt at least a portion of the payment token to identify the network association computer system 130. For instance, the merchant computer system 160 may be provided with a decryption key (e.g., by the token vault computer system 110, by the account holder computer system 140, etc.) in order to identify an appropriate entity to send the payment token for authorization.
At 506, the network association computer system 130 delivers the payment token to the token vault computer system 110 based on the payment token. Similarly, the payment token may include identifying information for the token vault computer system 110 that is readable by the network association computer system 130. In one embodiment, the network association computer system 130 is configured to decrypt at least a portion of the payment token to identify the token vault computer system 110. For instance, the network association computer system 130 may be provided with a decryption key (e.g., by the token vault computer system 110, by the account holder computer system 140, etc.) in order to identify an appropriate entity to send the payment token for authorization. In another embodiment, the merchant computer system 160 delivers the payment token directly to the token vault computer system 110 based on the payment token. In this embodiment, the merchant computer system 160 may be configured to identify the token vault computer system 110 based on the payment token.
At 508, the token vault computer system 110 authenticates the payment token. The token vault computer system 110 may authenticate the payment token by validating encrypted data (i.e., a cryptogram) stored within the payment token. For instance, the token vault computer system 110 may authenticate the payment token by verifying that the payment token was provisioned by the token vault computer system 110. The payment token may also be authenticated by verifying that the payment token was received from the account holder computer system 140. The payment token may also be authenticated by verifying any other information stored as a cryptogram within the payment token, such as account holder information, information related to the associated financial product, provisioning data, or by matching any other data stored on the payment token with data stored at the token vault computer system 110 (e.g., token history 124). As part of authenticating the payment token, the token vault computer system 110 may decrypt the payment token to reveal account information necessary to process the transaction.
At 510, the token vault computer system 110 may re-encrypt the account information. For instance, the account information may be tokenized similarly to when the payment token was provisioned. The account information may be encrypted in order to securely send the account information to the merchant computer system 160 to complete the transaction. At 512, the encrypted account information is sent by the token vault computer system 110 to the network association computer system 130 as an indication that the transaction has been authorized by the token vault computer system 110. At 514, the network association computer system 130 delivers the encrypted account information to the merchant computer system 160. In an example embodiment, at least the merchant computer system 160 is provided with a key or rules for decrypting the encrypted account information in order to process the transaction. In other embodiments, the token vault computer system 110 may deliver the encrypted account information directly to the merchant computer system 160.
At 516, the token vault computer system 110 is configured to store any actions related to the payment token within the token history 124. The token vault computer system 110 may also update the payment token at the token repository 122, including to update the status of the payment token.
The present disclosure contemplates methods, systems and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, 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. Software implementations could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.
While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular implementations. Certain features described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products embodied on tangible media.
Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.
The claims should not be read as limited to the described order or elements unless stated to that effect. It should be understood that various changes in form and detail may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims. All implementations that come within the spirit and scope of the following claims and equivalents thereto are claimed.
This application claims priority to and is a continuation of U.S. patent application Ser. No. 15/081,536 (now U.S. Pat. No. 11,429,975), filed Mar. 25, 2016, entitled “TOKEN MANAGEMENT SYSTEM which is related to and claims priority to U.S. Provisional Patent Application No. 62/139,525, entitled “TOKEN MANAGEMENT SYSTEM,” filed on Mar. 27, 2015, the contents of which is hereby incorporated by reference in its entirety and for all purposes.
| 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 et al. | Mar 2005 | B1 |
| 6879965 | Fung et al. | Apr 2005 | B2 |
| 6910021 | Brown et al. | Jun 2005 | B2 |
| 6931382 | Laage et al. | Aug 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 |
| 7155411 | Blinn et al. | Dec 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 |
| 7401731 | Pletz et al. | Jul 2008 | B1 |
| 7413113 | Zhu | Aug 2008 | B1 |
| 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 |
| 7740170 | Singh et al. | Jun 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 | Apr 2013 | B1 |
| 8473394 | Marshall | Jun 2013 | B2 |
| 8489761 | Pope et al. | Jul 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 |
| 8639629 | Hoffman | Jan 2014 | B1 |
| 8655310 | Katzer et al. | Feb 2014 | B1 |
| 8655719 | Li | Feb 2014 | B1 |
| 8660926 | Wehunt et al. | Feb 2014 | B1 |
| 8666411 | Tokgoz et al. | Mar 2014 | B2 |
| 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 |
| 8768838 | Hoffman | Jul 2014 | B1 |
| 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 |
| 8868666 | Hellwege 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 |
| 8925099 | Saxe 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 |
| 9305155 | Vo et al. | Apr 2016 | B1 |
| 9372849 | Gluck et al. | Jun 2016 | B2 |
| 9390417 | Song et al. | Jul 2016 | B2 |
| 9396491 | Isaacson et al. | Jul 2016 | B2 |
| 9444824 | Balazs et al. | Sep 2016 | B1 |
| 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 |
| 9569766 | Kneen | Feb 2017 | B2 |
| 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 |
| 9740543 | Savage et al. | Aug 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 |
| 9858405 | Ranadive et al. | Jan 2018 | B2 |
| 9858576 | Song et al. | Jan 2018 | B2 |
| 9978046 | Lefebvre et al. | May 2018 | B2 |
| 10032146 | Caldwell | Jul 2018 | B2 |
| 10044501 | Bradley et al. | Aug 2018 | B1 |
| 10044647 | Karp et al. | Aug 2018 | B1 |
| 10050779 | Alness et al. | Aug 2018 | B2 |
| 10055747 | Sherman et al. | Aug 2018 | B1 |
| 10115155 | Haller et al. | Oct 2018 | B1 |
| 10152756 | Isaacson et al. | Dec 2018 | B2 |
| 10157420 | Narayana et al. | Dec 2018 | B2 |
| 10187483 | Golub et al. | Jan 2019 | B2 |
| 10204327 | Katzin et al. | Feb 2019 | B2 |
| 10216548 | Zhang et al. | Feb 2019 | B1 |
| 10250453 | Singh et al. | Apr 2019 | B1 |
| 10275602 | Bjorn et al. | Apr 2019 | B2 |
| 10359915 | Asai | Jul 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 |
| 10445152 | Zhang et al. | Oct 2019 | B1 |
| 10460395 | Grassadonia | Oct 2019 | B2 |
| 10521798 | Song et al. | Dec 2019 | B2 |
| 10592882 | Viswanath et al. | Mar 2020 | B1 |
| 10650448 | Haller et al. | May 2020 | B1 |
| 10657503 | Ebersole et al. | May 2020 | B1 |
| 10872005 | Killis | Dec 2020 | B1 |
| 10878496 | Duong et al. | Dec 2020 | B1 |
| 10963589 | Fakhraie et al. | Mar 2021 | B1 |
| 10984482 | Thangarajah et al. | Apr 2021 | B1 |
| 10992679 | Fakhraie et al. | Apr 2021 | B1 |
| 11107561 | Matthieu et al. | Aug 2021 | B2 |
| 11144903 | Ready et al. | Oct 2021 | B2 |
| 11151529 | Nolte et al. | Oct 2021 | B1 |
| 20010001856 | Gould et al. | May 2001 | A1 |
| 20010032183 | Landry | Oct 2001 | A1 |
| 20010051920 | Joao et al. | Dec 2001 | A1 |
| 20010056398 | Scheirer | Dec 2001 | A1 |
| 20020016749 | Borecki et al. | Feb 2002 | A1 |
| 20020035539 | O'Connell | Mar 2002 | A1 |
| 20020038289 | Lawlor et al. | Mar 2002 | A1 |
| 20020062249 | Iannacci | May 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 |
| 20030055786 | Smith 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 |
| 20040054564 | Fonseca et al. | Mar 2004 | 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 |
| 20040143632 | McCarty | Jul 2004 | A1 |
| 20040148259 | Reiners et al. | Jul 2004 | A1 |
| 20040178907 | Cordoba | Sep 2004 | A1 |
| 20040225606 | Nguyen et al. | Nov 2004 | A1 |
| 20040249710 | Smith et al. | Dec 2004 | A1 |
| 20040249753 | Blinn et al. | Dec 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 |
| 20050171898 | Bishop et al. | Aug 2005 | A1 |
| 20050199714 | Brandt et al. | Sep 2005 | A1 |
| 20050205662 | Nelson | Sep 2005 | A1 |
| 20050224587 | Shin et al. | Oct 2005 | A1 |
| 20050228750 | Olliphant et al. | Oct 2005 | A1 |
| 20050273431 | Abel et al. | Dec 2005 | A1 |
| 20060046742 | Zhang | Mar 2006 | A1 |
| 20060046745 | Davidson | Mar 2006 | A1 |
| 20060059110 | Madhok et al. | Mar 2006 | A1 |
| 20060178986 | Giordano et al. | Aug 2006 | A1 |
| 20060184456 | De Janasz | Aug 2006 | A1 |
| 20060190374 | Sher | Aug 2006 | A1 |
| 20060202012 | Grano et al. | Sep 2006 | A1 |
| 20060206912 | Klarfeld et al. | Sep 2006 | A1 |
| 20060235795 | Johnson et al. | Oct 2006 | A1 |
| 20060278698 | Lovett | Dec 2006 | A1 |
| 20070051797 | Randolph-Wall et al. | Mar 2007 | 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 |
| 20080066185 | Lester et al. | Mar 2008 | A1 |
| 20080086398 | Parlotto | Apr 2008 | A1 |
| 20080115104 | Quinn | May 2008 | A1 |
| 20080149706 | Brown et al. | Jun 2008 | A1 |
| 20080154772 | Carlson | Jun 2008 | A1 |
| 20080170156 | Kim | Jul 2008 | A1 |
| 20080191878 | Abraham | Aug 2008 | A1 |
| 20080208726 | Tsantes et al. | Aug 2008 | A1 |
| 20080226142 | Pennella et al. | Sep 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 |
| 20080319889 | Hammad et al. | 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 |
| 20090164324 | Bishop et al. | Jun 2009 | A1 |
| 20090205014 | Doman et al. | Aug 2009 | A1 |
| 20090228381 | Mik et al. | Sep 2009 | A1 |
| 20090254447 | Blades | Oct 2009 | A1 |
| 20090254971 | Herz et al. | Oct 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 |
| 20100082445 | Hodge et al. | Apr 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 |
| 20100199098 | King | Aug 2010 | A1 |
| 20100228671 | Patterson | Sep 2010 | A1 |
| 20100274691 | Hammad et al. | Oct 2010 | A1 |
| 20100276484 | Banerjee et al. | Nov 2010 | A1 |
| 20100312700 | Coulter et al. | Dec 2010 | A1 |
| 20100327056 | Yoshikawa et al. | Dec 2010 | A1 |
| 20110023129 | Vernal et al. | Jan 2011 | A1 |
| 20110035288 | Clyne | Feb 2011 | A1 |
| 20110035318 | Hargrove et al. | Feb 2011 | A1 |
| 20110035596 | Attia et al. | Feb 2011 | A1 |
| 20110078010 | Postrel | Mar 2011 | A1 |
| 20110106698 | Isaacson et al. | May 2011 | A1 |
| 20110162057 | Gottumukkala et al. | Jun 2011 | A1 |
| 20110176010 | Houjou et al. | Jul 2011 | A1 |
| 20110178929 | Durkin et al. | Jul 2011 | A1 |
| 20110191177 | Blackhurst et al. | Aug 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 |
| 20110320246 | Tietzen et al. | Dec 2011 | A1 |
| 20120024946 | Tullis et al. | Feb 2012 | 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 |
| 20120099780 | Smith et al. | Apr 2012 | A1 |
| 20120101938 | Kasower | Apr 2012 | A1 |
| 20120123841 | Taveau et al. | May 2012 | A1 |
| 20120123933 | Abel et al. | May 2012 | A1 |
| 20120124658 | Brudnicki et al. | May 2012 | A1 |
| 20120158590 | Salonen | Jun 2012 | A1 |
| 20120173387 | Talker et al. | Jul 2012 | A1 |
| 20120197691 | Grigg et al. | Aug 2012 | A1 |
| 20120214577 | Petersen et al. | Aug 2012 | A1 |
| 20120227094 | Begen et al. | Sep 2012 | A1 |
| 20120239417 | Pourfallah et al. | Sep 2012 | A1 |
| 20120239479 | Amaro et al. | Sep 2012 | A1 |
| 20120239670 | Horn et al. | Sep 2012 | A1 |
| 20120240235 | Moore | Sep 2012 | A1 |
| 20120246122 | Short et al. | Sep 2012 | A1 |
| 20120254038 | Mullen | Oct 2012 | A1 |
| 20120259782 | Hammad | Oct 2012 | A1 |
| 20120265682 | Menon | Oct 2012 | A1 |
| 20120265685 | Brudnicki et al. | Oct 2012 | A1 |
| 20120270522 | Laudermilch et al. | Oct 2012 | A1 |
| 20120296725 | Dessert et al. | Nov 2012 | A1 |
| 20120296831 | Carrott | Nov 2012 | A1 |
| 20120310760 | Phillips et al. | Dec 2012 | A1 |
| 20120317036 | Bower et al. | Dec 2012 | A1 |
| 20130006847 | Hammad et al. | Jan 2013 | A1 |
| 20130031006 | McCullagh et al. | Jan 2013 | A1 |
| 20130046607 | Granville, III | Feb 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 |
| 20130212666 | Mattsson et al. | Aug 2013 | A1 |
| 20130218649 | Beal | Aug 2013 | A1 |
| 20130218758 | Koenigsbrueck et al. | Aug 2013 | A1 |
| 20130226813 | Voltz | Aug 2013 | A1 |
| 20130240618 | Hall | Sep 2013 | A1 |
| 20130246258 | Dessert | Sep 2013 | A1 |
| 20130246272 | Kirsch | Sep 2013 | A1 |
| 20130254079 | Murali | Sep 2013 | A1 |
| 20130254115 | Pasa et al. | Sep 2013 | A1 |
| 20130282542 | White | Oct 2013 | A1 |
| 20130301392 | Zhao | Nov 2013 | A1 |
| 20130339124 | Postrel | Dec 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 |
| 20140026193 | Saxman | Jan 2014 | A1 |
| 20140032419 | Anderson et al. | Jan 2014 | A1 |
| 20140032723 | Nema | Jan 2014 | A1 |
| 20140040134 | Ciurea | Feb 2014 | A1 |
| 20140040144 | Plomske et al. | Feb 2014 | A1 |
| 20140046827 | Hochstatter et al. | Feb 2014 | A1 |
| 20140053069 | Yan | Feb 2014 | A1 |
| 20140067503 | Ebarle Grecsek et al. | Mar 2014 | A1 |
| 20140067683 | Varadarajan | Mar 2014 | A1 |
| 20140068030 | Chambers et al. | Mar 2014 | A1 |
| 20140076967 | Pushkin et al. | Mar 2014 | A1 |
| 20140081736 | Blackhurst et al. | Mar 2014 | A1 |
| 20140108260 | Poole et al. | Apr 2014 | A1 |
| 20140108263 | Ortiz et al. | Apr 2014 | A1 |
| 20140114780 | Menefee et al. | Apr 2014 | A1 |
| 20140114855 | Bajaj et al. | Apr 2014 | A1 |
| 20140122328 | Grigg | May 2014 | A1 |
| 20140123312 | Marcotte | May 2014 | A1 |
| 20140129357 | Goodwin | May 2014 | A1 |
| 20140129448 | Aiglstorfer | May 2014 | A1 |
| 20140136419 | Kiyohara | May 2014 | A1 |
| 20140143886 | Eversoll et al. | May 2014 | A1 |
| 20140149198 | Kim et al. | May 2014 | A1 |
| 20140149368 | Lee et al. | May 2014 | A1 |
| 20140162598 | Villa-Real | Jun 2014 | A1 |
| 20140164220 | Desai et al. | Jun 2014 | A1 |
| 20140172576 | Spears et al. | Jun 2014 | A1 |
| 20140172707 | Kuntagod et al. | Jun 2014 | A1 |
| 20140180854 | Bryant, II | Jun 2014 | A1 |
| 20140198054 | Sharma et al. | Jul 2014 | A1 |
| 20140200957 | Biggs | Jul 2014 | A1 |
| 20140207672 | Kelley | Jul 2014 | A1 |
| 20140237236 | Kalinichenko | Aug 2014 | A1 |
| 20140248852 | Raleigh et al. | Sep 2014 | A1 |
| 20140250002 | Isaacson et al. | Sep 2014 | A1 |
| 20140258104 | Harnisch | Sep 2014 | A1 |
| 20140258109 | Jiang et al. | Sep 2014 | A1 |
| 20140258110 | Davis et al. | Sep 2014 | A1 |
| 20140279309 | Cowen et al. | Sep 2014 | A1 |
| 20140279474 | Evans et al. | Sep 2014 | A1 |
| 20140279559 | Smith et al. | Sep 2014 | A1 |
| 20140282852 | Vestevich | Sep 2014 | A1 |
| 20140297438 | Dua | Oct 2014 | A1 |
| 20140306833 | Ricci | Oct 2014 | A1 |
| 20140324527 | Kulkarni et al. | 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 |
| 20140365291 | Shvarts | Dec 2014 | A1 |
| 20140372308 | Sheets | Dec 2014 | A1 |
| 20140379575 | Rogan | Dec 2014 | A1 |
| 20150019443 | Sheets et al. | Jan 2015 | 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 | Jan 2015 | A1 |
| 20150039457 | Jacobs et al. | Feb 2015 | A1 |
| 20150046338 | Laxminarayanan et al. | Feb 2015 | A1 |
| 20150046339 | Wong | Feb 2015 | A1 |
| 20150066768 | Williamson et al. | Mar 2015 | A1 |
| 20150070132 | Candelore | Mar 2015 | A1 |
| 20150073989 | Green et al. | Mar 2015 | A1 |
| 20150079932 | Zelinka et al. | Mar 2015 | A1 |
| 20150081349 | Johndrow et al. | Mar 2015 | A1 |
| 20150082042 | Hoornaert et al. | Mar 2015 | A1 |
| 20150088633 | Salmon et al. | Mar 2015 | A1 |
| 20150088756 | Makhotin et al. | Mar 2015 | A1 |
| 20150095238 | Khan et al. | Apr 2015 | A1 |
| 20150096039 | Mattsson et al. | Apr 2015 | A1 |
| 20150100477 | Salama et al. | Apr 2015 | A1 |
| 20150100495 | 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 |
| 20150127524 | Jacobs et al. | May 2015 | A1 |
| 20150127547 | Powell et al. | May 2015 | A1 |
| 20150128215 | Son et al. | May 2015 | A1 |
| 20150132984 | Kim et al. | May 2015 | A1 |
| 20150134700 | Macklem et al. | May 2015 | A1 |
| 20150142673 | Nelsen et al. | May 2015 | A1 |
| 20150149272 | Salmon et al. | May 2015 | A1 |
| 20150149357 | Ioannidis et al. | May 2015 | A1 |
| 20150154595 | Collinge et al. | Jun 2015 | A1 |
| 20150178724 | Ngo et al. | Jun 2015 | A1 |
| 20150180836 | Wong et al. | Jun 2015 | A1 |
| 20150186856 | Weiss et al. | Jul 2015 | A1 |
| 20150193639 | Esposito et al. | Jul 2015 | A1 |
| 20150193764 | Haggerty et al. | Jul 2015 | A1 |
| 20150193866 | Van Heerden et al. | Jul 2015 | A1 |
| 20150199679 | Palanisamy | Jul 2015 | A1 |
| 20150199689 | Kumnick et al. | Jul 2015 | A1 |
| 20150200495 | Yu et al. | Jul 2015 | A1 |
| 20150213435 | Douglas | Jul 2015 | A1 |
| 20150220917 | Aabye et al. | Aug 2015 | A1 |
| 20150220999 | Thornton | Aug 2015 | A1 |
| 20150221149 | Main et al. | Aug 2015 | A1 |
| 20150229622 | Grigg et al. | Aug 2015 | A1 |
| 20150242853 | Powell | Aug 2015 | A1 |
| 20150248405 | Rudich et al. | Sep 2015 | A1 |
| 20150254635 | Bondesen et al. | Sep 2015 | A1 |
| 20150254638 | Bondesen et al. | Sep 2015 | A1 |
| 20150254646 | Harkey et al. | Sep 2015 | A1 |
| 20150254647 | Bondesen et al. | Sep 2015 | A1 |
| 20150254655 | Bondesen et al. | Sep 2015 | A1 |
| 20150254656 | Bondesen et al. | Sep 2015 | A1 |
| 20150269566 | Gaddam et al. | Sep 2015 | A1 |
| 20150277712 | Ratcliffe et al. | Oct 2015 | A1 |
| 20150286834 | Ohtani et al. | Oct 2015 | A1 |
| 20150287133 | Marlov et al. | Oct 2015 | A1 |
| 20150295906 | Ufford et al. | Oct 2015 | A1 |
| 20150312038 | Palanisamy | Oct 2015 | A1 |
| 20150319158 | Kumnick | Nov 2015 | A1 |
| 20150319198 | Gupta et al. | Nov 2015 | A1 |
| 20150324592 | Dutta | Nov 2015 | A1 |
| 20150332067 | Gorod | Nov 2015 | A1 |
| 20150339663 | Lopreiato et al. | Nov 2015 | A1 |
| 20150339664 | Wong et al. | Nov 2015 | A1 |
| 20150371221 | Wardman | Dec 2015 | A1 |
| 20150372999 | Pi-Sunyer | Dec 2015 | A1 |
| 20150379508 | Van | Dec 2015 | A1 |
| 20160004741 | Johnson et al. | Jan 2016 | 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 |
| 20160065370 | Le Saint et al. | Mar 2016 | A1 |
| 20160078428 | Moser et al. | Mar 2016 | A1 |
| 20160092696 | Guglani et al. | Mar 2016 | A1 |
| 20160092870 | Salama | Mar 2016 | A1 |
| 20160092872 | Prakash et al. | Mar 2016 | A1 |
| 20160092874 | O'Regan et al. | Mar 2016 | A1 |
| 20160098577 | Lacey et al. | Apr 2016 | A1 |
| 20160098692 | Johnson et al. | Apr 2016 | A1 |
| 20160109954 | Harris et al. | Apr 2016 | A1 |
| 20160119296 | Laxminarayanan | Apr 2016 | A1 |
| 20160125405 | Alterman et al. | May 2016 | A1 |
| 20160125409 | Meredith et al. | May 2016 | A1 |
| 20160127892 | Huang et al. | May 2016 | A1 |
| 20160140221 | Park et al. | May 2016 | A1 |
| 20160149875 | Li et al. | May 2016 | A1 |
| 20160155156 | Gopal et al. | Jun 2016 | A1 |
| 20160171483 | Luoma et al. | Jun 2016 | A1 |
| 20160173483 | Wong et al. | Jun 2016 | A1 |
| 20160180302 | Bagot, Jr. | Jun 2016 | A1 |
| 20160189121 | Best et al. | Jun 2016 | A1 |
| 20160217461 | Gaddam et al. | Jul 2016 | A1 |
| 20160232600 | Purves | Aug 2016 | A1 |
| 20160239437 | Le et al. | Aug 2016 | A1 |
| 20160239835 | Marsyla | Aug 2016 | A1 |
| 20160239840 | Preibisch | Aug 2016 | A1 |
| 20160260084 | Main et al. | Sep 2016 | A1 |
| 20160260176 | Bernard et al. | Sep 2016 | A1 |
| 20160267467 | Rutherford et al. | Sep 2016 | A1 |
| 20160267480 | Metral | Sep 2016 | A1 |
| 20160292673 | Chandrasekaran | Oct 2016 | A1 |
| 20160294879 | Kirsch | Oct 2016 | A1 |
| 20160307229 | Balasubramanian et al. | Oct 2016 | A1 |
| 20160314458 | Douglas et al. | Oct 2016 | A1 |
| 20160321669 | Beck et al. | Nov 2016 | A1 |
| 20160328522 | Howley | Nov 2016 | A1 |
| 20160328577 | Howley | Nov 2016 | A1 |
| 20160358163 | Kumar et al. | Dec 2016 | A1 |
| 20160371471 | Patton et al. | Dec 2016 | A1 |
| 20160373458 | Moreton et al. | Dec 2016 | A1 |
| 20160379211 | Hoyos et al. | Dec 2016 | A1 |
| 20170004506 | Steinman et al. | Jan 2017 | A1 |
| 20170011215 | Poiesz et al. | Jan 2017 | A1 |
| 20170011389 | McCandless et al. | Jan 2017 | A1 |
| 20170011450 | Frager 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 |
| 20180276628 | Radiotis et al. | Sep 2018 | A1 |
| 20180349922 | Carlson et al. | Dec 2018 | A1 |
| 20180357440 | Brady et al. | Dec 2018 | A1 |
| 20180373891 | Barday et al. | Dec 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 |
| 20190228428 | Bruner et al. | Jul 2019 | A1 |
| 20190228430 | Givol et al. | Jul 2019 | A1 |
| 20190318122 | Hockey et al. | Oct 2019 | A1 |
| 20190325161 | Zavesky et al. | Oct 2019 | A1 |
| 20190332802 | Barday et al. | Oct 2019 | A1 |
| 20190333061 | Jackson et al. | Oct 2019 | A1 |
| 20190347442 | Marlin et al. | Nov 2019 | A1 |
| 20190354979 | Crawford | Nov 2019 | A1 |
| 20190356641 | Isaacson et al. | Nov 2019 | A1 |
| 20190362069 | Park et al. | Nov 2019 | A1 |
| 20190369845 | Rucker | Dec 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 |
| 20210303335 | Foreman et al. | Sep 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 102498497 | Jun 2012 | CN |
| 102804219 | Nov 2012 | CN |
| 104106276 | Oct 2014 | CN |
| 1 259 947 | Nov 2002 | EP |
| 1 770 628 | Apr 2007 | EP |
| 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-2011017613 | Feb 2011 | WO |
| WO-2012054148 | Apr 2012 | WO |
| WO-2013082190 | Jun 2013 | WO |
| WO-2015103443 | Jul 2015 | WO |
| WO-2015135131 | Sep 2015 | WO |
| WO-2016015054 | Jan 2016 | WO |
| WO-2016025291 | Feb 2016 | WO |
| WO-2017035399 | Mar 2017 | WO |
| WO-2018005635 | Jan 2018 | WO |
| Entry |
|---|
| Technologies for Payment Fraud Prevention: EMV, Encryption, and Tokenization, Oct. 2014, Smart Card Alliance, pp. 1-34 ( Year: 2014). |
| ASB, “How to command your cards with ASB Card Control” Apr. 20, 2015, https://www.youtube.com/watch?v=O1sfxvVUL74 (Year: 2015). |
| Austin Telco Federal Credit Union, “Lost or Stolen Cards”, www.atfcu.org/lost-stolen-cards.htm; Apr. 9, 2004. 6 pages. |
| 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). |
| BancFirst, “Lost Card”, https://www.bancfirst.com/contact.aspx, Oct. 28, 2003. 1 page. |
| CM/ECF, “CM/ECF Internet Credit Card Payment Guide”, https://www.vaeb.uscourts.gov/wordpress/?page_id=340, Mar. 16, 2005. 12 pages. |
| 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). |
| 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/. |
| Demiriz et al. “Using Location Aware Business Rules for Preventing Retail Banking Frauds” Jan. 15, 2015, IEEE (Year: 2015). |
| Fiserv. CardValet: Mobile Application Training. Fiserv, Inc. 1-93. https://www.westernbanks.com/media/1664/ cardvalet-application .pdf (Year: 2015). |
| Fort Knox Federal Credit Union, “Lost or Stolen VISA Card”, http://www.fortknoxfcu.org/loststolen.html, Feb. 1, 2001. 2 pages. |
| IEEE Xplore; 2009 First Asian Himalayas International Conference on Internet: Emergence of Payment Systems in the age of Electronic Commerce.; The state off Art. Author S Singh Nov. 1, 2009 pp. 1-18 (Year: 2009). |
| 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). |
| Merrick Bank, “Reporting Lost or Stolen Card Help Return to the Cardholder Center FAQs”, http://www.merrickbank.com/Frequent-Asked-Questions/Report-Stolen-Card.aspx, Aug. 9, 2004. 1 page. |
| Microsoft, “Automatically summarize a document”, 2016. 3 pages. |
| 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). |
| RBC Royal 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. |
| Transaction aggregation as a strategy for credit card fraud detection. file:///C:/Users/eoussir/Downloads/ Transaction_aggregation_as_a_strategy for credit_c. pdf (Year: 2009). |
| Union Bank & Trust, “Report Lost or Stolen Card”, http://www.ubt.com/security-fraud/report-lost-or-stolen-cards Jul. 10, 2005. 13 pages. |
| Using location aware business rules for preventing retail banking frauds. https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7351936 (Year: 2015). |
| Diversinet enables new consumer mobile services from intersections inc.; MobiSecure wallet and vault helps identity management leader get closer to its customers. (May 30, 2007). PR Newswire Retrieved from https://dialog.proquest.com/professional/docview/ 450976918?accountid=131444 on Feb. 22, 2023 (Year: 2007). |
| Smartphones as Practical and Secure Location Verification Tokens for Payments. file:///C:/Users/eoussir/Documents/e-Red% 20 Folder/ 15496961 /N PL_ Smartphones %20as %20 Practical %20and %20Secu re %20 Location %20Verification %20Tokens %20for% 20Payments.pdf (Year: 2014). |
| Urein et al: “A breakthrough for prepaid payment: End to end token exchange and management using secure SSL channels created by EAP-TLS smart cards”, 2011 International Conference on Collaboration Technologies and Systems (CTS) (Year: 2011). |
| Yang MH. Security enhanced EMV-based mobile payment protocol. Scientific World Journal. 2014.https://www.ncbi.nlm.nih.gov/ pmc/articles/PMC4181509/ (Year: 2014). |
| Eickhoff et al: “Quality through Flow and Immersion: Gamifying Crowdsourced Relevance Assessments” ,Proceedings of the 35th international Acm Sigir conference on Research and development in information retrieval, Aug. 12, 2012. (Year: 2012). |
| Hinze et al.; Event-Based Applications and Enabling Technologies. https://www.researchgate.net/profile/Annika-Hinze/publication/220796268_Event-based_applications_and_enabling_technologies/Links/0fcfd 50b638d9592a1000000/Event-based-applications-and-enabling-technologies.pdf (Year: 2009). |
| Yang, Ming-Hour; Security Enhanced EMV-Based Mobile Payment Protocol. https://patents.google.com/scholar/ 15767854982483958498?q (Security Enhanced EMV-Based Mobile Payment Protocol)&patents=false&scholar&oq=Security Enhanced EMV-Based Mobile Payment Protocol (Year: 2014). |
| Number | Date | Country | |
|---|---|---|---|
| 62139525 | Mar 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15081536 | Mar 2016 | US |
| Child | 17897551 | US |
