HK40003961A - Mirrored token vault - Google Patents

Description

Mirror image token vault

Cross reference to related applications

This application is a non-provisional application and claims the benefit of U.S. patent application No. 62/374,711 entitled "Third party token Service Provider" (Third party PartyToken Service Provider) filed on 12/8/2016, which is incorporated herein by reference in its entirety for all purposes.

Technical Field

Background

A token may be used in place of an account identifier in the transaction processing system. An entity is a transaction processing system that can use a token to generate, process, and approve/deny authorization request messages for a transaction. The transaction may be used to obtain a resource, good, or service provided by a resource provider.

In conventional systems, a token generating entity (e.g., a token service provider) stores a generated token and data associated with the token at a storage device (e.g., a token vault). Thus, in conventional systems, the token generating entity is responsible for all token-related activities, and does not participate in all information about the user and/or account associated with the token.

Conventional processes for storing and processing tokens may be inefficient. The token service provider is responsible for generating and processing tokens. However, token service providers typically do not possess all information about the user and/or account associated with the token. For example, the token may represent an account identifier associated with a first account issued to the user by a first issuer. A transaction using the first account may be processed by a first transaction processing entity. The user may have at least a second account issued by a second issuer and at least a third account issued by the first issuer. Transactions using the second account may be processed by the first transaction processing entity and transactions using the third account may be processed by the second transaction processing entity.

When the token service provider is the first transaction processing entity, the token service provider will have information about the first account and the second account. However, the token service provider will not have information about the third account. When the token service provider is the first issuer, the token service provider will have information about the first account and the third account. However, the token service provider will not have information about the second account. Thus, during processing of the token, the token service provider may not possess all of the information for making a discreet determination as to whether the transaction (e.g., authorization request) should be approved/denied.

It would be desirable to provide systems and methods that can allow token data to be stored at multiple locations managed by different entities to provide redundancy, and that can allow token processing responsibilities to be divided among different entities to better prevent fraud by allowing parties to perform different data analyses using data that is available to the respective entities.

Further, in conventional systems, the token and token data are stored at a single location (e.g., a token vault). Thus, when the token vault is attacked by a hacker, sensitive information can be cracked.

Embodiments of the present invention address this and other problems, individually and collectively.

Disclosure of Invention

Embodiments provide systems and methods of storing tokens and token data at multiple locations managed by different entities. Thus, embodiments provide redundancy when one of the token storage locations is compromised or otherwise becomes unavailable. Embodiments further allow dividing token processing responsibilities among the different entities to better prevent fraud by having parties perform different data analyses using data available to the respective entities.

Embodiments of the present invention relate to a method performed by a server computer for storing tokens and data associated with the tokens at a first token vault and a second token vault. The method may include receiving an authorization request message including the token. The authorization request message is associated with a transaction. The method may also include retrieving, from the first token vault, an account identifier represented by the token and data associated with the token. The account identifier is associated with a user account. The first token vault storing a first set of data associated with the token is synchronized with the second token vault storing a second set of data associated with the token. The method may further include transmitting, to an authorization entity, a modified authorization request message including the token and the data associated with the token. The data associated with the token includes at least the account identifier. The method also includes receiving an authorization response message from the authorizing entity authorizing or denying the transaction. The authorizing entity retrieves additional data associated with the token from the second token vault and approves or denies the transaction based on at least the additional data.

Embodiments of the invention further relate to a server computer that includes a processor and a memory element. The memory element may comprise code executable by the processor for implementing the method described above.

Embodiments of the present invention further relate to a method performed by a server computer for storing tokens and data associated with the tokens at a first token vault and a second token vault. The method includes generating a token representing an account identifier associated with a user account, and storing the token and a mapping between the token and the account identifier at the first token vault. The server computer manages the first token vault. The method further comprises synchronizing the first token vault with the second token vault. The first token vault stores a first set of data associated with the token and the second token vault stores a second set of data associated with the token. The method also includes receiving an authorization request message that includes the token and data associated with the token. The data associated with the token includes at least the account identifier, and the authorization request message is associated with a transaction. The method includes generating an authorization response message authorizing or denying the transaction, and transmitting the authorization response message to a transaction processing computer.

These and other embodiments of the invention are described in further detail below.

Drawings

FIG. 1A illustrates a block diagram of a tokenization and transaction processing environment, in accordance with various embodiments.

FIG. 1B illustrates a block diagram of a tokenization and transaction processing environment including a third party token service provider, in accordance with various embodiments.

FIG. 2 illustrates a block diagram showing basic components that may reside in an exemplary token service provider computer.

FIG. 3 illustrates a block diagram of token provisioning in a tokenization environment, in accordance with various embodiments.

Fig. 4 illustrates a block diagram of token lifecycle updates initiated by a wallet provider in a tokenization environment, in accordance with various embodiments.

FIG. 5 illustrates a block diagram of issuer-initiated token lifecycle updates in a tokenized environment, in accordance with various embodiments.

FIG. 6 illustrates a block diagram of an authorization process in a tokenized environment, in accordance with various embodiments.

FIG. 7 illustrates a block diagram of an alternative authorization process in a tokenized environment, in accordance with various embodiments

Detailed Description

The token may be used to represent an account identifier associated with the user account. For example, the token may represent a primary account number associated with a user's payment account. Alternatively, the token may represent an employment identification number assigned to the employee by the employer. The token may be associated with token data such as a token expiration date, a token assurance level, a token type, a token status indicator, a device identifier associated with the token (e.g., a token requestor identifier), an account identifier expiration date, a token assurance level, a domain restriction (and/or underlying user account) associated with the token, and so forth. The tokens and associated token data may be stored at one or more token vaults (e.g., token databases).

Embodiments relate to a first token vault managed by a token service provider (e.g., a token generation entity) and a second token vault managed by a second entity (e.g., a transaction processing network, a resource provider, an authorization entity, etc.). The first token vault is continuously synchronized with the second token vault in real time. That is, the data in the second token vault is updated simultaneously with or immediately after the data in the first token vault is updated. In some embodiments, the first token vault may be a master token vault and the second token vault may be a mirror token vault. The mirror token vault may store the same information as the master token vault. Alternatively, the mirror token vault may store a subset of the information stored at the master token vault. In other embodiments, the information stored at the first token vault and the information stored at the second token vault may be mutually exclusive.

In some embodiments, the token service provider may be a transaction processing network and the second entity managing the second token vault may be an issuer of a user account represented by the token. The transaction processing network may store a first set of data associated with the token at a first token vault, while the issuer may store a second set of data associated with the token at a second token vault. For example, the first set of data may include one or more of: an account identifier associated with the token, a token expiration date, a token status indicating whether the token is valid or invalid, an expiration date of the account identifier, an identifier of an entity requesting generation of the token (e.g., a requestor identifier). The second set of data may include one or more of: domain restrictions associated with a token, override authorization associated with a token, and the like

Before discussing particular embodiments of the invention, some terms may be described in detail.

A "communication device" may comprise any suitable device that may allow communication with an external entity. A communication device may be a mobile device if the mobile device has the capability to communicate data to and from external entities.

A "mobile device" may include any suitable electronic device that a user may transport and operate, which device may also provide the ability to communicate remotely with a network. Examples of remote communications capabilities include the use of a mobile telephone (wireless) network, a wireless data network (e.g., 3G, 4G, or the like), Wi-Fi, Wi-Max, or any other communications media that can provide access to a network such as the internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablets, netbooks, laptops, personal music players, handheld application specific readers, and so forth. Other examples of mobile devices include wearable devices such as smart watches, fitness bracelets, foot chains, rings, earrings, and the like, as well as automobiles with telecommunication capabilities. A mobile device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., two devices that are linked together may be considered a single mobile device when the devices are shared over a network to another device-i.e., remotely accessing the network using the other device as a modem).

"payment means" may comprise a device that may be used to conduct financial transactions, such as providing a merchant with a payment voucherAny suitable device for authentication. The payment device may be a software object, a hardware object, or a physical object. As an example of a physical object, the payment device may include a substrate, such as a paper or plastic card, and information printed, embossed, encoded, or otherwise contained at or near the surface of the object. A hardware object may relate to a circuit (e.g., a permanent voltage value), while a software object may relate to non-permanent data stored on a device. The payment device may be associated with a value such as a monetary value, discount, or store credit, and the payment device may be associated with an entity such as a bank, merchant, payment processing network, or individual. The payment device may be used to conduct a payment transaction. Suitable payment devices may be hand-held and compact such that they can be placed into a user's wallet and/or pocket (e.g., pocket-sized). Example payment devices may include smart cards, magnetic stripe cards, keychain devices (e.g., Speedpass available from Exxon-Mobil, Inc.)^TM) And so on. Other examples of mobile devices include pagers, debit cards, security cards, access cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit or smart card, the payment device may also optionally have features such as a magnetic stripe. Such devices may operate in either a contact or contactless mode. In some embodiments, the mobile device may function as a payment device (e.g., the mobile device may store and be able to transmit payment credentials for a transaction).

A "credential" may be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable character, and any object or document that may serve as a confirmation. Examples of credentials include value credentials, identification cards, notary documents, access cards, passwords and other login information, and the like.

The "payment credentials" may include any suitable information associated with the account (e.g., the payment account and/or the payment device associated with the account). Such information may be directly related to the account, or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or "account number"), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so forth. CVV2 is generally understood to be a static verification value associated with a payment device. The CVV2 values are typically visible to a user (e.g., a user), while the CVV and dCVV values are typically embedded in memory or in an authorization request message and are not readily known to the user (but are known to the issuer and payment processor). The payment credential may be any information identifying or associated with the payment account. Payment credentials may be provided for payment from a payment account. The payment credentials may also include a username, an expiration date, a gift card number or code, and any other suitable information.

A "digital wallet" may include an electronic device that allows an individual to conduct e-commerce transactions. The electronic wallet may store user profile information, payment credentials, bank account information, one or more digital wallet identifiers, and the like, and may be used in various transactions such as, but not limited to, e-commerce, social networking, account transfer/personal payment, mobile commerce, proximity payment, gaming, and the like, for retail purchases, digital goods purchases, utility payments, purchases of gaming or lottery tickets from a gaming website, transfers funds between users, and the like. The digital wallet may be designed to simplify the purchase and payment process. The digital wallet may allow a user to load one or more payment cards onto the digital wallet for payment without entering an account number or presenting a physical card.

A "digital wallet provider" or "wallet provider" may include an entity, such as an issuing bank or third party service provider, that issues a digital wallet to a user that enables the user to conduct financial transactions. The digital wallet provider may provide a separate user-oriented software application that stores an account number or representation of an account number (e.g., a payment token), facilitates payment at more than one unrelated merchant on behalf of the cardholder (or other user), performs person-to-person payments, or loads financial value into a digital wallet. The digital wallet provider may enable a user to access their account via a personal computer, mobile device, or access device. In addition, the digital wallet provider may also provide one or more of the following functions: storing a plurality of payment cards and other payment products on behalf of a user; storing other information including billing addresses, shipping addresses, and transaction history; the transaction is initiated by one or more methods, such as providing a username and password, NFC, or a physical token, and a pass-through or two-step transaction may be facilitated.

The "token" may contain an alternative identifier for some information. For example, the payment token may contain an identifier of the payment account that is a substitute for an account identifier, such as a Primary Account Number (PAN). For example, the token may contain a series of alphanumeric characters that may be used as a substitute for the original account identifier. For example, the token "4900000000000001" may be used in place of PAN "4147090000001234". In some embodiments, the token may be in a "reserved format" and may have a numeric format consistent with an account identifier used in existing payment processing networks (e.g., ISO8583 financial transaction message format). In some embodiments, the token may be used in place of the PAN to initiate, authorize, settle, or resolve payment transactions. In other systems that typically provide the original credential, the token may also be used to represent the original credential. In some embodiments, the token value may be generated such that a recovery of the original PAN or other account identifier may not be computationally derived from the token value. Additionally, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and identify the entity that issued the token.

The "account identifier" may contain the original account identifier associated with the payment account. For example, the account identifier may be a Primary Account Number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.). For example, in some embodiments, the account identifier may comprise a sixteen digit value, such as "4147090000001234". The first six digits of the account identifier (e.g., "414709") may represent an issuer identifier (BIN) that may identify the issuer associated with the account identifier.

"tokenization" may include the process of replacing data with substitute data. For example, a payment account identifier (e.g., a Primary Account Number (PAN)) may be tokenized by replacing a primary account identifier with an alternate number (e.g., token) that may be associated with the payment account identifier. Additionally, tokenization may be applied to any other information that may be replaced with an alternative value (i.e., token).

A "token provider" or "token service system" may comprise a system that services a payment token. In some embodiments, the token service system may facilitate requesting, determining (e.g., generating), and/or issuing tokens, as well as maintaining an established mapping of tokens to account identifiers (e.g., a Primary Account Number (PAN)) in a repository (e.g., a token vault). In some embodiments, the token service system may establish a token assurance level for a given token to indicate the token's level of trust for PAN binding. The token service system may comprise or be in communication with a token vault that stores the generated tokens. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the tokens to obtain an actual PAN. In some embodiments, the token service system may comprise only a tokenized computer, or in combination with other computers, such as transaction processing network computers. Various entities of the tokenized ecosystem can assume the role of a token service provider. For example, a payment network and issuer or its agents may become a token service provider by implementing a token service according to embodiments of the present invention.

The "token vault" may include a repository that maintains established token mappings. Which may be present in the token service computer. According to various embodiments, the token vault may also maintain other attributes of the token requestor that may be determined at registration time. The token provider may use the attributes to apply domain restrictions or other controls during transaction processing. In some embodiments, the token vault may be part of the token provider. Alternatively, the token vault may be a remote repository available to the token provider. The token vault may be protected by strong underlying physical and logical security due to the sensitive nature of the data maps stored and managed therein.

A "token domain" may indicate an area and/or environment in which a token may be used. Examples of token domains may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS input modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token may be used. A set of parameters (i.e., token domain restriction controls) may be established by the token service provider as part of token issuance that may allow for enforcement of appropriate use of the token in a payment transaction. For example, the token domain restriction control can restrict use of the token in a particular presentation mode (e.g., contactless or e-commerce presentation mode). In some embodiments, the token domain restriction control may restrict use of the token at a particular merchant that may be uniquely identified. Some exemplary token domain restriction controls may require verification of the presence of a token password that is unique to a given transaction. In some embodiments, a token domain may be associated with a token requestor.

The "token data" may include data associated with the token. For example, the token data may include an account identifier (e.g., a Primary Account Number (PAN)), a mapping between the token and the account identifier, an account identifier expiration date (e.g., a PAN expiration date), a token assurance level, a token requestor identifier, a token state identifier, a token type, a device identifier that provided or generated the token, and so forth.

"token exchange" or "de-tokenization" may include processes to recover data that was replaced during tokenization. For example, token exchange may include replacing a payment token with a Primary Account Number (PAN) associated with the payment token during tokenization of the PAN. Thus, de-tokenization may refer to the process of redeeming tokens for associated PAN values based on token-to-PAN mappings stored, for example, in a token vault. The ability to retrieve a PAN to exchange an associated token may be limited to a particular authorized entity, person, application or system. In addition, de-tokenization or token exchange may be applied to any other information. In some embodiments, token exchange may be accomplished via a transaction message, such as an ISO message, an Application Programming Interface (API), or another type of network interface (e.g., a network request). Token exchange may also be accomplished via credential request messages whereby a requesting entity, which may be a token holder, makes a request to receive a PAN associated with a token.

The "token request message" may be an electronic message for requesting a token. The token request message may contain information that may be used to identify the payment account or digital wallet, and/or information used to generate the payment token. For example, the token request message may include payment credentials, mobile device identification information (e.g., a telephone number or MSISDN), a digital wallet identifier, information identifying the tokenized service provider, a merchant identifier, a password, and/or any other suitable information. The information contained in the token request message may be encrypted (e.g., using an issuer-specific key).

The "token response message" may be a message that responds to a token request. The token response message may contain an indication that the token request is approved or denied. The token response message may also contain a payment token, mobile device identification information (e.g., a telephone number or MSISDN), a digital wallet identifier, information identifying the tokenized service provider, a merchant identifier, a password, and/or any other suitable information. The information contained in the token response message may be encrypted (e.g., using an issuer-specific key).

A "user" may comprise an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. The user may also be referred to as a cardholder, account holder, or consumer.

A "resource provider" may be an entity that may provide resources, such as goods, services, information, and/or access. Examples of resource providers include merchants, access devices, secure data access points, and the like. A "merchant" may generally be an entity that participates in a transaction and may sell or provide access to goods or services.

An "acquirer" can generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such single entity issuer-acquirers. The acquirer may operate an acquirer computer, which may also be collectively referred to as a "transport computer".

An "authorizing entity" may be the entity that authorizes the request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, and so forth. An "issuer" may generally refer to a business entity (e.g., a bank) that maintains a user's account. The issuer may also issue payment credentials to the consumer that are stored on a user device, such as a cell phone, smart card, tablet, or laptop.

An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, such as at a merchant location. The access means may be in any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, Personal Computers (PCs), tablet PCs, hand-held dedicated readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, and the like. The access device may use any suitable contact or contactless mode of operation to send or receive data to or from the user mobile device or to associate with the user mobile device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may contain a reader, processor, and computer readable medium. The reader may include any suitable contact or contactless mode of operation. For example, an exemplary card reader may include a Radio Frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with a payment device and/or a mobile device. In some embodiments, a cellular phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.

A "server computer" may comprise a powerful computer or cluster of computers. For example, a server computer system may be a mainframe, a minicomputer cluster, or a group of servers that function as a unit. In one example, the server computer may be a database server coupled to a network server. A server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing requests from one or more client computers. The server computer may include one or more computing devices and may service requests from one or more client computers using any of a variety of computing structures, arrangements, and compilations.

An "authorized entity" is an entity that can authorize or approve an interaction. The authorizing entity may generally refer to a business entity (e.g., a bank) that maintains an account for the user and is capable of authorizing interactions, such as payment transactions, e.g., purchases of goods or services. An issuer is an instance of an "authorizing entity" that can operate an authorizing entity computer. Other examples of authorized entities may include government departments, transportation departments, and the like.

An "authorization request message" may be an electronic message sent to request authorization of a transaction. The authorization request message may be sent to the payment processing network and/or the issuer of the payment card. The authorization request message according to some embodiments may comply with ISO8583, ISO8583 being a standard of systems for exchanging electronic transaction information associated with payments made by users using payment devices or payment accounts. The authorization request message may contain information that may be used to identify the account. The authorization request message may also include additional data elements, such as one or more of a service code, an expiration date, and the like. The authorization request message may also include transaction information, such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that may be used to determine whether to identify and/or authorize the transaction. The authorization request message may also contain other information, such as information identifying the access device that generated the authorization request message, information regarding the location of the access device, and so forth.

The "authorization response message" may be an electronic message reply to the authorization request message. The authorization response message may be generated by the issuing financial structure or the payment processing network. By way of example only, the authorization response message may contain one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-in response to more information pending, the merchant must call the toll free authorization phone number. The authorization response message may also contain an authorization code, which may be a code indicating approval of the transaction that the credit card issuing bank returned to the merchant computer (either directly or through the payment processing network) in response to the authorization request message in the electronic message. The code may act as proof of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

A "memory" may be any suitable device or devices that can store electronic data. Suitable memories may include non-transitory computer-readable media that store instructions that are executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, and the like. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.

A "processor" may refer to any suitable data computing device or devices. The processor may include one or more microprocessors that work together to achieve the desired functionality. The processor may comprise a CPU including at least one high speed data processor sufficient to execute program components for executing user and/or system generated requests. The CPU may be a microprocessor, such as AMD's fast dragon (Athlon), drill dragon (Duron), and/or gosauron (Opteron); PowerPC from IBM and/or Motorola; cell processors by IBM and Sony (Sony); intel (Intel) sialon (Celeron), Itanium (Itanium), Pentium (Pentium), to strong (Xeon) and/or XScale; and/or the like.

Embodiments relate to storing tokens and data associated with the tokens (e.g., an account identifier represented by the token, a mapping between the token and the account identifier, a token expiration date, a token status indicating whether the token is valid or invalid, an expiration date of the account identifier, an identifier of the entity requesting generation of the token (e.g., a requestor identifier), a domain restriction associated with the token, an override authorization associated with the token, etc.) at a plurality of locations, at least a first token vault managed by a token service provider (e.g., a token generation entity) and a second token vault managed by a second entity (e.g., a transaction processing network, a resource provider, an authorization entity, etc.). The first token vault is continuously synchronized with the second token vault in real time. That is, the data in the second token vault is updated simultaneously with or immediately after the data in the first token vault is updated.

In some embodiments, the first token vault may be a master token vault and the second token vault may be a mirror token vault. The mirror token vault may store the same information as the master token vault. Alternatively, the mirror token vault may store a subset of the information stored at the master token vault. In other embodiments, the information stored at the first token vault and the information stored at the second token vault may be mutually exclusive.

Embodiments enable a third party entity (an entity other than the transaction processing entity) to act as a token service provider. FIG. 1A illustrates a block diagram of a tokenization and transaction processing environment 150, in accordance with various embodiments. The user 102 may communicate with the token service provider computer 152 via the communication network 106 using the user communication device 104. For example, the user 102 may be an account holder of an account issued by the authorized entity computer 112. The user 102 (or the authorizing entity computer 112) may request an account identifier that identifies the account to be represented using the token. The token service provider computer 152 may generate a token representing an account identifier and store the token, the corresponding account identifier, and a mapping between the token and the account identifier at the first token vault 110. The token service provider computer 152 may also store additional token data at the first token vault 110. For example, the additional token data may include one or more of the following at a plurality of locations, at least a first token vault managed by a token service provider (e.g., a token generation entity) and a second token vault managed by a second entity (e.g., a transaction processing network, a resource provider, an authorization entity, etc.): a token expiration date, a token status indicating whether the token is valid or invalid, an expiration date of an account identifier, an identifier of an entity requesting generation of the token (e.g., a requestor identifier), a domain restriction associated with the token, an override authorization associated with the token, and so forth.

The token service provider computer 152 may also send the token and at least a subset of the data associated with the token to the authorizing entity computer 112 via the communication network 106. The authorizing entity computer 112 may store the received token and token data at the second token vault 114. The first token vault 110 and the second token vault 114 may be continuously synchronized, for example by a token generating entity, in real time. That is, when the contents of the first token vault 110 are updated, the contents of the second token vault 114 are automatically updated. In some embodiments, the data stored at the first token vault 110 may be the same as the data stored at the second token vault 114. That is, the second token vault 114 may be a back-up vault that mirrors the contents of the first token vault 110 (e.g., the first token vault 110 and the second token vault 14 are non-mutually exclusive). Alternatively, the data stored at the second token vault 114 may be a subset of the data stored at the first token vault 110. In some embodiments, the data stored at the first token vault 110 and the data stored at the second token vault 114 may be mutually exclusive.

After generating the token, the token service provider computer 152 may return the token to the user 102 via the communication network 106. The user 102 may present the token to the resource provider computer 108 during a transaction with the resource provider computer 108. For example, the user 102 may request a server or resource provided by the resource provider computer 108. The resource provider computer 108 may generate an authorization request message that includes the token presented by the user 102 and forward the authorization request message to the transaction processing computer 109. The resource provider computer 108 may interact with the token service provider computer 152 to retrieve the account identifier represented by the token. The token service provider computer 152 may receive the token from the transaction processing computer 109, retrieve the account identifier corresponding to the token and token data from the first token vault 110, and return the token and token data to the transaction processing computer 109. The transaction processing computer 109 may modify the authorization request message to incorporate the token and token data received from the token service provider computer 152 into the authorization request message. The transaction processing computer 109 can transmit the modified authorization request message to the authorizing entity computer 112 via the communications network.

In some embodiments, the authorizing entity computer 112 may retrieve additional token data associated with the token from the second token vault 114. The additional token data may be stored only at the second token vault 114 (e.g., may not be stored at the first token vault 110). The authorizing entity computer 112 may determine to approve or deny the authorization request based on at least the token data retrieved from the first token vault 110 and, where applicable, based on additional token data retrieved from the second token vault 114. The authorizing entity computer 112 may generate an authorization response message authorizing or denying the transaction and return the authorization response message to the resource provider computer 108 via the transaction processing computer 109 over the communication network 106. The resource provider computer 108 may provide the service or resource to the user 102 based on the authorization response message.

The communication network 106 may be in the form of any suitable communication network, which may be any one and/or combination of the following: direct interconnects, the internet, Local Area Networks (LANs), Metropolitan Area Networks (MANs), an operational task as an internet node (OMNI), a secure custom connection, a Wide Area Network (WAN), a wireless network (e.g., using a protocol such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.), and so forth.

Messages between entities, providers, networks and devices may be transmitted using secure communication protocols such as, but not limited to: file Transfer Protocol (FTP); hypertext transfer protocol (HTTP); secure hypertext transfer protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and the like.

Fig. 2 illustrates a block diagram showing basic components that may reside in an exemplary token service provider computer 152. In some embodiments of the present invention, the token service provider computer 152 may form part of the transaction processing computer 109, as depicted in FIG. 1B. The token service provider computer 152 includes a processor 200, a network interface 202, and computer readable media 204.

Computer-readable media 204 may include a token generation module 206, a token association module 208, a provisioning module 210, and a communication module 212.

The token generation module 206 may include code that causes the processor 200 to generate a token. In some embodiments, the token may comprise a 16-digit number and may be similar to a PAN.

The token association module 208 may include code that causes the processor 200 to associate the token with other data (e.g., user data including an email address, a phone number, a main account number, etc., token data including a token expiration date, a token requestor identifier, etc.). For example, the token association module 208 may contain logic that causes the processor 200 to link the generated token with the received user input data and store the information in the first token vault 110.

Provisioning module 210 may include code that causes processor 200 to provision a token. For example, provisioning module 210 may contain logic that causes processor 200 to generate a provisioning script and provide the provisioning script, token, and any other suitable information to an electronic notification apparatus.

The communication module 212 may include code that causes the processor 200 to generate messages, reformat messages, and/or otherwise communicate with other entities. For example, the communication module 212 may contain logic that causes the processor 200 to identify a token in a received message and return a true credential associated with the token in response.

According to some embodiments, the token service provider computer 152 may form part of the authorizing entity computer 112. The authorizing entity computer 112 may generate a token representing an account identifier associated with the user account and store the token and a mapping between the token and the account identifier at a first token vault. The authorizing entity may manage the first token vault. The authorizing entity computer 112 may continuously synchronize the first token vault with the second token vault. The second token vault may be managed by a different entity. The first token vault may store a first set of data associated with the token and the second token vault may store a second set of data associated with the token. The second data set stored at the second token vault may be a subset of the first data set stored at the first vault. The authorizing entity computer 112 may receive an authorization request message associated with the transaction. The authorization request message may include the token and data associated with the token (e.g., an account identifier). The authorizing entity computer 112 may generate an authorization response message authorizing or denying the transaction and transmit the authorization response message to the transaction processing computer.

In fig. 3-7, the token service provider 304 is depicted as a separate entity. However, as explained above, the token service provider 304 may be part of or managed by the transaction processing computer 109 or the authorizing entity computer 112.

FIG. 3 depicts a token provisioning data flow 312 among entities of a tokenization and transaction processing environment. As depicted in fig. 3, a user 300 (e.g., an account holder) may send a message 316 to a token service provider 304 via a wallet provider 302. The message may include an account identifier (e.g., a Primary Account Number (PAN)) as well as additional information (e.g., an account identifier expiration date, user information, user device information, etc.). The token service provider 304 may confirm with the authorizing entity 306 (e.g., the issuer) that the account identifier is eligible or qualified for provisioning on the user device. Upon receiving token provisioning response message 318 from authorizing entity 306, token service provider 304 may then generate the token and store the token and the mapping between the token and the account identifier at first token vault 324. The token service provider 304 may manage a first token vault 324.

In some embodiments, the token service provider 304 may provide the token and associated token data (e.g., a mapping between the generated token and a corresponding account identifier, a token expiration date, a token requestor identifier, etc.) to the transaction processing entity 308 such that the transaction processing entity 308 may store the received data at a second token vault 326 that is managed and/or made available by the transaction processing entity 308. In some embodiments, the token service provider 304 may provide the transaction processing entity 308 with a subset of the token data stored at the first token vault 324. For example, token service provider 304 may not provide a copy of the token to the payment processing network, but rather provide a token-account identifier mapping. If the transaction processing entity 308 does not manage the token provisioning (e.g., when the provisioning is handled by the token service provider 304), the transaction processing entity 308 may not need to obtain a token.

Embodiments may support synchronizing the first token vault 324 and the second token vault 326 in real time. That is, the contents of the second token vault 326 may be updated substantially simultaneously with the contents of the first token vault 324. For example, the token service provider 304 may send a message 320 to the transaction processing entity 308 that includes token data stored at the first token vault 324. When the transaction processing entity 308 stores the received token data at the second token vault 326, the transaction processing entity 308 may send a token vault synchronization response message 322 to the token service provider 304 to confirm that the contents of the second token vault 326 have been updated. According to various embodiments, token vault synchronization messages 320 and 322 may be based on an industry standard for messages, such as ISO 0302. In the exemplary embodiment depicted in FIG. 3, the contents of the first token vault 324 may be the same as the contents of the second token vault 326.

The token may need to be updated when the token or base account/account identifier has changed or the token has expired. Fig. 4 depicts an exemplary token lifecycle update 400 process that includes a token update request 402 initiated by the wallet provider 302. Wallet provider 302 may send token update request message 404 to token service provider 304. The token update request message 404 may contain the token and updated information. The token service provider 304 may update the first token vault 324 with information received from the wallet provider 302. The token service provider 304 may then synchronize the first token vault 324 with the second token vault 326 by sending a token update message 406 to the transaction processing entity 308 that manages the second token vault 326. When the transaction processing entity 308 updates the contents of the second token vault 326, the transaction processing entity 308 may send a token vault synchronization confirmation message 408 to the token service provider 304. In some embodiments, token service provider 304 may inform authorization entity 306 of the updated token information. For example, token service provider 304 may send token update message 410 including the token and updated information to authorization entity 306. Authorization entity 306 may send token update construct message 412 to token service provider 304 confirming receipt of the updated token and/or token data.

In some embodiments, an entity other than the wallet provider may request that the token or data associated with the token be updated. Fig. 5 depicts an exemplary token lifecycle update 500 process that includes a token update request 502 initiated by the authorizing entity 306. Authorization entity 306 may send token update request message 504 to token service provider 304. The token update request message 504 may contain the token and updated information. The token service provider 304 may update the first token vault 324 with information received from the authorizing entity 306. The token service provider 304 may then synchronize the first token vault 324 with the second token vault 326 by sending a token update message 506 to the transaction processing entity 308 that manages the second token vault 326. When the transaction processing entity 308 updates the contents of the second token vault 326, the transaction processing entity 308 may send a token vault synchronization confirmation message 508 to the token service provider 304. In some embodiments, token service provider 304 may inform wallet provider 302 of the updated token information. For example, the transaction processing entity 308 may send a token update message 510 to the wallet provider 302 that includes the token and updated information. Wallet provisioning 302 may send token update construct message 512 to token service provider 304 confirming receipt of the updated token and/or token data.

As explained above, when token service provider 304 generates a token, token service provider 304 may return the token to user 302. The user may present a token to the resource provider 350 during a transaction with the resource provider 350 for the user 302 to obtain a service or resource provided by the resource provider 350. Upon receiving the token, the resource provider 350 may begin the authorization process 600, as depicted in fig. 6.

Fig. 6 illustrates an authorization process 600, which has two main components: an authorization request 602 and an authorization response 612 associated with the transaction. During the authorization request 602, the resource provider 350 generates an authorization request message 604 and sends the authorization request message 604 to the transaction processing entity 308. The authorization request message 604 may include the token, the token expiration date received from the user 302, and any additional data associated with the token (e.g., token presentation mode), the user device (e.g., device identifier, whether the user device has a cryptographic processor, and whether data received from the user device is encrypted), the resource provider's device (e.g., device identifier), and/or the transaction.

In the embodiment depicted in fig. 6, the transaction processing entity 308 may manage a first token vault 324, the first token vault 324 storing at least tokens, account identifiers associated with the tokens, and mappings between the tokens and the account identifiers. Thus, the transaction processing entity 308 may de-tokenize the token and generate a modified authorization request message 605 that includes at least the account identifier (e.g., PAN) and the token. The de-tokenization may include retrieving, from the first token vault, an account identifier represented by the token and data associated with the token. The modified authorization request message 605 may also contain an account identifier expiration date and a token expiration date. Transaction processing entity 308 may transmit a modified authorization request message 605 to authorization entity 306.

The authorizing entity 306 may retrieve the additional data from the second token vault 326 via the token service provider 304. The second token vault 326 may store additional data associated with the tokens. For example, the second token vault 326 may store domain controls, cryptographic authentication keys, and the like. In some embodiments, the token service provider 304 may send the transaction history 608 associated with the account identifier and/or token to the authorizing entity 306. A transaction history 608 associated with the token may be stored at the second token vault 326. The authorizing entity 306 may determine to approve or deny the transaction based on data retrieved from the first token vault 324 and the second token vault 326.

As part of the authorization response 612 of the authorization process 600, the authorization entity 306 may generate an authorization response message 614 and send the authorization response message 614 to the transaction processing entity 308. Authorization response message 614 may include at least a primary account identifier and an indication of whether to approve or decline the transaction. Authorization response message 614 may also include a chip verification indicator. Transaction processing entity 308 may generate a modified authorization response message 616 to replace the account identifier with the corresponding token and send the modified authorization response message 616 to resource provider 350. Resource provider 350 may notify user 302 whether the transaction is approved or denied at step 618.

In some embodiments, the transaction processing entity 308 may "override" the authorizing entity 306 and approve or deny the authorization request in lieu of the authorizing entity 306.

Fig. 7 shows an alternative authorization process 700, which has two main components: an authorization request 702 and an authorization response 712. Similar to the process in fig. 6, the resource provider 350 generates an authorization request message 704 and sends the authorization request message 704 to the transaction processing entity 308. The authorization request message 704 may include the token, the token expiration date received from the user 302, and any additional data associated with the token (e.g., token presentation mode), the user device (e.g., device identifier, whether the user device has a cryptographic processor, and whether data received from the user device is encrypted), the resource provider's device (e.g., device identifier), and/or the transaction. The transaction processing entity 308 may de-tokenize the token and generate a modified authorization request message 706 that includes at least the account identifier (e.g., PAN) and the token. The modified authorization request message 706 may also include an account identifier expiration date and a token expiration date. Transaction processing entity 308 may transmit a modified authorization request message 706 to authorization entity 306.

If the transaction processing entity 308 does not receive a response from the authorizing entity 306 by a predetermined time (or within a predetermined amount of time), the transaction processing entity 308 may begin an alternate authorization process and may send a token data request message 708 to the token service provider 304 to request additional token data associated with the token from the second token vault 326. For example, the second token vault 326 may store domain controls, cryptographic authentication keys, and the like. In some embodiments, the token service provider 304 may send the transaction history 608 associated with the account identifier and/or token to the transaction processing entity 308. A transaction history 608 associated with the token may be stored at the second token vault 326. The transaction processing entity 308 may determine to approve or deny the transaction based on data retrieved from the first token vault 324 and the second token vault 326.

Transaction processing entity 308 may generate authorization response message 714 and send authorization response message 714 to resource provider 350. The authorization response message 714 may contain the token and an indication of whether to approve or reject the transaction. The authorization response message 714 may also include a chip verification indicator. Resource provider 350 may notify user 302 whether the transaction is approved or denied at step 716. Transaction processing entity 308 may also notify authorization entity 306 of the results of the authorization process. Transaction processing entity 308 may send authorization proposal message 718 to authorization entity 306. The authorization advice message 718 may include at least an account identifier and an indication of whether to approve or decline the transaction. The authorization proposal message 718 may also include a chip verification indicator.

Even though the embodiments discussed above in connection with fig. 3-7 depict the token service provider 304 as a separate entity, in some embodiments, the transaction processing entity 308 or the authorization entity 306 may still act as the token service provider 304, as depicted in fig. 1B.

There may be several technical benefits to storing tokens and token data at more than one token vault. For example, using at least two token vaults to store token data provides redundancy for security purposes. When the second token vault is a mirror vault (e.g., the second token vault stores the same data as the first token vault), the mirror vault provides a less secure backup of the token data.

Another technical benefit provided by embodiments is the ability to separate the functionality of token generation, processing, and management between entities that manage a token vault. For example, a first entity managing a first token vault that stores at least tokens, corresponding account identifiers, and mappings between tokens and account identifiers may receive a transaction request that includes a token and de-tokenize the transaction request (e.g., replace the token with the corresponding account identifier). In another aspect, a second entity managing a second token vault that stores domain restrictions associated with tokens may apply the domain restrictions. The separation of functionality may better prevent fraud because the first and second entities may perform respective data analysis based on manipulation of different data that is only available to each of these entities.

For example, the first entity may be a transaction processing entity. The transaction processing entity may have more information about potential security breaches at a resource provider (e.g., a merchant) and may identify a transaction request from a particular resource provider as fraudulent. Similarly, the transaction processing entity will have more information about user accounts issued by several issuers. For example, the transaction processing entity may identify that a first user account issued by a first entity is compromised. Thus, the transaction processing entity may choose to block transactions for a second user account of the same user issued by a second issuer. The first issuer may not participate in this information because the second user account is not issued by the first issuer.

The second entity may be an authorized entity (e.g., an issuer of an account represented by the token). The authorized entity will have more information about the user. For example, the user may notify the issuer that the user data was compromised (e.g., the user's wallet may be stolen). In this case, the issuer may determine that user accounts (e.g., MasterCard accounts and VISA accounts of the user) of different transaction processing entities issued by the same issuer are to be compromised. Alternatively, if a user account of one transaction processing entity (e.g., the user's MasterCard account) is blocked for some reason, the issuer may closely review transactions associated with another account of the user (e.g., the user's VISA) account. Thus, it may be beneficial to separate the functionality associated with the token, as different entities possess different information and perform different data analysis using the available information.

As explained above, storing token data at multiple token vaults may enable different entities to perform different token generation, processing, and management functions, which may provide a flexible authorization process. For example, when a token vault managed by an authorizing entity stores domain restrictions associated with a token, the authorizing entity may determine to cover transactions that are to be denied based on the domain restrictions and allow the transactions.

Embodiments further provide for a faster authorization process. Even when the transaction processing entity applies domain restrictions, the authorizing entity acts as the final decision point for approving/denying the transaction. However, if the authorized entity applies the domain restriction, the result of the "apply restriction" is to approve/deny the transaction, thereby eliminating one step of the process.

The various participants and elements described herein with reference to fig. 1-7 may operate one or more computer devices to facilitate the functionality described herein. Any of the elements in fig. 1-7, including any servers or databases, may use any suitable number of subsystems to facilitate the functions described herein.

One or more computer devices and/or subsystems may be interconnected via a system bus. Additional subsystems may include a printer, keyboard, fixed disk (or other memory including computer-readable media), monitor coupled to a display adapter, and other devices. Peripheral devices and input/output (I/O) devices coupled to an I/O controller (which may be a processor or other suitable controller) may be connected to the computer system by any number of means known in the art, such as a serial port. For example, a serial port or external interface may be used to connect the computer device to a wide area network, such as the internet, a mouse input device, or a scanner. The interconnection via a system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from the system memory or the fixed disk, as well as the exchange of information between subsystems. The system memory and/or fixed disk may embody a computer readable medium.

Embodiments of the present invention are not limited to the embodiments described above. For example, while the issuer, payment processing network, acquirer are shown as separate functional blocks, some entities perform all of these functions and may be included in embodiments of the present invention.

Specific details are provided above regarding some of the aspects described above. The specific details of certain aspects may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention. For example, in some embodiments of the invention, back-end processing, data analysis, data collection, and other transactions may all be combined. However, other embodiments of the invention may relate to specific embodiments relating to each individual aspect or specific combinations of these individual aspects.

It should be understood that the invention as described above may be implemented in the form of control logic using computer software (stored in tangible physical media) in a modular or integrated manner. Based on the present disclosure and the teachings provided herein, one of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.

Any of the software components or functions described in this application may be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques, and using any suitable computer language, such as Java, C + +, or Perl. The software code may be stored as a series of instructions or commands on a computer readable medium, such as a Random Access Memory (RAM), a Read Only Memory (ROM), a magnetic medium such as a hard drive or floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable media may reside on or within a single computing device and may exist on or within different computing devices within a system or network.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading the present disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

The recitation of "a/an" or "the" is intended to mean "one or more" unless explicitly indicated to the contrary.

All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. They are not admitted to be prior art.

Claims (20)

1. A method for storing tokens and data associated with the tokens at a first token vault and a second token vault, the method comprising:

receiving, by a server computer, an authorization request message including the token, wherein the authorization request message is associated with a transaction;

retrieving, by the server computer, from the first token vault, an account identifier represented by the token and data associated with the token, wherein the account identifier is associated with a user account, wherein the first token vault storing a first set of data associated with the token is synchronized with the second token vault storing a second set of data associated with the token;

transmitting, by the server computer to an authorization entity, a modified authorization request message including the token and the data associated with the token, wherein the data associated with the token includes at least the account identifier;

receiving, by the server computer, an authorization response message from the authorizing entity that authorizes or denies the transaction, wherein the authorizing entity retrieves additional data associated with the token from the second token vault and approves or denies the transaction based on at least the additional data.

2. The method of claim 1, further comprising:

generating, by the server computer, the token representing the account identifier associated with the user account;

storing, by the server computer, the token and a mapping between the token and the account identifier at a first token vault, wherein the server computer manages the first token vault;

synchronizing, by the server computer, the first token vault with the second token vault.

3. The method of claim 1, further comprising:

upon receiving the authorization request message containing the token, retrieving the token from the authorization request message;

transmitting the token to a token generator service computer to retrieve the account identifier represented by the token from the first token vault, wherein the token generator service computer manages the first token vault.

4. The method of claim 1, wherein the first set of data and the second set of data are mutually exclusive.

5. The method of claim 1, wherein the first set of data and the second set of data are non-mutually exclusive.

6. The method of claim 1, wherein the data associated with the token retrieved from the first token vault includes one or more of: a token status indicator, a device identifier associated with the token, a token expiration date, an account identifier expiration date, a token assurance level, a token type, and a token requestor identifier.

7. The method of claim 1, wherein the additional data is stored only at the second token vault.

8. The method of claim 1, wherein the additional data includes a domain restriction associated with the token, wherein the domain restriction limits use of the token to a particular domain.

9. The method of claim 1, wherein the transaction is approved or denied based on a combination of data retrieved from the first token vault and data retrieved from the second token vault.

10. The method of claim 1 wherein the second token vault stores override data associated with the token.

11. The method of claim 1, wherein the authorization entity's computer is configured to receive the modified authorization request message and to generate and transmit the authorization response message.

12. The method of claim 1 wherein the first token vault is continuously synchronized with the second token vault immediately after modifying content of the first token vault.

13. A server computer, comprising:

a processor; and

a computer-readable medium comprising code that, when executed by the processor, causes the processor to:

receiving an authorization request message including a token, wherein the authorization request message is associated with a transaction;

retrieving an account identifier represented by the token and data associated with the token from a first token vault, wherein the account identifier is associated with a user account, wherein the first token vault storing a first set of data associated with the token is synchronized with a second token vault storing a second set of data associated with the token;

transmitting a modified authorization request message including the token and the data associated with the token to an authorization entity, wherein the data associated with the token includes at least the account identifier;

receiving an authorization response message from the authorizing entity authorizing or rejecting the transaction, wherein the authorizing entity retrieves additional data associated with the token from the second token vault and

approving or rejecting the transaction based on at least the additional data.

14. The server computer of claim 13, wherein the code, when executed by the processor, further causes the processor to:

generating the token representing the account identifier associated with the user account;

storing, at the first token vault, the token and a mapping between the token and the account identifier, wherein the server computer manages the first token vault;

synchronizing the first token vault with the second token vault.

15. The server computer of claim 13, wherein the code, when executed by the processor, further causes the processor to:

upon receiving the authorization request message containing the token, retrieving the token from the authorization request message;

transmitting the token to a token generator service computer to retrieve the account identifier represented by the token from the first token vault, wherein the token generator service computer manages the first token vault.

16. The server computer of claim 13, wherein the authorization entity's computer is configured to receive the modified authorization request message and to generate and transmit the authorization response message.

17. The server computer according to claim 13 wherein the first token vault is continuously synchronized with the second token vault immediately after modifying content of the first token vault.

18. A method for storing tokens and data associated with the tokens at a first token vault and a second token vault, the method comprising:

generating, by the server computer, a token representing an account identifier associated with the user account;

storing, by the server computer, the token and a mapping between the token and the account identifier at the first token vault, wherein the server computer manages the first token vault;

synchronizing, by the server computer, the first token vault and the second token vault, wherein the first token vault stores a first set of data associated with the token and the second token vault stores a second set of data associated with the token;

receiving, by the server computer, an authorization request message including the token and data associated with the token, wherein the data associated with the token includes at least the account identifier, wherein the authorization request message is associated with a transaction;

generating, by the server computer, an authorization response message authorizing or denying the transaction; and

transmitting, by the server computer to a transaction processing computer, the authorization response message authorizing or denying the transaction.

19. The method of claim 18, further comprising:

retrieving, by the server computer, additional data associated with the token from the second token vault, an

Determining, by the server computer, whether to approve or reject the transaction based on at least the additional data.

20. The method of claim 18, wherein the second data set stored at the second token vault is a subset of the first data set stored at the first vault.