Cloud token provisioning with multiple tokens

Abstract

A method is disclosed. The method includes receiving a token request message from a token service computer, the token request message originating from a token requesting computer. The method further includes determining two or more access tokens based on a single credential by the token service computer, and then transmitting the two or more access tokens to the token requesting computer in a token response message.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2019 / 061385, international application date November 14, 2019, Chinese national phase application number 201980074915.8, entitled "Cloud Token Pre-configuration of Multiple Tokens".

[0002] Cross-referencing related applications

[0003] This application is a PCT application claiming priority to U.S. Provisional Application No. 62 / 767,111, filed November 14, 2018, which is incorporated herein by reference in its entirety. Background Technology

[0004] Users can use tokens instead of credentials to access services or products. During a transaction, the token on the mobile device can be exchanged for real credentials that can be used for the transaction authorization process (such as a master account (PAN) or other payment information). Using tokens ensures greater security for sensitive information by clearing all real credentials from the mobile device.

[0005] In some processes, the user initially receives a token by sending a provisioning request from the mobile device. The token is bound to the mobile device and can be stored within a secure element in the mobile device's hardware or in software, where the security of the token can be ensured through encryption.

[0006] However, there are limitations to binding a token to a single mobile device. For example, if a user wants to switch from their current mobile device to a new one, they must repeat the provisioning process for the new mobile device by providing a PAN or some other credential to obtain a new token. The token on the user's previous mobile device is then lost, and the new mobile device cannot transmit or use the token.

[0007] Furthermore, this method cannot allow more than one device to share a token. Any spare mobile device owned by the user requires a separate provisioning request, where a different token is generated for each individual mobile device. Since it can be assumed that the credentials provided by the user (e.g., PAN) remain the same, these subsequent provisioning requests are generally redundant and a waste of computing resources.

[0008] Embodiments of the present invention relate to addressing these and other problems individually and collectively. Summary of the Invention

[0009] Embodiments of the present invention include pre-provisioning multiple access tokens in response to a single token request message. In one embodiment, a method includes receiving access credentials from a user-operated mobile device by a token requesting computer and transmitting the access credentials to a token service computer. In response to receiving the access credentials, the method further includes transmitting an authorization request message from the token service computer to an authorization entity computer to verify credential eligibility. After receiving an affirmative authorization response message from the authorization entity computer, the method further includes obtaining at least two or more tokens by the token service computer, wherein at least one token can be associated with the mobile device and at least one token can be associated with a cloud server computer. The generated tokens are transmitted to the token requesting computer within a token response message.

[0010] Another embodiment of the present invention relates to a method comprising: receiving a token request message by a token service computer, the token request message originating from a token requesting computer; determining two or more access tokens by the token service computer based on a single credential; and transmitting the two or more access tokens to the token requesting computer in a token response message by the token service computer.

[0011] Another embodiment of the present invention relates to a token service computer, comprising: a processor; and a non-transient computer-readable medium including code executable by the processor to implement a method comprising: receiving a token request message originating from a token requesting computer; determining two or more access tokens based on a single credential; and transmitting the two or more access tokens to the token requesting computer in a token response message.

[0012] Another embodiment of the present invention relates to a method comprising: receiving a single credential from a communication device by a token requesting computer; transmitting a token request message including the single credential from the token requesting computer to a token service computer by the token requesting computer; receiving a token response message from the token service computer by the token requesting computer, the token response message including two or more access tokens, the two or more access tokens including a first access token and a second access token; transmitting the first access token from the token requesting computer to the communication device; and transmitting the second access token from the token requesting computer to a cloud server computer.

[0013] Another embodiment of the present invention relates to a token requester computer, comprising: a processor; and a non-transient computer-readable medium including code executable by the processor for implementing methods including: receiving a single credential from a communication device; transmitting the single credential to a token service computer; receiving two or more access tokens from the token service computer, the two or more access tokens including a first access token and a second access token; transmitting the first access token to the communication device; and transmitting the second access token to a cloud server computer.

[0014] For more detailed information on embodiments of the present invention, please refer to the detailed description and accompanying drawings. Attached Figure Description

[0015] Figure 1 A system and method for pre-configuring multiple tokens are shown.

[0016] Figure 2 A swimlane diagram illustrating a method for retrieving and using a token from a binding device according to an embodiment of the present invention is shown.

[0017] Figure 3 A swimlane diagram illustrating the retrieval and use of cloud tokens is shown according to some embodiments of the present invention.

[0018] Figure 4 A system for obtaining access to a secure location using a cloud token is illustrated according to some embodiments of the present invention.

[0019] Figure 5 A block diagram of a mobile communication device according to some embodiments of the present invention is shown.

[0020] Figure 6 A block diagram of a token service computer according to some embodiments of the present invention is shown.

[0021] Figure 7 A block diagram of a token requester computer according to some embodiments of the present invention is shown. Detailed Implementation

[0022] Before discussing the embodiments of the present invention, some terms may be described in more detail.

[0023] A “user device” can be any suitable device that can be used by a user. A user device can take any suitable form. Some examples of user devices include cellular phones, PDAs, personal computers (PCs), tablet computers, etc. In some embodiments where the user device is a mobile device, the mobile device may include a display, memory, a processor, a computer-readable medium, and any other suitable components.

[0024] A "mobile device" can include any suitable electronic device that a user can transmit and operate, and that also provides the ability to communicate remotely with a network. Mobile communication devices can communicate using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that provides access to networks such as the Internet or private networks. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptops, wearable devices (e.g., watches), vehicles (e.g., cars and motorcycles), personal music players, handheld dedicated readers, etc. Mobile devices can include any suitable hardware and software for performing such functions, and can also include multiple devices or components (e.g., two devices used together can be considered a single mobile device when the device remotely accesses a network by being attached to another device—that is, using the other device as a modem).

[0025] A "resource provider" can be any suitable entity that provides resources (e.g., goods, services, access to secure data, access to location, etc.) during a transaction. For example, a resource provider could be a merchant, venue operator, building owner, government entity, etc. A "merchant" can typically be an entity that participates in the transaction and can sell goods or services or provide access to goods or services.

[0026] An "application" can be a computer program used for a specific purpose.

[0027] "Authentication data" can include any data used to verify something. Authentication data can include data used to authenticate a user or mobile device. Authentication data can be obtained from a user or a device operated by the user. Examples of authentication data obtained from a user can include a PIN (Personal Identification Number), biometric data, passwords, etc. Examples of authentication data obtained from a device can include device serial numbers, hardware security element identifiers, device fingerprints, phone numbers, IMEI numbers, etc.

[0028] "Access data" can include any suitable data that can be used to access resources or create data that allows access to resources. In some embodiments, access data can be account information for a payment account. Account information can include a primary account (PAN), payment token, expiration date, and verification value (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data can be data that can be used to activate account data. For example, in some cases, account information can be stored on a mobile device but may not be activated until the mobile device receives specific information. In other embodiments, access data can include data that can be used to access a location. Such access data can be event ticket information, data for accessing buildings, transportation ticket information, etc. In other embodiments, access data can include data for obtaining access to sensitive data. Instances of access data can include code or other data required by a server computer to grant access to sensitive data.

[0029] An "access request" can include a request to access a resource. The resource can be a physical resource (e.g., a product), a digital resource (e.g., an electronic document, electronic data, etc.), or a service. In some cases, an access request can be submitted by transmitting an access request message that includes access request data. Typically, a device associated with the requesting party can transmit the access request message to a device associated with the resource provider.

[0030] "Access request data" can include any information about or related to an access request. Access request data can include access data. Access request data can include information that can be used to process and / or verify the access request. For example, access request data can include details associated with an entity involved in processing the access request (e.g., a resource provider computer, a processor server computer, an authorizing computer, etc.), such as entity identifiers (e.g., name, etc.), location information associated with the entity, and information indicating the entity type (e.g., category code). Exemplary access request data can include information indicating the amount of access request, the location of the access request, the resources received (e.g., products, documents, etc.), information about the received resources (e.g., size, quantity, type, etc.), resource provider entity data (e.g., resource provider data, document owner data, etc.), user data, the date and time of the access request, information about the method used to make the access request (e.g., contactless, contactless, etc.), and other relevant information. Access request data can also be referred to as access request information, transaction data, transaction information, etc.

[0031] An "access device" can be any suitable device for providing access to an external computer system. Access devices can take any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, websites, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data to or associate with a mobile device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a mobile device.

[0032] A “digital wallet” or “e-wallet” can include electronic devices or services that allow individuals to conduct e-commerce transactions. A digital wallet can store user profile information, credentials, bank account information, one or more digital wallet identifiers, and can be used for various transactions, such as, but not limited to, e-commerce transactions, social network transactions, money transfer / personal payment transactions, mobile commerce transactions, proximity payment transactions, and gaming transactions. Digital wallets can be designed to simplify the purchasing and payment process. A digital wallet can allow users to load one or more payment cards onto it to make payments without entering an account number or presenting a physical card.

[0033] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used for authentication. Examples of credentials include value certificates, identification cards, authentication documents, access cards, passwords, and other login information. Other examples of credentials include master accounts (PANs) and personally identifiable information (PIIs) such as names, addresses, and telephone numbers.

[0034] An "authorizing entity" can be an entity that typically uses an authorized computer to authorize a request. Authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. An "issuer" can typically include a commercial entity that maintains a user's account (e.g., a bank). Issuers may also issue payment credentials to users that are stored on user devices such as cellular phones, smart cards, tablets, or laptops.

[0035] A "service provider" can be an entity that can typically provide resources such as goods, services, information, and / or access through a service provider's computer. Examples of service providers include merchants, digital wallets, payment processors, etc.

[0036] "User" may include an individual or computing device. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may be a cardholder, account holder, or consumer.

[0037] A "token" can be a substitute for a credential. An "access token" can be a token used to access something. A token can be a string of numbers, letters, or any other suitable characters. Instances of tokens include access tokens (e.g., payment tokens), personal identification tokens, and so on.

[0038] A "payment token" may include a payment account identifier that substitutes for an account identifier such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "4900 00000000 0001" may be used in place of the PAN "4147 0900 00001234". In some embodiments, the token may be "formatted" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token may be used in place of the PAN to initiate, authorize, process, or resolve payment transactions, or to represent the original credentials in other systems where the original credentials would typically be provided. In some embodiments, a token value may be generated such that the original PAN or other account identifier may not be computably recoverable from the token value. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to identify the entity issuing the token. In some embodiments, the length of the access token in the embodiments may be 16, 18, or 19 characters.

[0039] A "key" can be a piece of information used in a cryptographic algorithm to transform data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0040] An "authorization request message" can be an electronic message requesting authorization to perform something. In some embodiments, an authorization request message is sent to a payment processing network and / or the issuer of a payment card to request transaction authorization. Authorization request messages according to some embodiments may conform to ISO 8583, a standard for systems that exchange information related to electronic transactions made by a user using a payment device or payment account. An authorization request message may include an issuer account identifier that can be associated with a payment device or payment account. An authorization request message may also include additional data elements corresponding to "identification information," including, by way of example only, a service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. An 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 can be used to determine whether to identify and / or authorize the transaction.

[0041] An "authorization response message" can be an electronic message reply to an authorization request message. In some embodiments, the authorization response message is generated by the issuing financial institution or a payment processing network. As an example only, the authorization response message may include one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - further information is pending, and the merchant must call the toll-free authorization number. The authorization response message may also include an authorization code, which may be a code returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the payment processing network), indicating that the transaction has been approved. This code can be used as evidence of authorization. As described above, in some embodiments, the payment processing network may generate or forward authorization response messages to the merchant.

[0042] A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one instance, a server computer could be a database server coupled to a web server.

[0043] "Processor" can include any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to perform the desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. The CPU can be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

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

[0045] A "token service computer" can be any suitable device that processes, monitors, or manages token generation or token processing. A token service computer can communicate with a token requester computer, a processing network computer, an authorizing entity computer, etc.

[0046] A "token request message" can be an electronic message requesting a token. In some embodiments, a token request message may include a token requester identifier and an address to the token service computer.

[0047] A token response message can be an electronic message that replies to a token request message. A token response message may include at least one or more tokens, the address of the token requesting device, etc.

[0048] A "cloud server computer" can be a remotely located server computer, including information or data that a user can access from at least one or more devices. A cloud server computer can be a standalone device or included within a larger device, and can be connected to a user device via a network interface (e.g., for connecting to a standalone device via the Internet) or any suitable communication interface.

[0049] A “requesting party” can be an application, device, process, or system configured to perform actions associated with a token. For example, a requesting party may request registration with a network token system, request token generation, token activation, token deactivation, token exchange, other token usage period management processes, and / or any other token-related processes. The requesting party may interface with the network token system via any suitable communication network and / or protocol (e.g., using HTTPS, Simple Object Access Protocol (SOAP), and / or Extensible Markup Language (XML) interfaces). Some non-limiting examples of requesting parties may include third-party wallet providers, issuers, acquirers, merchants, and / or payment processing networks. A requesting party may be referred to as a token requester when requesting the generation of a new token from the network token system or requesting new use of an existing token. In some embodiments, a token requester may request tokens for multiple domains and / or channels. Token requesters may include, for example, card archiving merchants, acquirers operating on behalf of merchants, acquirer processors and payment gateways, payment supporters (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, and / or card issuers.

[0050] A “token requester identifier” (or a token requester computer identifier) ​​may include any character, number, or other identifier associated with an entity linked to the network token system. For example, a token requester identifier may be associated with an entity registered in the network token system. In some embodiments, a unique token requester identifier may be assigned to each domain of a token request 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, mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). A token requester identifier may include information of any format or type. For example, in one embodiment, a token requester identifier may include a value such as ten or eleven digits (e.g., 4678012345).

[0051] In some embodiments, a token requester identifier can uniquely identify a pair of token requesters and token domains. Therefore, in some embodiments, if a token requester can request tokens for multiple domains, the token requester can have multiple token requester identifiers, one for each domain.

[0052] For example, in some embodiments, the token requester identifier may include an 11-bit numeric value assigned by the network token system, and the token requester identifier may be unique within the token registry for each entity (and each domain). For example, the token requester identifier may include a code (e.g., the first 3 bits) for a token service provider such as a network token system, and the remaining bits (e.g., the last 8 bits) may be assigned by the token service provider for each requesting entity (e.g., a mobile wallet provider) and for each token domain (e.g., contactless, e-commerce, etc.).

[0053] Currently, mobile wallets on communication devices such as mobile phones can provide a device-linked token to a merchant application on the device. This device-linked token may be suitable for both one-time and repeated use. The merchant application can then communicate with an application server associated with it to initiate payment transactions using the token. If a user deletes the device-linked token from their mobile wallet, every repeated transaction submitted by the merchant application will fail. Embodiments of the present invention address this problem and others.

[0054] Embodiments of the present invention can provide two or more access tokens to a token requester (e.g., a service provider computer such as a mobile wallet computer). These two or more access tokens may include, but are not limited to, tokens for device binding and cloud tokens. A "cloud token" can be a token stored on a remote server computer and used for remote access or remote transactions. In an embodiment, the token requester computer, acting as a mobile wallet server computer associated with a mobile wallet application on a communication device, can request multiple tokens from a token service computer. These multiple tokens may include at least cloud tokens and tokens for device binding. The token service computer can provide cloud tokens to a cloud server computer operated by a merchant via the token requester computer, enabling the use of cloud tokens to conduct repeated transactions on behalf of the user.

[0055] Cloud tokens can be based on the same PAN as device tokens stored on communication devices, but are unrelated to device tokens. A “device token” or “device-bound token” can be a token used by the communication device, which stores the token in proximity or contact transactions. Therefore, while cloud tokens are used for remote transactions—such as e-commerce transactions—device tokens are used for transactions at physical points of sale. In the event of (intentional or unintentional) deletion of a device token, the cloud token is unaffected and will continue to process duplicate merchant transactions. This embodiment avoids the need for the token requesting computer to make multiple calls to the token service computer to obtain multiple tokens from the token service computer.

[0056] Figure 1A system 100 according to an embodiment of the present invention is illustrated. The system includes: a mobile communication device 110 including a mobile wallet application; a token requester computer 120 operable by a token requester, such as a mobile wallet application server computer; a token service computer 130; an authorization entity computer 140, such as an issuer computer operable by an issuer; and a cloud server computer 150. The cloud server computer 150 may be operated by a resource provider, such as a merchant or a mobile wallet provider. Figure 1 Each of the components shown can communicate operationally with each other.

[0057] Figure 1 Components within the system can operationally communicate with each other through any suitable communication channel or network. Suitable communication networks can be any one and / or a combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an Operational Mission as an Internet node (OMNI), a secure custom connection, a wide area network (WAN), or a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.). Messages between computers, networks, and devices can 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), etc.

[0058] Some implementations allow multiple tokens to be pre-provisioned after a single token request message is received. (Return to Reference) Figure 1 This can describe the token pre-allocation method.

[0059] refer to Figure 1 In step S102, the mobile communication device 110 containing the mobile wallet application can provide access credentials (e.g., PAN, etc.) to the token requester computer 120, which may be a digital wallet server computer (e.g., Apple Pay, Samsung Pay, Android Pay, etc.).

[0060] In step S104, the token requesting computer 120 may generate a token request message including access credentials and transmit the token request message to the token serving computer 130. The token request message may also include at least the address of the token serving computer 130 and an identifier for the token requesting computer 120. The token serving computer 130 may then perform an eligibility check on the access credentials. For example, the token serving computer may determine whether the access credentials are authentic before continuing the token pre-provisioning process.

[0061] Qualification checks can be performed in any suitable manner. For example, the token service computer 130 can check a blacklist to see if access credentials exist and / or use a fraud engine to perform fraud checks on the access credentials. In other embodiments, the token service computer 130 can transmit a qualification request message to the authorization entity computer 140. The authorization entity computer 140 can perform a qualification check and then provide a qualification response message to the token service computer 130.

[0062] In step S106, after the token service computer 130 completes the eligibility check and determines that the access credentials are valid, the token service computer 130 may optionally transmit a provisioning request message to the authorizing entity computer 140. The provisioning request message may include the access credentials and the address of the authorizing entity computer 140. The token service computer 130 may contain a routing table that maps different access credentials to specific authorizing entity computers. The authorizing entity computer 140 can then determine whether the access credentials are genuine or otherwise approved to have one or more tokens associated with them.

[0063] In step S108, the authorizing entity computer 140 may transmit a provisioning response message to the token service computer 130. The provisioning response message may include an indication of whether the authorizing entity computer 140 has approved the provisioning.

[0064] In response to receiving a provisioned response message, the token service computer 130 may determine (e.g., generate or retrieve) two or more access tokens, which may be associated with access credentials. In some embodiments, access tokens may be pre-generated, while in other embodiments, access tokens may be derived from provided credentials.

[0065] Two or more access tokens can have any suitable characteristics and can ultimately be used by a single user associated with the access token in different situations. For example, in some embodiments, one access token may be a resource provider (e.g., a merchant) specific token, while another access token may be a device-specific token associated with a particular device, such as a specific mobile phone operated by the user.

[0066] In some embodiments, the two or more access tokens are encrypted with a first symmetric cryptographic key before being transmitted to the token requesting computer 120. The token requesting computer 120 can then decrypt the two or more access tokens using a second symmetric cryptographic key.

[0067] In step S110, a token response message, including two or more access tokens and optionally the original authentic credentials, may be transmitted to the token requester computer 120. The token response message may also include information about the token type, wherein the token type determines whether a single token will be stored on the mobile communication device 110 or on the cloud server computer 150. The information about the token type may include a token type indicator, which may indicate, for example, that the token is a cloud token used for cloud-based transactions such as e-commerce transactions, or that the token is a device-bound token used in physical point-of-sale transactions. The token response message may also include a password. The password may be attached to the token in the authorization request message. The password may be verified by the processing computer, and verification of the password may indicate that the token is being used in the appropriate transaction channel.

[0068] In step S112, after receiving the token response message, the token requesting computer 120 can extract an access token from the token response message, wherein the extracted access token is determined by the token type, and the token requesting computer can transmit the extracted access token to the mobile communication device 110 for storage in the memory structure of the mobile communication device 110 (e.g., stored in a secure element). In some embodiments, before transmitting the first access token to the mobile communication device 110, the token requesting computer 120 can encrypt the first access token using a public key in an RSA encryption scheme. When the first access token is transmitted to the mobile communication device 110, the first access token can be in encrypted form. The mobile communication device 110 stores a private key corresponding to the public key.

[0069] In S114, the token requesting computer 120 can extract another access token from the token response message, wherein the extracted access token is determined by the token type, and the token requesting computer can provide the extracted access token to the cloud server computer 150. This access token can be stored in the cloud server computer 150 for later use by the user. For example, the access token stored in the cloud server computer 150 can be a merchant-specific token used for recurring payment transactions, such as recurring subscription payments for newspapers.

[0070] The token requesting computer 120 may include a routing table containing entries for linked device identifiers and / or device addresses (e.g., cloud storage locations on a cloud server computer), which will be pre-configured with an access token, credentials, and a token type indicator. The routing table can be used with received token response messages. The token response message may include credentials or other identifiers that can be used to identify the device to be provisioned. The token type indicator can also be used to identify a specific type of device to be provisioned (e.g., a mobile communication device or a cloud server).

[0071] In embodiments of the present invention, information can be filled into the routing table during the user registration stage, and / or the information can be filled into the routing table during system pre-configuration and transaction processing.

[0072] Note that in embodiments of the invention, steps S112 and S114 can be performed in any order, or sequentially. Furthermore, although this example describes a token requesting computer 120 receiving two access tokens and assigning them to two separate machines, in other embodiments, the token requesting computer 120 may receive three or more tokens in a single token response message and may assign these three or more tokens to any number of machines. For example, three or more tokens may be assigned to three or more machines, or two tokens may be assigned to one machine and one token to another machine.

[0073] In step S116, the mobile communication device 110 may use a mobile wallet or other application (e.g., a resource provider or merchant-specific application) to access the token stored in the cloud server computer 150 for transactions, as described below.

[0074] The implementation offers several advantages. In this implementation, two or more access tokens can be obtained in response to a single token request message. This reduces the time and frequency of data transmissions associated with the reception of access tokens, compared to a conventional provisioning system that receives only one access token from each response message at a time.

[0075] For reference Figure 2 This illustrates a system for retrieving and using a token of a bound device to conduct in-app payment transactions. In this system, user 200 can operate mobile communication device 220 using a token 226 of the bound device stored in memory element 225.

[0076] In step S202, the user can initiate a payment within a mobile wallet or merchant application on the mobile communication device 220. In some embodiments, the mobile wallet or merchant application may be Apple Pay, Samsung Pay, or Android Pay, and / or any application that requires an access token to complete a transaction and / or obtain some services or products.

[0077] In step S203, the mobile communication device 220 can retrieve the appropriate token 226 from the secure element and transmit the token 226 to the access device 240. The access device 240 can be a point-of-sale (POS) device, an automated teller machine (ATM), and / or any suitable device for communicating with the mobile communication device 220.

[0078] In step S204, access device 240 may provide an authentication request to user 200. The authentication request may require user 200 to provide a PIN or some other user identification data (e.g., password, biometric fingerprint and / or voice sample, etc.).

[0079] In step S206, access device 240 may receive an authentication response with any requested authentication data. Access device 240 may verify the authentication data and generate a positive authentication indicator. If authentication fails, access device 240 and / or mobile communication device 220 may display an error message and / or abort the transaction, preventing subsequent steps from being executed.

[0080] In step S208, access device 240 may generate an authorization request message, which may then optionally be transmitted to authorization entity 260 via a transmission computer operated by, for example, an acquiring entity, and the processing network computer operated by, for example, a payment processing organization such as Visa™. The authorization request may include a token 226 bound to the device and / or one or more transaction details (e.g., timestamp, user ID, requested amount, etc.). Authorization entity 260 may determine whether the requested amount is at least less than or equal to the user's available funds by communicating with the issuer. Authorization entity computer 260 or processing network computer operationally communicating with authorization entity computer 260 (…) Figure 2 (Not shown in the image) The device token 226 can also be exchanged for a real credential (e.g., PAN) before the authorizing entity computer 260 determines whether the transaction has been authorized.

[0081] In step S210, an authorization response is transmitted back to the access device 240. The transaction can be completed upon receiving a positive authorization response. In the event of a negative authorization response, the access device 240 and / or the mobile communication device 220 may display an error message and / or abort the transaction.

[0082] At the end of the day, clearing and settlement processes can be performed between the authorized entity computer 260, the processing network computer, and the transmission computer associated with the resource provider (e.g., merchant) of the access device 240.

[0083] In some embodiments, a cloud token can be retrieved from the cloud server computer and used for, for example... Figure 3 In the transactions described.

[0084] Figure 3A system and method for using cloud tokens for in-app payment transactions are illustrated. The system includes a user 300 operating a mobile communication device 320, which may store an application, such as a mobile wallet or a merchant application 325 as shown in this example. An application server computer (not shown) may be associated with the merchant application 325. The merchant application 325 may be associated with a token requester computer 340, which may be a wallet server computer. A token service computer 360 may communicate with both the token requester computer 340 and the authorization entity computer 380.

[0085] In step S302, user 300 can initiate payment using merchant application 325 on mobile communication device 320 in exchange for products or services. Merchant application 325 can be Apple Pay, Samsung Pay, or Android Pay, and / or any application that requires an access token to complete a transaction and / or obtain some services or products.

[0086] In step S304, the merchant application 325 may send a cloud token request to the token requesting computer 340. The cloud token request may include a token from a bound device. The token requesting computer 340 may use a routing table to determine the location of the corresponding cloud token 345, which stores information that associates a first access token (e.g., a token from a bound device) with the location of a second access token (e.g., the location where the cloud token is stored on the cloud server computer 344). Using this location, the token requesting computer 340 may retrieve the appropriate cloud token 345 from the cloud server computer 344, as shown in step S305. In step S306, the cloud token 345 may be transmitted from the token requesting computer 340 to the merchant application 325 on the mobile communication device 320.

[0087] In steps S308 and S310, the token requesting computer 340 may authenticate the user 300. The authentication request may require the user 300 to provide a PIN or other user identification data (e.g., password, biometric fingerprint, and / or voice sample). If authentication fails or a negative authentication indicator is received, the token requesting computer 340 and / or mobile communication device 320 may display an error message and / or abort the transaction, preventing subsequent steps from being executed.

[0088] In steps S312 and S314, in response to a positive authentication response, the token requesting computer 340 can request an access password from the token service computer 360. The access password may be specifically associated with a particular cloud token 345 that will be used to conduct the transaction. For example, an access token associated with a device for in-store payments may require a specific password to use. Another access token stored in a file on the cloud computer may require a different specific password to use. The password may be a TAVV (Transaction Authentication Verification Value).

[0089] In step S316, the password and access token from the token requester computer 340 can then be provided to the merchant application 325.

[0090] In step S318, once the merchant application 325 obtains the cloud token 345 and the password, the merchant application (or the application provider communicating with the merchant application) can (e.g., via the acquirer and / or payment processing network) submit an authorization request message to the authorizing entity computer 380. The authorizing entity computer 380, the token service computer 360, the payment processor, or the payment processing network can verify the password and can exchange the cloud token 345 for a genuine credential (e.g., a PAN) before the authorizing entity computer 380 makes a decision on the authorization request message.

[0091] Then, the authorizing entity computer can transmit the authorization response message (e.g., via a processing network computer in the payment processing network and a transmission computer operated by the acquirer) back to the merchant application on the communication device 320. In step S320, the authorizing entity computer 380 can transmit the authorization response message back to the merchant application 325 on the mobile communication device 320, thereby authorizing the transaction.

[0092] At the end of the day, clearing and settlement can be carried out between the authorized physical computer 380, the processing network computer, and the transmission computer operated by the merchant's acquiring party.

[0093] Figure 4 Another embodiment of the invention is shown. Figure 4 A system and method are shown for using a mobile communication device 410 to obtain access to a building 430 (e.g., which may refer to any secure location). In yet another embodiment, the building may be a secure server computer housing secure data (e.g., secure and private data records) to be accessed.

[0094] User 406 can use mobile communication device 410 to interact with access device 420. Access device 420 can retrieve a token from the mobile communication device 410, or, if a token from the bound device is not available, request a cloud token (e.g., from the token requester's computer). Figure 3 (As described). The token or cloud token of the binding device can be exchanged for real credentials (e.g., a PIN) that can be used to obtain access to building 430.

[0095] Embodiments of the present invention can be used to provide greater efficiency in token pre-provisioning processing. For example, refer to... Figure 4 In the described system, user 406 can program (e.g., request tokens) and use multiple mobile communication devices (e.g., mobile phones and access cards) through a single provisioning request. Therefore, the user will only need to provide access credentials once to access a secure location through two or more devices (e.g., the aforementioned mobile phones and access cards).

[0096] Figure 5 A block diagram of a mobile communication device 500 that can be used in embodiments of the present invention is shown. The mobile communication device 500 may be a mobile phone or an access card.

[0097] The mobile communication device 500 may include a computer-readable medium 502, which may be in the form of a memory element storing data (e.g., a merchant application) (or may be included in a memory element), and may be in any suitable form (e.g., a microSD chip, a SIM card, or other types of memory elements). The computer-readable medium 502 may store a transaction initiation module 502A, one or more applications 502B, a real credential and / or token 502C, and an operating system 502D for the device. The transaction initiation module 502A can initiate a transaction upon request from a user or application.

[0098] The computer-readable medium 502 may also include a storage element 502B for tokens and credentials used to bind the device. The token / credential storage element 502B may be a secure storage element separate from the rest of the computer-readable medium, such that the token or credential can only be accessed or modified by certain elements of the mobile communication device 500 and / or an external device (e.g., a token requester's computer).

[0099] Additionally, the mobile communication device 500 may include device hardware 504, including: a processor 506, a user interface 508, an input element 510, and an output element 512. The device hardware may also include a long-range antenna 516 and a short-range antenna 514 for communicating with wireless networks and / or other devices. All components in the device hardware 504 are operatively coupled to enable mutual communication and data transmission.

[0100] refer to Figure 6The diagram illustrates a block diagram of a token service computer 600 according to an embodiment of the present invention. The token service computer 600 may include a processor 602 and a network interface 608 for receiving messages (e.g., token provisioning request messages or token response messages) and transmitting the messages to external sources (e.g., authorizing entities and / or token requester computers).

[0101] The token service computer 600 may include a non-transient computer-readable medium 604, which includes a token generation module 604A and a verification module 604B. The token generation module 604A may include code executable by the processor 602 to generate or obtain at least two or more tokens from access credentials. However, this module may also replace a token retrieval module that connects the token service computer 600 to an external database (e.g., an issuer or authorizing entity) that can provide at least two or more tokens. The verification module 604B may be used in conjunction with the processor 602 to determine the eligibility of access credentials.

[0102] The non-transient computer-readable medium 604 may include code executable by processor 602 for implementing methods including: receiving a token request message originating from a token requesting computer; determining two or more access tokens based on a single credential; and transmitting the two or more access tokens to the token requesting computer in a token response message.

[0103] Figure 6 Also shown is a token database 612 operatively coupled to the processor 602. The token database 612 can store pre-generated tokens and other token data, such as token data mapped to real credentials, passwords, etc.

[0104] Figure 7 A block diagram of a token requester computer 700 according to an embodiment of the present invention is shown.

[0105] The token requester computer 700 may also include a processor 702 and a network interface 708 for receiving and transmitting messages (e.g., token response messages) with the token service computer and the cloud server computer.

[0106] The token requesting computer 700 may include a non-transient computer-readable medium 704, which includes a token determination module 704A and a credential transmission module 704B. The token determination module 704A, together with the processor 702, uses a token type indicator to determine whether to send a first access token to the mobile communication device and a second access token to the cloud server computer. The credential transmission module 704B, together with the processor 702, processes the generation or receipt of access credentials from the user-operated mobile communication device and transmits the access credentials to the token service computer to request at least two or more access tokens.

[0107] The non-transient computer-readable medium 704 may include code executable by a processor for implementing methods including: receiving a single credential from a communication device; transmitting the single credential to a token service computer; receiving two or more access tokens from the token service computer, the two or more access tokens including a first access token and a second access token; transmitting the first access token to the communication device; and transmitting the second access token to a cloud server computer.

[0108] The token requesting computer 700 may include a routing table 706 that stores the relationship between the location of a first access token (e.g., a communication device operated by a user) and the secondary location of a second access token (e.g., a cloud storage location on a cloud server computer). The routing table 706 can be accessed to retrieve the appropriate cloud token for the user.

[0109] Any software component or function described in this application may be implemented as software code executable by a processor using, for example, conventional or object-oriented techniques and in any suitable computer language (e.g., Java, C++, or Perl). The software code may be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on different computing devices within a system or network, or on different computing devices.

[0110] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. Therefore, the scope of the invention may be determined not with reference to the above description, but rather with reference to the pending claims and their full scope or equivalents.

[0111] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0112] Unless explicitly indicated otherwise, the use of “a,” “an,” or “the” is intended to indicate “one or more.”

[0113] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This is not an admission that they are prior art.

Claims

1. A method for pre-allocating multiple tokens, comprising: A mobile communication device sends a single credential to a token requester computer, wherein the token requester computer sends a token request message to a token service computer and receives a single token response message from the token service computer, which includes two or more access tokens; The mobile communication device receives a first access token from the token requester computer, the two or more access tokens being two or more payment tokens based on the single credential, and wherein the token requester computer stores a second access token from the two or more access tokens in a cloud server computer; The first access token is stored in the mobile communication device; as well as The application on the mobile communication device accesses the second access token on the cloud server computer to perform interactions using the second access token. The token requester computer includes a routing table that stores the relationship between the mobile communication device operated by the user and the cloud storage location on the cloud server computer. The routing table also stores a first token type indicator associated with the first access token to be stored in the mobile communication device and a second token type indicator associated with the second access token to be stored in the cloud storage location on the cloud server computer, wherein the first token type indicator is used to determine that the first access token is sent to the mobile communication device, and the second token type indicator is used to determine that the second access token is sent to the cloud server computer.

2. The method of claim 1, wherein the single credential is a PAN.

3. The method of claim 1, wherein the second access token includes a cloud token, and the first access token includes a device-specific token.

4. The method of claim 1, wherein the two or more access tokens include three or more access tokens.

5. The method according to claim 1, wherein the mobile communication device is a mobile phone.

6. The method of claim 1, wherein when the mobile communication device receives the first access token, the first access token is encrypted, and wherein the mobile communication device decrypts the first access token before storing it.

7. The method of claim 6, wherein the mobile communication device is a mobile phone.

8. The method of claim 7, wherein the mobile phone includes a security element storing the first access token.

9. A mobile communication device, comprising: processor; as well as A non-transitory computer-readable medium, the non-transitory computer-readable medium comprising code that can be executed by the processor to perform operations including: Send a single credential to a token requester computer, wherein the token requester computer sends a token request message to a token service computer and receives a single token response message from the token service computer including two or more access tokens; The token requester computer receives a first access token from two or more access tokens, the two or more access tokens being two or more payment tokens based on the single credential, and wherein the token requester computer stores a second access token from the two or more access tokens in a cloud server computer; Store the first access token; as well as The application on the mobile communication device accesses the second access token on the cloud server computer to perform interactions using the second access token. The token requester computer includes a routing table that stores the relationship between the mobile communication device operated by the user and the cloud storage location on the cloud server computer. The routing table also stores a first token type indicator associated with the first access token to be stored in the mobile communication device and a second token type indicator associated with the second access token to be stored in the cloud storage location on the cloud server computer, wherein the first token type indicator is used to determine that the first access token is sent to the mobile communication device, and the second token type indicator is used to determine that the second access token is sent to the cloud server computer.

10. The mobile communication device of claim 9, wherein the first access token allows access to a restricted location.

11. The mobile communication device according to claim 9, wherein the mobile communication device is a mobile phone.

12. The mobile communication device of claim 9, wherein the two or more access tokens are capable of being used to access a secure location.

13. The mobile communication device according to claim 9 further includes a security element.

14. The mobile communication device of claim 13, wherein the first access token is stored in the security element.

15. The mobile communication device of claim 9, wherein the first access token is 16 bits long.

16. The mobile communication device of claim 9, wherein the application is a resource provider application.

17. The mobile communication device according to claim 9, wherein the first access token is a device binding token.

Images