Method and system for token gateway

Abstract

A method is disclosed. The method includes receiving, by a token gateway, a first request message from a token requester computer. The token gateway determines at least one token service computer from a plurality of token service computers, each of the plurality of token service computers operating independently of each other. The token gateway transmits at least one second request message to the at least one token serving computer and receives from the at least one token serving computer at least one first response message comprising at least one token and / or supplemental data associated with the at least one token. The token gateway transmits a second response message to the token requester computer, the second response message comprising the at least one token and / or the supplemental data.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2020 / 066462, international application date December 21, 2020, application number 202080086931.1 entering the Chinese national phase, and name “Methods and Systems for Token Gateway”.

[0002] Cross-reference to related applications

[0003] This application claims the benefit of the filing dates of U.S. Provisional Application No. 62 / 951,997, filed December 20, 2019, and U.S. Provisional Application No. 62 / 969,454, filed February 3, 2020. These applications are incorporated by reference in their entirety for all purposes. Background Art

[0004] Access tokens (e.g., payment tokens) can be used to access resources such as goods and services, secure locations, and secure data. Access tokens can replace real credentials. The use of access tokens protects real credentials because the real credentials are not stored or transmitted where they can be accessed by fraudulent entities such as hackers.

[0005] In some access token systems, a token requester (e.g., a mobile phone) can request a token from a token service provider. However, since a token requester can have many accounts, the token requester can interact with many different token service providers. This requires the token requester to interact with each token service provider to obtain a token. If a token requester has ten tokenization accounts, the token requester will have to interact with the token service providers using ten different APIs or interfaces. If there are thousands of token requesters, updating and maintaining all those connections and interfaces can be cumbersome.

[0006] More specifically, in today's era, users use multiple channels to conduct transactions, and commercial entities provide seamless multi-channel commerce experiences through mobile devices, mobile applications, web browsers, and Internet of Things (IoT) devices. Therefore, using tokens as a substitute for real payment credentials will require consumers to manage secure communications with each token service provider associated with a specific transaction channel. In addition, consumer devices will need to implement specific integrations with each connected token service provider. Such tokenization schemes are not flexible and / or scalable.

[0007] Additionally, each token requester can only interact with one token service provider at a time. This is restrictive and can be problematic for token requesters. For example, if a particular token service provider is temporarily unavailable or slow, this can make it difficult for the token requester to conduct a transaction.

[0008] Therefore, there is a need for improved tokenization systems and methods. Embodiments of the present invention address these and other problems individually and collectively. Summary of the invention

[0009] According to one embodiment, a method is provided. The method includes receiving a first request message from a token requestor computer by a token gateway. The token gateway determines at least one token service computer from a plurality of token service computers, each of the plurality of token service computers operating independently of one another. The token gateway transmits at least one second request message to the at least one token service computer, and receives at least one first response message including at least one token and / or supplementary data associated with the at least one token from the at least one token service computer. The token gateway transmits a second response message to the token requestor computer, the second response message including the at least one token and / or the supplementary data.

[0010] Another embodiment provides a token gateway computer. The token gateway computer includes: a processor; and a non-transitory computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method, the method including: receiving a first request message from a token requester computer; determining at least one token service computer from a plurality of token service computers, each of the plurality of token service computers operating independently of one another; transmitting at least one second request message to at least one token service computer; receiving at least one first response message including at least one token and / or supplemental data associated with at least one token from at least one token service computer; and transmitting a second response message to the token requester, the second response message including at least one token and / or supplemental data.

[0011] Another embodiment includes a method comprising: receiving a first request message for a token from a token gateway, sending the first request message from a token requester computer to the token gateway; transmitting a second request message for verifying a user associated with the token requester computer to an authorization computer; generating at least one token and / or supplementary data associated with at least one token in response to receiving a successful verification message from the authorization computer; and transmitting at least one token and / or supplementary data associated with at least one token to the token gateway.

[0012] These and other embodiments are described in more detail below with reference to the figures and detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 A block diagram of a token system according to an embodiment is shown.

[0014] Figure 2 A block diagram of a token gateway computer is shown according to an embodiment.

[0015] Figure 3 A block diagram of a token requestor according to an embodiment is shown.

[0016] Figure 4 A process flow of a token provisioning system according to an embodiment is shown.

[0017] Figure 5 A block diagram of a system with a process flow illustrating online interactions is shown according to an embodiment. DETAILED DESCRIPTION

[0018] Embodiments of the present disclosure provide a token gateway computer that provides a managed service that allows token service providers and authorization systems to manage the issuance and distribution of digital token credentials. The token gateway computer provides a flexible and scalable way to securely provision, process, and manage token credentials with token requesters across several use cases. This capability can be provided and supplemented by a set of common interfaces between the token gateway computer and the different entities involved in the tokenization system, i.e., token requesters, token aggregators, and token service providers.

[0019] The token gateway computer can be used to enable a variety of digital payment use cases, such as contactless transactions, quick response (QR) code transactions, e-commerce transactions, card-on-file transactions, automated clearing house (ACH), real-time payment (RTP), and IoT device-based payment transactions. Tokenization limits the exposure of account data and reduces the risk of fraud for transactions occurring in the payment ecosystem. Users can benefit from new and more secure ways to conduct transactions, improve transaction approval levels, and reduce the risk of subsequent fraud in the event of a data breach where the payment token, rather than the user's potential personal and private information (e.g., personal account numbers), can be exposed. In addition, because the token is restricted to a specific domain, the service providing entity can experience reduced threats of attacks and data breaches because the token becomes a less attractive fraud target. In addition, due to the higher level of assurance provided by the token, authorization entities such as financial institutions can also benefit from improved authorization rates.

[0020] Before discussing specific embodiments of the invention, some description of certain terminology may be helpful.

[0021] A "resource provider" may be an entity that can provide resources such as goods, services, information, and / or access to a location (e.g., parking spots, transit stations, etc.). Examples of resource providers include merchants, government agencies, security data providers, etc. A resource provider may operate one or more resource provider computers.

[0022] An "acquirer" may 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 a single entity, an issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer."

[0023] An "authorization computer" or "authorization entity computer" may include any system involved in transaction authorization. An authorization computer may determine whether a transaction may be authorized and may generate an authorization response message including an authorization status (also referred to as an authorization decision). In some embodiments, the authorization computer may be a payment account issuer computer. In some cases, the authorization computer may store contact information for one or more users. In other embodiments, the authorization computer may authorize non-financial transactions involving users. For example, an authorization computer may make an authorization decision as to whether a user may access a resource. In some cases, the authorization computer may be a content provider server computer associated with a content providing entity that manages one or more resources accessible to a user. The authorization computer may be referred to as an authorization entity computer. The authorization computer may include an "access control server" that may be configured to authenticate a user.

[0024] An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, the message is sent to a payment processing network and / or an issuer of a payment account to request authorization for a payment transaction. The authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may also include additional data elements corresponding to the "identification information", including, for example, a service code, CW (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction data", for example, any information associated with the current transaction (e.g., transaction amount, merchant identifier, merchant location, etc.) and any other information that can be used to determine whether to identify and / or authorize a payment transaction.

[0025] An "authorization response message" may be a reply to an authorization request message. In some embodiments, the authorization response message may be an electronic message reply to an authorization request message generated by an issuing financial institution (i.e., an issuer) or a payment processing network. The authorization response message according to some embodiments may comply with ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization response message may include an authorization code, which may be a code that the account issuing bank returns (whether directly or through a payment processing network) to the merchant's access device (e.g., a point of sale terminal) in response to the authorization request message in the electronic message indicating approval of the transaction. The code may serve as evidence of authorization. As described above, in some embodiments, the payment processing network may generate and / or forward an authorization response message to the merchant.

[0026] 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 characters that may be presented or contained in any object or document that can serve as confirmation.

[0027] A "value credential" may be information associated with a value. Examples of value credential include a payment credential, a coupon identifier, information required to obtain a promotional offer, and the like.

[0028] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or a 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 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 the like. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values ​​are generally visible to users (e.g., consumers), while CVV and dCVV values ​​are generally embedded in memory or authorization request messages, which are not easily known to users (although they are known to issuers and payment processors). Payment credentials may be any information that identifies a payment account or is associated with a payment account. Payment credentials may be provided to make payments from a payment account. Payment credentials may also include username, expiration date, gift card number or code, and any other suitable information.

[0029] A "token" may be a replacement value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens, such as payment tokens, data that can be used to access a secure system or location, etc.

[0030] A "payment token" may include an identifier of a payment account that is a replacement for an account identifier, such as a primary account number (PAN) and / or an expiration date. For example, a token may include a series of alphanumeric characters that can be used as a replacement for the original account identifier. For example, the token "4900 0000 0000 0001" can be used to replace the PAN "4147 0900 00001234". In some embodiments, the token may be "format-preserving" and may have a digital format consistent with account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, the token may be used to initiate, authorize, process, or settle payment transactions in place of a PAN, or to represent an original credential in other systems that would normally provide an original credential. In some embodiments, a token value may be generated such that it may not be possible to computationally recover the original PAN or other account identifier from the token value. In addition, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0031] "Tokenization" is the process of replacing sensitive data with alternative data. For example, a real credential (e.g., a primary account number (PAN)) can be tokenized by replacing a real account identifier with a substitute number that can be associated with the real credential. For example, the tokenization process can be applied to any other information to replace the implicit information with a token. "Token exchange" or "de-tokenization" can be the process of recovering data that was replaced during tokenization. For example, a token exchange can include replacing a payment token with a primary account number (PAN) associated with the payment token. In addition, de-tokenization or token exchange can be applied to any other information to retrieve the replaced information from the token. In some embodiments, token exchange can be achieved through a transaction message (e.g., an ISO message), an application programming interface (API), or other types of web interfaces (e.g., web requests).

[0032] "Token issuer", "token service provider", "token service computer", "token service system" may include systems that serve tokens. In some embodiments, the token service computer may facilitate the request, determination (e.g., generation) and / or issuance of tokens, and maintain an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., a token library). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token binding to the PAN. The token service computer may include or communicate with a token library that stores generated tokens. The token service computer may support token processing for payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN. The token service provider may be responsible for several discrete functions, which may include token provisioning, domain control, processing, and lifecycle management of tokens.

[0033] 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, thereby uniquely identifying where the token may be used. A set of parameters (i.e., token domain restriction controls) may be established by the token service computer as part of token issuance, which may allow for enforcement of appropriate use of tokens in payment transactions. For example, a token domain restriction control may restrict the use of a token in a specific presentation mode, e.g., a contactless or e-commerce presentation mode. In some embodiments, a token domain restriction control may restrict the use of a token at a specific 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.

[0034] A "token requester" or "token requester computer" may be a registered entity that requests a token from a token service provider. Examples of token requesters include third-party wallet providers, authorized entities (e.g., financial institutions) that provide mobile or web applications, merchants, e-commerce enablers, bill payment entities, financial payment initiators, etc. In order to request a token, the token requester may connect to the token gateway computer directly or through a token aggregator in accordance with a dome embodiment. The token requester may be assigned multiple token requester IDs to support token domain restriction control for each associated use scenario. The token requester may register and comply with participation requirements.

[0035] A "token aggregator" may be an entity that is authorized to integrate with a token gateway computer to perform token-related activities on behalf of one or more token requestors. A token aggregator may perform payment token-related activities such as token provisioning, password requests, and lifecycle management of tokens. According to some embodiments, a payment gateway, a payment service provider, and a third-party provider may play the role of a token aggregator.

[0036] "Token expiration date" may indicate the date / time at which a token is valid. The token expiration date may be communicated between entities in the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g., a 4-digit numeric value). In some embodiments, the token validity period may be expressed as a duration from the time of issuance.

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

[0038] A "token response message" may be a message in response to a token request. The token response message may include an indication of whether the token request is approved or denied. The token response message may also include a payment token, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a password, and / or any other suitable information. The information included in the token response message may be encrypted (e.g., using an issuer-specific key).

[0039] A "token requester identifier" may include any characters, numbers, or other identifiers associated with an entity associated with a network token system. For example, a token requester identifier may be associated with an entity registered with the network token system. In some embodiments, a unique token requester identifier may be assigned for each domain of token requests associated with the same token requester. For example, a token requester identifier may identify a pairing of a token requester (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). The token requester identifier may include any format or type of information. For example, in one embodiment, a token requester identifier may include a numeric value such as ten or eleven digits (e.g., 4678012345).

[0040] The "password" may include a cryptic text, such as an encrypted text. The password may be formed by encrypting the input data with an encryption key, such as a symmetric encryption key. In some embodiments, the password is also reversible, so that the same symmetric key may be used to obtain the input for forming the password to perform the decryption process. In some embodiments, if the input data is encrypted using the private key of a public / private key pair, the password may also be a digital signature. The digital signature may be verified using the public key of the public / private key pair. In some embodiments, the password may include a dCVV, i.e., a dynamic card verification value.

[0041] In some embodiments, the password may be generated in any suitable manner. In some embodiments, the input of the password may include data elements including, for example, an account identifier of a primary account number, variable data elements such as a counter, time of day, etc. Such data may be included using an encryption process such as DES (Data Encryption Standard), Triple DES, or AES (Advanced Encryption Standard) using any suitable encryption key. The password may be verified by another computer, such as a remote computer, by decrypting the password and verifying the decrypted content with other data (e.g., an account number stored in a file), or by encrypting other inputs and then comparing the encryption result with the password.

[0042] A "user" may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or user devices.

[0043] A "user device" or "mobile communication device" may include any suitable electronic device that a user can transmit and operate, and that may also optionally provide remote communication capabilities with a network. Examples of remote communication capabilities include the use of a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G or similar network), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that can provide access to a network such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, wearable devices (e.g., watches), vehicles (e.g., cars and motorcycles), personal music players, handheld dedicated readers, etc. A mobile communication device may include any suitable hardware and software for performing such operations, and may also include multiple devices or components (e.g., when a device remotely accesses a network by connecting to another device, i.e., using the other device as a modem, the two devices connected together may be considered a single mobile communication device).

[0044] "Processor" may refer to any suitable one or more data computing devices. A processor may include one or more microprocessors that work together to perform the desired functions. A processor may include a CPU that includes 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 Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0045] "Memory" may be any suitable device or devices capable of storing electronic data. Suitable memory may include a non-transitory computer-readable medium storing instructions executable by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0046] Figure 1 A block diagram of a token provisioning system according to an embodiment is shown. The token provisioning system 100 comprises a token requester 101 , a token aggregator 103 , a first token gateway computer 105 , a token service provider cluster 107 , a second token gateway computer 109 and an authorization entity computer 111 .

[0047] The first token gateway computer 105 forms an interface between the token requester 101 and / or the token aggregator 103 and the token service provider cluster 107, while the second token gateway computer 109 forms an interface between the token service provider cluster 107 and the authorization entity computer 111. The cluster of token service providers includes multiple token service providers 107a, 107b, ... 107n. Each of the multiple token service providers is operably configured to generate tokens independently of each other and provide tokens to the token service computer of the token requester / aggregator. Specifically, each of the token service computers can implement a unique protocol to communicate with the token gateway computer and implement a different set of rules that govern the token generation process.

[0048] The first token gateway computer 105 is configured to receive a token request message (e.g., a first request message) from the token requester 101 and / or the token aggregator 103, and to route the token request message to one or more token service computers within the token service provider cluster 107. As will be described later, the first request message may be one of a token provision request message and a password request message. In this manner, the first token gateway computer 105 provides for the token requester 101 (or aggregator 103) to communicate with the token service provider cluster 107 without requiring the token requester 101 to implement a specific integration with each of the token service computers communicating therewith.

[0049] According to some embodiments, the token request message includes a data element associated with the token requester 101. Upon receiving the token request message, the first token gateway computer 105 may extract the token requester data element and, based on the extracted data element, route the token request to one or more token service computers (within the cluster 107). According to some embodiments, the request transmitted to the token gateway computer 105 may be routed to one or more token service computers within the cluster based on a service configuration. The service configuration associates the token requester with a domain. Specifically, the domain associates the token requester with a tokenization rule, which includes a set of restrictions that define conditions applicable to the request and use of the token. Subsequently, reference is made to Figure 2 Details regarding the routing of token request messages performed by the first token gateway computer 105 are described.

[0050] According to one embodiment, the first token gateway computer 105 can be configured to support several use cases of card-based and account-based tokens. Card-based tokens can be device-bound or non-device-bound. Device-bound tokens may be limited and bound to specific devices, and may require additional verification of the identity of the account holder by an authorized entity. Transaction communications using device-bound tokens may include NFC mobile contactless payments, in-application e-commerce payments, IoT devices such as wearables, home automation, QR code transactions presented by merchants, QR code transactions presented by consumers, etc. In contrast, non-device-bound tokens are not limited to specific devices, but to specific merchants. Examples of transactions using non-device-bound tokens may include transactions initiated by secure remote commerce and e-commerce enablers, merchants who store tokens in their payment systems instead of account holders' PANs, etc. Account-based tokens may be limited to specific devices, specific merchants, or contracting parties. Transaction instances based on account-based tokens may include ACH payments, RTP payments, etc.

[0051] After the token request message is received by one or more token service computers, i.e., the token service provider within the token service provider cluster 107, each of the one or more token service computers may initiate an identity and verification process. The identity and verification process enables verification without the actual account holder authorizing the token requester 101 and / or the token aggregator 103 to initiate the token request process.

[0052] like Figure 1As shown, each of the token service providers 107a, 107b, ... 107n can communicate with the authorization entity computer 111 through the second token gateway computer 109 to perform identity and verification procedures. For example, a specific token service provider, such as 107a, can communicate with the authorization entity computer 111 to confirm and verify information about an account and / or an account holder. The second token gateway computer 109 can be configured to receive a verification response message from the authorization entity computer 111, wherein after the second token gateway computer 109, the verification response message can be forwarded to the specific token service provider. In turn, the specific token service provider can generate the requested token and forward the generated token to the first token gateway computer 105, which in turn forwards the generated token to the token requester 101.

[0053] According to some embodiments, the authorization entity computer 111 can utilize several mechanisms to perform the above-mentioned identification and verification process. For example, in one instance, the authorization entity computer 111 can provide a phone number that can be displayed in the user interface of the token requester. The account holder, i.e., the user, can be instructed to contact the authorization entity to complete the verification process. In another example, a one-time password (OTP) mechanism can be used to verify the identity of the account holder. The OTP can be generated by the token service computer and transmitted to the authorization entity computer 111. The authorization entity computer 111 can use a persistent communication method such as an email or SMS message to send the OTP to the account holder to a mobile device operated by the user. Upon receipt, the account holder can enter the OTP in the user interface of the token requester, which in turn forwards the OTP to the token service computer. The token service computer can determine whether the received OTP matches the initially generated OTP. After determining a successful match, the token service computer can generate a token and transmit the token to the token requester.

[0054] According to some embodiments, the authorization entity computer 111 may transmit the account holder's credentials for provisioning purposes to the token requestor 101. For example, when the account holder initiates a token provisioning request from an application or web browser (installed by the authorization entity on a device operated by the account holder), the authorization entity computer 111 transmits the account holder's credentials to the one or more token service providers 107 via the second token gateway computer 109. Upon successful authentication, the one or more token service providers activate the token and transmit a message to the token requestor 101 via the first token gateway computer 105. It must be understood that although in Figure 1In the above description of the token system 100 , the first token gateway computer 105 and the second token gateway computer 109 are depicted as separate entities, but the token system 100 may include only a single token gateway computer configured to perform the functions of both the first token gateway computer 105 and the second token gateway computer 109 .

[0055] Figure 2 A block diagram is shown showing components in an exemplary token gateway computer 200. The token gateway computer 200 may include a processor 202. It may also include a computer readable medium 212 operatively coupled to the processor 202, a short range communication interface 206, a long range communication interface 204, a data storage device 208, and a routing table 210.

[0056] The computer-readable medium 212 may store code or instructions for allowing the token gateway computer 200 to operate as described herein. The instructions may be executed by the processor 202. For example, the computer-readable medium 212 may include code or instructions for: forming a local data connection between a token requestor and a plurality of token service provider computers; receiving a token request message from a token requestor and directing the received token request message to one or more token service provider computers; and automatically providing a resource (e.g., at least one token) to a token requestor after receiving the resource from one or more token service provider computers. In some embodiments, the token gateway computer 200 may receive supplemental data associated with at least one token (from one or more token service provider computers) and forward the supplemental data to the token requestor. The supplemental data may include a password that restricts an interaction channel for the corresponding token.

[0057] The computer-readable medium 212 may also include an API module 214, a token request processing module 216, a token management module 218, an identity and authentication module 220, a detokenization module 222, a routing module 224, a provisioning module 226, and a token requestor authorization module 228. The API module 214 may include software that allows the token gateway computer 200 to communicate with external computers.

[0058] The token requester processing module 216 may include software that enables the token gateway computer 200 to receive a token request message from a token requester and / or a token aggregator and extract data elements associated with the token requester included in the token request message. According to some embodiments, the data elements associated with the token requester may include a token requester identifier, authentic credentials such as a PAN, identity data, etc.

[0059] The provisioning module 226 may include software that enables the token gateway computer 200 to process data elements extracted from the token request message by the token requester processing module 216. Specifically, the provisioning module 226 may enable the token gateway computer 200 to determine one or more token service provider computers to which the token request message is to be forwarded. According to one embodiment, the provisioning module 226 activates the routing module 224, which includes software that determines one or more token service provider computers to which the token request message is to be routed. The routing module 224 accesses the routing table 210 that stores mapping information. The mapping information may include information that maps the token requester data elements to the identifiers of the token service provider computers. In this way, the routing module 224 can forward a given input token request message to one or more token service provider computers. Upon receiving the token (and supplemental data associated with the token), the token provisioning module 226 can forward the received token and supplemental data to the token requester.

[0060] The identity and authentication module 220 may include software that enables the token gateway computer 200 to perform an authentication process. Specifically, as previously described, the identity and authentication module 220 may perform an authentication process to determine that the actual account holder has authorized the token requester to initiate a token request message.

[0061] The token requester authorization module 228 may include software that enables the token gateway computer 200 to authorize token requesters and / or token aggregators. Specifically, the token requester authorization module 228 may determine whether a particular token requester and / or token aggregator is authorized by Figure 1 The token gateway computer 200 may be registered with the token system and is permitted to request tokens from the token service provider computer. It must be noted that the token requester may be associated or linked to one or more domains for which the token requester is permitted to request tokens. The token requester authorization module 228 may determine whether a specific token requester is requesting a token and / or supplemental data (e.g., a password) associated with the token in a permitted domain. The token gateway computer 200 may maintain information of the token requester and the token aggregator, such as the token requester identifier and the domain(s) for which the specific token requester is permitted to request tokens in the data storage device 208.

[0062] The de-tokenization module 222 may include software that enables the token gateway computer 200 to receive and process token authorization request messages. For example, in some embodiments, after receiving the token and / or password, the de-tokenization module 222 may de-tokenize and verify the password with the token service provider computer associated with password generation. After verification, the de-tokenization module 222 may notify the authorization entity computer whether the password is valid (i.e., whether it is the correct password associated with the interaction channel).

[0063] The token management module 218 may include software that enables the token gateway computer 200 to perform token lifecycle management functions. The token lifecycle management functions may include several operations, which may be token / account related. Such functions may be initiated by different entities (e.g., by a token service provider computer at the request of an authorized entity computer) and facilitated by the API module 214 of the token gateway computer 200. Specifically, the token gateway computer 200 allows a token requester to perform token lifecycle management through a token requester API included in the API module 214. In addition, the authorized entity computer may initiate token lifecycle management through the authorized entity computer's API included in the API module 214.

[0064] According to some embodiments, the token gateway computer 200 may support the following lifecycle management events for a token:

[0065] Activation - Since some token types may be pre-provisioned before account holder authentication is successfully completed, the activation function allows the authorized entity computer to notify the token service provider computer to activate the token after the account holder has been authenticated. The token may be active before any payment transaction occurs.

[0066] Delete - The authorized entity computer may initiate a delete function on behalf of the consumer (e.g., lost device) or for internal risk and consumer protection reasons (e.g., compromised account). This action terminates the token to account mapping in the token service provider computer. The account holder may delete the token directly through the token requester's user interface. The token requester may initiate a delete function on behalf of the account holder, and the authorized computer may receive notification that the token has been deleted.

[0067] Suspend - The authorized entity computer may initiate a suspend action to temporarily deactivate a token (eg, suspicious activity being performed by a consumer). In some embodiments, the token requestor may also initiate a suspend function based on an internal service interaction.

[0068] Resume - The authorization computer can initiate a resume function of the token (following a suspension event) so that existing account parameters can be implemented for payments and replenishments.

[0069] Update Account - When the underlying account associated with an active token may be changed by the authorized computer, it may notify the token service provider computer of the new account information. The token service provider computer may then update the token-to-account mapping maintained in the repository. This allows new accounts to be mapped to existing tokens, which eliminates the need for account holders to delete and re-provision active tokens.

[0070] Now turn to Figure 3, which illustrates a token requestor device 300 according to an embodiment. The token requestor device 300 may include device hardware 304 coupled to a system memory 302.

[0071] The device hardware 304 may include a processor 306, a short-range antenna 314, a long-range antenna 316, an input element 310, a user interface 308, and an output element 312 (the output element may be part of the user interface 308). Examples of input elements may include a microphone, a keypad, a touch screen, a sensor, etc. Examples of output elements may include a speaker, a display screen, and a tactile device. The processor 306 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of the token requester device 300. The processor 306 may execute various programs in response to program code or computer-readable code stored in the system memory 302, and may maintain multiple concurrently executing programs or processes.

[0072] The long-range antenna 316 may include one or more RF transceivers and / or connectors that may be used by the token requestor device 300 to communicate with other devices and / or to connect to an external network. The user interface 308 may include any combination of input and output elements to allow a user to interact with the token requestor device 300 and invoke functions of the token requestor device. The short-range antenna 314 may be configured to communicate with external entities over a short-range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long-range antenna 316 may be configured to communicate over the air with a remote base station and a remote cellular or data network.

[0073] The system memory 302 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage media or media combinations thereof. The system memory 302 may store computer code executable by the processor 306 for performing any of the functions described herein. For example, the system memory 302 may include a computer-readable medium including code executable by the processor 306 for transmitting a token request message to a token gateway computer.

[0074] The system memory 302 may also store a token initiation module 302A, a voice assistance module 302B, an authentication module 302C, a voucher 302D, and an operating system 302E. The token initiation module 302A may include instructions or codes for initiating and transmitting a token request message with an external device such as a token gateway computer. It may include codes that can be executed by the processor 306 for generating and transmitting other request messages, and receiving and forwarding response messages received from the token gateway computer or other devices. It may also include codes that can be executed by the processor 306 for forming a local connection or otherwise interacting with an external access device. The voice assistance module 302B may include codes that can be executed by the processor 306 to receive a voice segment and generate and analyze data corresponding to the voice segment. The authentication module 302C may include codes that can be executed by the processor 306 to authenticate the user of the operating token requester device 300. This may be performed using a user secret (e.g., a password) or user biometric information.

[0075] The system memory 302 may also store credentials and / or tokens 302D. The credentials may also include information identifying the token requestor device 300 and / or a user of the token requestor device 300. Examples of credentials may include a public key associated with the token requestor device 300 and / or a user of the token requestor device 300, a digital signature (e.g., a public key of the token requestor device 300 signed by a key of an authentication system), payment credentials, biometric data (e.g., a biometric sample or template), etc.

[0076] Figure 4 A process flow of a token provisioning system according to an embodiment is depicted. The process begins in step S451, where a token request message (e.g., a first token request message, a token provisioning request message) is transmitted by a token requester 410 to a token gateway computer 420. In step S453, the token gateway computer 420 routes the token request message to one or more token service computers included in a token service provider computer cluster 430. According to some embodiments, the token gateway computer transmits a second request message to at least one token service provider computer. As previously described with reference to Figure 2 As described, the token gateway computer 420 may access a routing table that maps token requestor data elements (included in a token request message) to token service provider computers.

[0077] Then, the process moves to step S455, where one or more token service provider computers in cluster 430 can perform an identity and verification process with authorization entity computer 440 to verify whether the actual account holder has authorized token requester 410 to initiate the token generation request. In step S457, one or more token service provider computers can receive a successful verification response message from authorization entity computer 440. Note that authorization entity computer 440 can utilize various methods (see above for reference) to verify that the actual account holder has authorized token requester 410 to initiate the token generation request. Figure 1 Described) to verify the account holder.

[0078] The process then proceeds to step S459, where one or more token service provider computers generate one or more tokens and transmit the generated tokens to the token gateway computer 420. In other words, the token gateway computer 420 receives a first response message including at least one token from at least one token service provider computer. In step S461, the token gateway computer 420 transmits the received token to the token requester 410, that is, the token gateway computer transmits a second response message to the token requester 410, wherein the second response message includes at least one token and / or additional information. In some embodiments, the token service provider computer may generate additional / supplementary data associated with each of the one or more tokens. For example, the token service provider computer may generate supplementary data including a password that restricts the interactive channel of the corresponding token. In this case, the supplementary data may be generated by the token service provider computer (in step S459) and transmitted to the token requester 410 in step S461 together with the token.

[0079] Figure 5 FIG. 2 shows a block diagram of a system with a process flow illustrating online interaction according to an embodiment. Figure 5 The process flow depicted may correspond to an e-commerce type transaction or a card-on-file type transaction. However, it should be noted that Figure 5 The process in may also correspond to a device-present transaction, where the token requestor is a user device operated by a user and the resource provider computer is an access device (e.g., a POS terminal or door terminal) at a location of a resource provider (e.g., a merchant or transit agency).

[0080] The first step in conducting an online transaction may include requesting a token cryptogram from a token gateway computer to conduct a transaction using a token. In addition, the token gateway computer may be accessed to retrieve a payment bundle for processing the transaction. According to some embodiments, the payment bundle may include a payment cryptogram generated by one or more token service provider computers for a particular transaction.

[0081] like Figure 5As shown, in step S531, the token requester 501 transmits a request for a token password (e.g., a first request message, i.e., a password request message) to the token gateway computer 503. The request may include a token to be associated with the token password. In step S532, the token gateway computer 503 routes the request to one or more token service provider computers (included in the token service provider computer cluster 507) requesting the exchange of specific passwords. In other words, the token gateway computer 503 transmits the second request message to at least one token service provider computer. In some embodiments, the token gateway computer 503 determines at least one token service provider computer (to whom the request is to be forwarded) by accessing a routing table, which maps the data elements of the token requester included in the request (e.g., the token requester ID) to one or more token service provider computers.

[0082] In some embodiments, the token requester 501 can transmit a single request to the token gateway computer 508, and the request can include multiple tokens. The token gateway computer 508 can then transmit multiple password request messages to multiple token service provider computers 507 in parallel or sequentially. This can be beneficial in the event that one or more token service provider computers 507 are slow or non-functional. In some embodiments, the token gateway computer 508 can include a timer that can send token password request messages to one token service provider computer at a time. If no response is made before the timer expires, the token gateway computer 503 can communicate with the next token service provider computer, and so on.

[0083] After one or more token service provider computers 507 receive the request for the interaction-specific password, one or more token service provider computers 507 initiate the identity and verification process. Specifically, one or more token service provider computers transmit the verification request message to the token gateway computer 509 (step S533). The token gateway computer 509 communicates with the authorization entity computer 511 (step S534) to verify that the actual account holder has authorized the token requester 501 to initiate the token request. As previously described, the authorization entity computer 511 can use multiple mechanisms (e.g., one-time password, email, text message, etc.) to verify the account holder. In step S535, the authorization entity computer 511 transmits a verification response message indicating whether the account holder has been successfully verified to the token gateway computer 509. In step S536, the token gateway computer 509 forwards the verification response message to the one or more token service provider computers 507.

[0084] In step S537, after receiving the verification response message indicating that the account holder has been successfully verified, the one or more token service provider computers 507 generate an interactive specific password and provide the token together with the password to the token gateway computer 503. Specifically, the token gateway computer 503 receives at least one first response message, the first response message includes at least one token and / or supplementary data associated with the token. In addition, in step S538, the token gateway computer 503 forwards the token together with the password to the token requester 501, that is, the token gateway computer 503 transmits a second response message to the token requester 410, wherein the second response message includes at least one token and / or the password.

[0085] Although steps S531 to S538 describe the retrieval of a token password, it should be understood that these steps are not limited thereto. In other embodiments, after the token requester computer provides real credentials such as a primary account number, a token or both a token and a password can be retrieved from a token service provider computer.

[0086] After obtaining the interaction-specific password from the token gateway computer 503, the token requester 501 may transmit the token (e.g., token payload) and the password to the resource provider computer 513, e.g., the merchant computer, at any suitable time thereafter (step S539). Thereafter, in step S540, the resource provider computer 513 generates an authorization request message to verify the password. For example, the resource provider computer 513 generates an authorization request message including the token, and transmits the generated authorization request message to the acquirer computer 515 (e.g., the issuer computer).

[0087] The acquirer computer 515 provides the authorization request message to the network computer 517 (step S541). The network computer 517 may be a payment processing network computer. The payment processing network computer 517 may include data processing subsystems and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. Exemplary payment processing networks may include VisaNet TM For example, VisaNet TM Payment processing networks such as are able to process credit card transactions, debit card transactions, and other types of commercial transactions.

[0088] In some embodiments, the network computer 517 may forward the authorization request message to the authorization entity computer 511 in step S541. To verify the password, the authorization entity computer 511 forwards the authorization request to the token gateway computer 509 (step S542). In step S543, upon receiving the authorization request message, the token gateway computer 509 may detokenize and verify the password with one or more token service provider computers 507 associated with password generation.

[0089] After verification, the token gateway computer 509 may receive a response message indicating the status of the password verification, i.e., whether the password is valid, from the one or more token service provider computers 507 (step S544). In some embodiments, the one or more token service providers may be configured to verify the password based on a mapping table that maps the password to transaction-related data, such as a transaction ID, a user ID, etc. In step S545, the token gateway computer 509 forwards a message indicating the status of the password verification to the authorization entity computer 511.

[0090] The authorization entity computer 511 may determine whether to authorize a transaction, i.e., an interaction between a user and a resource provider, based on criteria associated with the user's account. For example, the authorization entity computer may determine that the user has sufficient funds in the account to complete the transaction. The authorization entity computer 511 generates an authorization response message, which includes at least, for example, an indication of whether the interaction is authorized. In step S546, the authorization response message is transmitted by the authorization entity computer 511 to the resource provider computer 513 via the network computer 517 so that the transaction can be completed.

[0091] It must be understood that although in the above description of online interactions such as e-commerce interactions between users and resource providers, the first token gateway computer 503 and the second token gateway computer 509 are depicted as separate entities, the online transaction system may include only a single token gateway computer configured to perform the functions of both the first token gateway computer 503 and the second token gateway computer 509. In addition, according to some embodiments, the network computer 517, i.e., the payment processing network computer, may be directly connected to the token service provider computer cluster 507. In this scenario, the network computer 517 may bypass the authorization entity computer 511 and the token gateway computer 509 for the purpose of verifying the password. In addition, it must be noted that although Figure 5 The above description relates to online interactions for e-commerce type transactions or card-on-file type transactions, but similar mechanisms for verifying a password apply to contactless interactive transactions. For example, a contactless transaction using a token supplied to an NFC-enabled device such as a phone or IoT device may verify a password as described above (using at least steps S540 to S546) to complete the contactless transaction.

[0092] In some of the above embodiments, the data elements associated with the token requester included in the token request message correspond to credentials such as a PAN. Thereafter, as described above, the token and / or supplementary data associated with the token may be obtained to conduct a transaction. It must be understood that the above tokenization mechanism may also be applied to access systems, such as building access systems. In this context, the data elements included in the token request may correspond to the user's identity data. Thus, the user of the mobile device may implement the above tokenization mechanism using his / her identity data embedded in the token request. Upon communication and / or authorization from the token service provider computer, the user may be authorized to access a building, a restricted area, etc.

[0093] Embodiments of the present invention have several advantages. For example, see Figure 1 , a single token gateway computer 105 can communicate with many token service providers 107a to 107n. Any routing functions or updates can be programmed into the token gateway computer 105, and each token service provider does not need to provide a separate connection to each token requester or token aggregator. In other words, each token requester only needs to be concerned with one connection to the token gateway computer, rather than managing multiple connections to the token service provider. In addition, each token service provider only needs to be concerned with one connection to the token gateway computer, rather than connecting to each of the token requesters.

[0094] Furthermore, conventional systems do not allow a token requester to send a single token or password request message and then communicate with many different token service providers in parallel. This allows the token requester to receive the desired password or token as quickly as possible or according to any preferences the token requester may desire (e.g., if one account is preferred over another). It further allows the token requester to receive the desired token or token password even if one of the token service providers does not work.

[0095] It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and the teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the present invention using hardware and a combination of hardware and software.

[0096] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language, such as Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code can 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 a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

[0097] Although certain exemplary embodiments have been described in detail and shown in the drawings, it is to be understood that such embodiments are merely illustrative of the invention and not restrictive, and that the invention is not limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those skilled in the art.

[0098] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A token service provider computer, comprising: processor; as well as A non-transitory computer readable medium coupled to the processor and comprising code executable by the processor for implementing a method comprising the steps of: receiving a first request message for a token from a first token gateway, the first request message being sent from a token requestor computer to the first token gateway; transmitting, via a second token gateway, a second request message to an authorization computer to authenticate a user associated with the token requestor computer; generating at least one token in response to receiving a successful authentication message from the authorization computer via the second token gateway; as well as The at least one token is sent to the first token gateway in a first response message, wherein the first token gateway is different from the second token gateway.

2. The token service provider computer of claim 1 , wherein the processor is further configured to: generating supplemental data associated with the at least one token; and The supplemental data associated with the at least one token is transmitted to the first token gateway.

3. The token service provider computer according to claim 2, wherein the supplementary data includes a password restricting an interaction channel for the corresponding token.

4. The token service provider computer of claim 1 , wherein the processor is further configured to: A third request message for verifying the earlier generated password is received from the authorization computer and through the second token gateway.

5. The token service provider computer of claim 1, wherein the first request message is a provisioning request message.

6. The token service provider computer of claim 1, wherein the first request message is a password request message.

7. The token service provider computer of claim 1, wherein the first token gateway selects the token service provider computer from a plurality of token service provider computers based on service configuration information of the token requestor computer.

8. A token service provider computer according to claim 1, wherein the first token gateway selects the token service provider computer from a plurality of token service provider computers by accessing a routing table that maps the token requester data element in the first request message to the plurality of token service provider computers.

9. The token service provider computer of claim 8, wherein the token requestor data element comprises a token requestor identifier.

10. The token service provider computer of claim 8, wherein the token requestor data element comprises authentic credentials.

11. The token service provider computer of claim 1, wherein the token service provider computer is directly coupled to the first token gateway at a first end and directly coupled to the second token gateway at a second end.

12. A token service provider computer according to claim 1, wherein the first token gateway transmits a second response message to the token requester computer, the second response message including the token and supplementary data, the supplementary data including a password restricting an interaction channel used for the corresponding token.

13. A method comprising: receiving, by a second token gateway, a verification request message from a token service provider computer, the verification request message requesting verification of a user associated with a token requestor computer, wherein the token requestor computer issues a token request to the token service provider computer, the token request being forwarded to the token service provider computer via a first token gateway different from the second token gateway; The second token gateway sends the verification request message to an authorization computer; as well as In response to receiving a successful verification response message from the authorization computer, the second token gateway forwards the successful verification response message to the token service provider computer, wherein the token service provider computer generates a token to be provided to the user associated with the token requestor computer in response to receiving the successful verification response message.

14. The method according to claim 13, further comprising: receiving, from said authorization computer, an authorization request message for verifying an earlier generated password; as well as The authorization request message is forwarded to the token service provider computer, wherein the token service provider computer is configured to detokenize and verify the earlier generated password.

15. The method according to claim 14, further comprising: receiving an authorization response message from the token service provider computer indicating a verification status of the earlier generated password; as well as The authorization response message is forwarded to the authorization computer.

16. The method of claim 13, wherein the second token gateway is directly coupled to the token service provider computer at a first end and directly coupled to the authorization computer at a second end.

17. The method of claim 13, wherein the token service provider computer is directly coupled to the first token gateway at a first end and directly coupled to the second token gateway at a second end.

18. The method of claim 13, wherein the token service provider computer generates supplemental data associated with the token, the token and the supplemental data being provided to the token requestor computer.

19. The method according to claim 18, wherein the supplementary data includes a password restricting an interaction channel for the corresponding token.

20. The method of claim 13, wherein the second token gateway is communicatively coupled to a plurality of token service provider computers, the token service provider computers being included in the plurality of token service provider computers.

Images