Methods and Systems for Token Provisioning and Processing

Abstract

Disclosed is a method and system for provisioning credentials. The method includes receiving, by a token provider computer, a token request message from a token requester computer, the token request message including an initial access identifier. The token provider computer transmits the initial access identifier to a first authorization computer, and then the token provider computer receives an intermediate access identifier. Then, the token provider computer transmits a token activation request message to a second authorization computer at least in part based on the intermediate access identifier. The token provider computer then receives a token activation response message from the second authorization computer. Then, the token provider computer provides the token to the token requester computer.

Description

[0001] Cross - Reference to Related Applications

[0002] This international application claims priority to U.S. Patent Application No. 62 / 721,128, filed on Aug. 22, 2018, the disclosure of which is incorporated herein by reference in its entirety for all purposes. Background of the Invention

[0003] Entities typically maintain accounts for users, whereby users can access resources using an account associated with the entity (e.g., a bank, a government organization, a cloud service provider, etc.). In a banking example, a bank can issue a payment card (e.g., a debit card) to a user as an account issuer, and the payment card allows the user to obtain goods using payment credentials associated with the account (e.g., a primary account number (PAN), CVV2, etc.). In some cases, users can use the payment card for cross - border transactions. For example, a user can obtain a card from a bank in their home country (e.g., Canada) and then travel to another country (e.g., the United States (U.S.)) to perform a payment transaction.

[0004] In addition, modern systems have been created to provision access data (e.g., tokens) for communication devices (e.g., mobile phones), where the access data is associated with a user account that is subsequently used to conduct transactions. For example, continuing with the banking example, a mobile phone can be provisioned with access data (e.g., PAN, payment tokens, etc.) associated with a user's bank account, which can allow the mobile phone to access the account to obtain goods. After the mobile phone is provisioned with the access data, the user can, for example, use the mobile phone to conduct e - commerce transactions using the payment account. In another example, a user can go to a merchant store and tap the mobile phone on an access device (e.g., a point - of - sale (POS) terminal) to conduct a transaction. In a non - banking example, a cloud service provider entity can issue a credential to a specific user that allows the user to access files associated with their account on a remote file share in the cloud. The cloud service provider can provision the mobile phone of the user with access data (e.g., a token) corresponding to the user's credential, which enables the mobile phone to access the files on the remote file share in the cloud via the mobile phone.

[0005] However, a transaction typically involves multiple entities that process transaction-related data at various stages of a transaction processing pipeline. In such cases, interoperability among the entities in the transaction pipeline is a significant challenge. For example, a bank in a particular country may issue a payment card corresponding to user account information (e.g., account number) formatted according to the banking standards of that particular country. However, a merchant store and / or website in another country may have existing infrastructure (e.g., POS terminals, web servers) configured to conduct account number transactions in a different format, which may impede the transaction. In another example, a software application (e.g., digital wallet) on a user's mobile phone may be configured to facilitate provisioning access data for the mobile phone based on receiving a user account number in a particular format, which may be different from the format of the account credentials issued by the issuer.

[0006] Embodiments of the present invention relate to methods and systems for enhancing interoperability between an issuer and other entities involved in a transaction. Embodiments of the present invention address these and other problems, both individually and jointly. Summary of the Invention

[0007] Embodiments of the present invention relate to secure token processing systems and methods.

[0008] One embodiment of the present invention relates to a method including: receiving, by a token provider computer, a token request message from a token requester computer, the token request message including an initial access identifier; transmitting, by the token provider computer, the initial access identifier to a first authorization computer; receiving, by the token provider computer, an intermediate access identifier; transmitting, by the token provider computer, a token activation request message to a second authorization computer at least partially based on the intermediate access identifier; receiving, by the token provider computer, a token activation response message from the second authorization computer; and providing, by the token provider computer, a token to the token requester.

[0009] Another embodiment of the present invention may relate to a token provider computer configured to perform the above method.

[0010] Another embodiment of the present invention relates to a method including: receiving, by a first authorization computer, an initial access identifier from a token provider computer. The method then includes: obtaining, by the first authorization computer, an intermediate access identifier at least partially based on the initial access identifier; and transmitting, by the first authorization computer, the intermediate access identifier to the token provider computer, wherein the token provider computer transmits a token activation request message to a second authorization computer at least partially based on the intermediate access identifier to authorize a token to be provisioned to a token requester computer.

[0011] Another embodiment of the present invention may relate to a first authorization computer configured to perform the above method.

[0012] Another embodiment of the present invention relates to a method, comprising: receiving, by a processing computer, an authorization request message including a token; providing, by the processing computer, the token to a token provider computer in a transaction; receiving, by the processing computer, an intermediate access identifier associated with the token; modifying, by the processing computer, the authorization request message to include the intermediate access identifier; and transmitting, by the processing computer, the authorization request message including the intermediate access identifier to a first authorization computer, wherein the first authorization computer modifies the authorization request message to include an initial access identifier associated with the intermediate access identifier, and transmits the authorization request message with the initial access identifier to a second authorization computer to authorize the transaction.

[0013] Other embodiments of the present invention may relate to a processing computer configured to perform the above method.

[0014] These and other embodiments of the present invention are further described in detail below with reference to the accompanying drawings and the detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A block diagram showing a system according to an embodiment of the present invention.

[0016] Figure 2 A block diagram showing a token requester computer of a system according to an embodiment of the present invention.

[0017] Figure 3 A block diagram showing a token provider computer of a system according to an embodiment of the present invention.

[0018] Figure 4 A block diagram showing a first authorization computer of a system according to an embodiment of the present invention.

[0019] Figure 5 A block diagram showing a processing computer of a system according to an embodiment of the present invention.

[0020] Figure 6 A block diagram showing a system and a flow sequence according to an embodiment of the present invention, showing a first provisioning process using push provisioning.

[0021] Figure 7 A block diagram showing a system and a flow sequence according to an embodiment of the present invention, showing a second provisioning process using manual provisioning.

[0022] Figure 8A block diagram showing a system and a process sequence according to an embodiment of the present invention, showing the use of tokens.

[0023] Figure 9 A block diagram showing a system according to an embodiment of the present invention, showing the use of tokens. Detailed Description

[0024] Embodiments of the present invention provide a mechanism for facilitating the secure token provisioning for a token requester computer (e.g., a communication device such as a mobile phone) for subsequent transaction use. In one embodiment, the advanced provisioning process flow may proceed as follows. First, the token requester computer may initiate the provisioning process by transmitting an initial access identifier (e.g., an International Bank Account Number (IBAN) obtained from the issuing bank) and a user identifier (e.g., a user name, an email address, etc.) to the token provider computer. Second, the token provider computer then interacts with a first authorization computer (e.g., an intermediary as a trusted third-party agent of the issuer) based on the initial access identifier and the user identifier to obtain an intermediate access identifier (e.g., a virtual PAN). The first authorization computer may store the mapping between the initial access identifier and the intermediate access identifier for future use in processing transactions. Third, based on the intermediate access identifier received from the first authorization computer, the token provider computer interacts with a second authorization computer (e.g., the issuer) to obtain token activation approval. Fourth, the token provider computer then provides the activated token to the token requester computer, and the activated token may be stored for future use. The token provider computer may store the mapping between the intermediate access identifier and the token for future use in processing transactions.

[0025] In some embodiments, the token may be "pushed" provisioned to the token requester computer by an issuer application (e.g., a bank application), and the issuer application initiates a provisioning request by "pushing" a payload including user credentials to an application (e.g., a digital wallet) executed on the token requester computer. In this case, the user can use only the issuer application to select the digital wallet for which the token is to be provisioned, and there is no need for the user to manually enter the credentials. The token requester computer may then initiate the provisioning process through the token provider computer as described above.

[0026] In other embodiments, the token may be "manually" provisioned to the token requester computer, whereby a token requester application executed on the token requester computer directly receives inputs such as a user identifier and an initial access identifier from the user (e.g., through keyboard input). The token requester computer may then initiate the provisioning process through the token provider computer as described above.

[0027] In some embodiments, after the token requester computer is pre-provisioned with a token, the token requester computer can use the token to conduct a transaction. In one embodiment, and using a payment transaction as a non-limiting example, the advanced transaction process flow can proceed as follows. First, a communication device (which can be, for example, the same token requester computer that was previously pre-provisioned with the token) can interact with an access device (such as by tapping the phone on the merchant POS terminal) by transmitting the pre-provisioned token to the access device. Second, the access device can transmit an authorization request message including the token to a transmission computer (such as an acquirer computer associated with the merchant access device). Third, the transmission computer can transmit the authorization request message including the token to a processing computer (such as a server computer within a payment processing network like VisaNet TM and so on). Fourth, the processing computer can then use the token to retrieve an intermediate access identifier (such as by leveraging the mapping previously stored by the token provider computer during the pre-provisioning process). The processing computer can then modify the authorization request message to include the intermediate access identifier. Fifth, the processing computer can transmit the modified authorization request message to a first authorization computer. Sixth, the first authorization computer can use the intermediate access identifier to retrieve an initial access identifier (such as by leveraging the mapping previously stored by the first authorization computer during pre-provisioning). The first authorization computer can then modify the authorization request message to include the initial access identifier. Seventh, the first authorization computer can send the modified authorization request message to a second authorization computer. Eighth, the second authorization computer can approve the transaction at least in part based on the initial access identifier received from the first authorization computer.

[0028] Embodiments of the present invention provide several technical advantages. In one non-limiting example, some initial access identifiers, such as IBAN, may be incompatible with existing token provisioning systems (e.g., which may require PAN format). Thus, using conventional techniques, a user may not be able to provision their communication device (e.g., mobile phone) with payment tokens based on the issued IBAN. In contrast, embodiments of the present invention utilize an intermediate access identifier within an existing token provisioning system to provide interoperability between an issuer and other entities (e.g., a token provider service). In this way, a user can provision their mobile phone with payment tokens using the IBAN. Thus, for example, a user can tap their token-provisioned mobile phone on a merchant access device to conduct a transaction. Additionally, a user can travel to another country (e.g., with a different payment processing system) and still be able to tap their token-provisioned mobile phone on a merchant access device to conduct a transaction. In yet another example, a user can use a digital wallet on their mobile phone to conduct remote e-commerce transactions based on tokens associated with an otherwise incompatible IBAN. Embodiments of the present invention also provide greater data security during the authorization process. For example, even if the intermediate access identifier may be cracked in a man-in-the-middle attack, in some embodiments, the intermediate access identifier will be of little value as it cannot be used to conduct a transaction.

[0029] It should be understood that the technical advantages of the present invention are not limited to payment-based token provisioning systems. In another non-limiting example, a cloud service provider may issue credentials for accessing files, where the credentials may have a specific format depending on a particular geographical region and / or organization associated with the user. A token provisioning system may be configured to provision tokens for accessing files only upon receipt of credentials in a different format. Similar to that described above, embodiments of the present invention can utilize an intermediate access identifier to provide interoperability between a cloud service provider issuer and a token provisioning system, such that for example, a user with issued credentials in an otherwise incompatible format can still provision a token for their communication device, and thus the user can access files in the cloud. This can also reduce the number of infrastructure updates required for a particular issuer (e.g., a bank, cloud service provider, etc.) to be interoperable with multiple token provisioning systems, and thus enable more efficient token provisioning for a wider variety of users.

[0030] Before discussing embodiments of the present invention, it may be useful to provide some description of some terms.

[0031] "Communication device" may include any suitable electronic device operable by a user, which may also provide remote communication capabilities with a network. For example, a communication device may be a personal computer (PC). A "mobile communication device" may be an example of a "communication device" that can be easily transferred. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (such as 3G, 4G or similar networks), Wi-Fi, 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, laptops, personal music players, handheld dedicated readers, etc. Other examples of mobile communication devices include wearable devices such as smart watches, fitness bracelets, ankle rings, rings, earrings, etc., and automobiles having remote communication capabilities. In some embodiments, a mobile communication device may act as a payment device (e.g., the mobile communication device may store and be capable of transmitting payment credentials for a transaction).

[0032] "Payment device" may include any suitable device that can be used to perform a financial transaction such as providing payment credentials to a merchant. A payment device may be a software object, a hardware object or a physical object. As an example of a physical object, a payment device may include a substrate (such as a paper card or a plastic card), and information printed, embossed, encoded or otherwise included on or near the surface of the object. A hardware object may relate to circuitry (e.g., a permanent voltage value), while a software object may relate to non-permanent data stored on the device (such as an identifier of a payment account). A payment device may be associated with a value such as a monetary value, a discount or a store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network or an individual. Suitable payment devices may be handheld and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). Example payment devices may include smart cards, magnetic stripe cards, keychain devices (such as Speedpass available from Exxon-Mobil Corporation TM ) etc. Other examples of payment devices include payment cards, smart media, transponders, etc. If the payment device is in the form of a debit card, a credit card or a smart card, the payment device may also optionally have features such as a magnetic stripe. Such devices may operate in contact or non-contact mode.

[0033] "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, as well as any object or document that can be used for confirmation. Examples of credentials include value vouchers, identification cards, authentication documents, access cards, passwords and other login information, etc.

[0034] A "payment credential" 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 a PAN (primary account number or "account number"), user name, expiration date, and verification values such as CVV, dCVV, CVV2, dCVV2, and CVC3 values.

[0035] An "application" may be a computer program for a specific purpose. Examples of applications may include banking applications, digital wallet applications, cloud service applications, ticketing applications, etc.

[0036] A "digital wallet" may include an electronic device and / or an application that allows an individual to conduct e-commerce transactions. The digital wallet may store user profile information, payment credentials, bank account information, access data, tokens, one or more digital wallet identifiers, and / or the like, and may be used in various transactions such as, but not limited to, e-commerce, social networking, money transfer / personal payments, mobile commerce, proximity payments, gaming, and / or the like, for retail purchases, digital goods purchases, utility payments, purchasing games or game credits from a gaming website, transferring funds between users, accessing secure data, and / or the like. The digital wallet may be designed to simplify the purchase and payment process. The digital wallet may allow a user to load one or more payment cards onto the digital wallet for making payments without entering the account number or presenting a physical card.

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

[0038] "Initial access identifier" may include the identifier initially used by a user. The initial access identifier may be the original credential issued by an issuer. The initial access identifier may be in any suitable format, such as alphanumeric characters, alphabetic characters, numeric values, text-based, etc. In some cases, the initial access identifier may be associated with an account of a single user. In other cases, the initial access identifier may be associated with multiple users who may share an account, for example. Examples of the initial access identifier may include an original primary account number or an IBAN identifier. An IBAN identifier (also referred to as "IBAN") may include alphanumeric characters and not just digits. Other examples may include cloud service accounts, public transportation accounts, building access identifiers, etc. The initial access identifier may also include a combination of fields, such as including an IBAN identifier and an email address or another user identifier.

[0039] "Intermediate access identifier" may include an identifier that can be used as an intermediate party in a process. The intermediate access identifier may be in any suitable format, such as alphanumeric characters, alphabetic characters, numeric values, text-based, etc. In some cases, the intermediate access identifier may be associated with a single user or with multiple users who may share an account, for example. Additionally, in some cases, the intermediate access identifier can be used to conduct a transaction. In other cases, the intermediate access identifier may not be used to conduct a transaction. For example, the intermediate access identifier may include a virtual PAN that maps to an IBAN initial access identifier. The virtual PAN may then be mapped to a token. In some cases, the intermediate access identifier is 16, 18, or 19 digits long and may resemble a real PAN (primary account number), but may not be used to conduct a transaction.

[0040] "Token" may be a replacement value for a credential. A token may be a string of digits, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0041] A "payment token" may include a payment account identifier that replaces an account identifier such as a PAN or IBAN. For example, a payment token may include a replacement series of alphanumeric characters that can be used as the original account identifier. For example, the token "4900 00000000 0001" may be used to replace the PAN "4147 0900 00001234". In some embodiments, a payment token may be "in a reserved format" and may have a numeric format consistent with the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction, or to represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a payment token may be generated such that it may not be computationally possible to derive the recovery of the original PAN or other account identifier from the token value. Additionally, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0042] "Tokenization" is the process of replacing data with replacement data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a replacement number (e.g., a token) that may be associated with the payment account identifier. Additionally, tokenization may be applied to any other information that can be replaced with a replacement value (i.e., a token). Tokenization improves transaction efficiency and security.

[0043] A "token issuer", "token provider", or "token service system" may include a system that services tokens. In some embodiments, the token service system may facilitate the request, determination (e.g., generation), and / or issuance of tokens, and maintain a mapping of established tokens to credentials (e.g., primary account number (PAN)) in a repository (e.g., a token vault). In some embodiments, the token service system may establish a token assurance level for a given token to indicate the level of confidence that the token is bound to the PAN. The token service system may include or communicate with a token vault in which the generated tokens are stored. By de-tokenizing a token to obtain the actual credential (e.g., PAN), the token service system may support token processing of payment transactions submitted using the token. In some embodiments, the token service system may include only a tokenization computer, or may include a tokenization computer in combination with other computers such as transaction processing network computers. Various entities in the tokenization ecosystem may assume the role of the token service provider. For example, a payment network and an issuer or its agent may become a token service provider by implementing a token service according to an embodiment of the present invention.

[0044] "Token domain" may indicate the area and / or environment where a token can be used. Examples of token domains may include, but are not limited to, various payment channels (e.g., e-commerce, physical point of sale, etc.), POS input modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers that uniquely identify where the token can be used. A set of parameters (i.e., token domain restriction controls) may be established by the token service provider as part of token issuance, and the parameters may allow for the proper use of tokens to be enforced in payment transactions. For example, the token domain restriction controls may limit the use of tokens in a specific presentation mode - e.g., contactless or e-commerce presentation mode. In some embodiments, the token domain restriction controls may limit the use of tokens at a specific merchant that can be uniquely identified. Some exemplary token domain restriction controls may require verification of the existence of a token password that is unique for a given transaction. In some embodiments, the token domain may be associated with the token requester.

[0045] "Token expiration date" may indicate the expiration date / time of the token. The token expiration date may be passed between entities in the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numerical value (e.g., a 4-digit numerical value). In some embodiments, the token expiration date may be expressed as a duration measured from the time of issuance.

[0046] "Token request message" may be an electronic message for requesting a token. The token request message may include information that can be used to identify an account (e.g., a payment account) or a digital wallet and / or information for generating a token. For example, the token request message may include payment credentials, mobile device identification information (e.g., a phone number or MSISDN), digital wallet identifier, information identifying the tokenization service provider, merchant identifier, account access identifier, user identifier, 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).

[0047] "Token response message" may be a message in response to a token request. The token response message may include an indication that the token request was approved or rejected. The token response message may also include a payment token, mobile device identification information (e.g., a phone number or MSISDN), digital wallet identifier, information identifying the tokenization service provider, merchant identifier, 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).

[0048] "Token requester identifier" may include any character, number, or other identifier associated with an entity associated with a 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 for each domain of token requests associated with the same token requester. For example, a token requester identifier may identify the 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.). A token requester identifier may include information in any format or type. For example, in one embodiment, a token requester identifier may include a numerical value such as a ten-digit or eleven-digit number (e.g., 4678012345).

[0049] "User" may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0050] "User identifier" may include any character, number, or other identifier associated with a user associated with a network token system. For example, a user identifier may be associated with an entity registered in the network token system. For example, in one embodiment, a user identifier may be a customer ID or an email address associated with an authorized user of a bank account maintained by a bank.

[0051] "Resource provider" may be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, shipping agents, government entities, venue and residential operators, etc.

[0052] "Merchant" generally may be an entity that participates in a transaction and may sell goods or services or provide access to goods or services.

[0053] "Acquirer" generally may be a commercial 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 cover such a single entity issuer-acquirer. An acquirer may operate an acquirer computer, which generally may also be referred to as a "transmission computer".

[0054] "Authorizing entity" may be an entity that authorizes a request. Examples of authorizing entities may be an issuer, a government agency, a document repository, an access administrator, etc.

[0055] "Issuer" generally may refer to a commercial entity (e.g., a bank, a cloud service provider) that maintains a user account. An issuer may also issue a credential (e.g., a payment credential) to a consumer for storage on a user device such as a cellular phone, a smart card, a tablet computer, or a laptop computer.

[0056] An "access device" can be any suitable device that provides access to a remote system. The access device can also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device can generally be located at any suitable location, such as at the location of the merchant. The access device can take any suitable form. Some examples of access devices include POS or point-of-sale devices (such as POS terminals), cellular phones, PDAs, personal computers (PCs), server computers, tablet computers, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), information kiosks, security systems, access systems, and the like. The access device can use any suitable contact or non-contact operating mode to send or receive data from or associated with a mobile communication device or a payment device. In some embodiments where the access device can include a POS terminal, any suitable POS terminal can be used and it can include a reader, a processor, and a computer-readable medium. The reader can include any suitable contact or non-contact operating mode. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and / or a mobile device. In some embodiments, a cellular phone, a tablet computer, or other dedicated wireless device used as a POS terminal can be referred to as a mobile point-of-sale or "mPOS" terminal.

[0057] An "authorization request message" can be an electronic message that requests authorization for a transaction. In some embodiments, the authorization request message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization for the transaction. An authorization request message according to some embodiments can conform to ISO 8583, which is a standard for a system for exchanging electronic transaction information associated with payments made by a user using a payment device or a payment account. The authorization request message can include an issuer account identifier that can be associated with a payment device or a payment account. The authorization request message can also include additional data elements corresponding to "identification information", by way of example only, including: service code, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), payment token, user identifier, initial access identifier, intermediate access identifier, expiration date, and the like. The authorization request message can also include "transaction information", such as any information associated with the current transaction, such as the transaction amount in the case of a payment transaction, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying the item purchased, and the like, and any other information that can be used to determine whether to identify and / or authorize the transaction.

[0058] "Authorization response message" can be a message in response to an authorization request. In some cases, an authorization response message can be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. By way of example only, an authorization response message can include one or more of the following status indicators: Approved - the transaction is approved; Declined - the transaction is not approved; or Call Center - for more information on a pending response, the merchant must call a toll-free authorization telephone number. An authorization response message can also include an authorization code, which can be a code indicating that the transaction is approved that is returned by a credit card issuing bank (either directly or through a transaction processing computer) to the merchant's access device (e.g., a POS device) in response to an authorization request message in an electronic message. The code can serve as proof of authorization. An authorization response message can also include additional data elements similar to the "identification information" described above, which can be used to route the message back to the requester.

[0059] "Token presentation mode" can indicate the method used to submit a token for a transaction. Some non-limiting examples of token presentation modes can include machine-readable codes (e.g., QR TM codes, barcodes, etc.), mobile contactless modes (e.g., Near Field Communication (NFC) communication), e-commerce remote modes, e-commerce proximity modes, and any other suitable mode for submitting a token.

[0060] "Server computer" can include a powerful computer or a computer cluster. For example, a server computer can be a mainframe, a small computer cluster, or a group of servers working as a unit. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to service requests from one or more client computers.

[0061] "Identification and Verification (ID&V) methods" can be used to ensure that a payment token will replace the PAN that has been properly used by the token requester. Examples of ID&V methods can include, but are not limited to, account verification messages, risk scores based on an assessment of the Primary Account Number (PAN), and the use of a one-time password by the issuer or its agent to verify the account holder. Exemplary ID&V methods can be performed using the following information: such as user signature, password, offline or online Personal Identification Number (PIN), offline or online encrypted PIN, combination of offline PIN and signature, combination of offline encrypted PIN and signature, user biometrics (e.g., voice recognition, fingerprint matching, etc.), patterns, glyphs, knowledge-based challenge responses, hardware tokens (multiple solution options), limited-use one-time passwords (OTP), software tokens, two-channel authentication processes (e.g., via phone), etc. Using ID&V, a confidence level regarding the binding of the token to the PAN can be established.

[0062] "Token Assurance Level" can refer to an indicator or value that allows a token service provider to indicate the confidence level of the binding of a token to a PAN. The Token Assurance Level can be determined by the token service provider based on the type of Identification and Verification (ID&V) performed and the entity performing the ID&V. The Token Assurance Level can be set at the time of token issuance. If additional ID&V is performed, the Token Assurance Level can be updated.

[0063] "Requested Token Assurance Level" can refer to the Token Assurance Level requested by the token requester from the token service provider. The Requested Token Assurance Level can be included in a field of the token request message sent by the requester to the token service provider for the generation / issuance of a token.

[0064] "Assigned Token Assurance Level" can refer to the actual (i.e., generated) value assigned to a token by the token service provider resulting from the Identification and Verification (ID&V) process performed by an entity within the tokenization ecosystem. The Assigned Token Assurance Level can be provided back to the token requester in response to the token request message. The Assigned Token Assurance Level can be different from the Requested Token Assurance Level included in the token request message.

[0065] "Token attributes" may include any characteristics or information about the token. For example, token attributes may include information that determines how the token can be used, delivered, issued, or how data can be manipulated within the transaction system. For example, token attributes may include token type, usage frequency, token expiration date and / or time, associated token number, transaction term expiration date, and any additional information that may be related to any entity within the tokenization ecosystem. For example, token attributes may include wallet identifiers associated with the token, additional account aliases, or another user account identifier (e.g., email address, username, etc.), device identifier, invoice number, etc. In some embodiments, the token requester may provide token attributes when requesting the generation of a token. In some embodiments, the network token system, a payment network associated with the network token system, the issuer, or any other entity associated with the token may determine and / or provide token attributes associated with a particular token.

[0066] Token attributes may identify the token type that indicates how the token can be used. Payment tokens may include high-value tokens that can be used in place of a real account identifier (e.g., PAN) to generate original and / or subsequent transactions for a consumer account and / or card. Another token type may be a "static" or "dynamic" token type for static and dynamic tokens, respectively.

[0067] A "token requester" may refer to an entity that attempts to implement tokenization according to embodiments of the present invention. In some embodiments, the token requester may initiate a request to tokenize a primary account number (PAN) or an initial access identifier by submitting a token request message to a token service provider. According to various embodiments discussed herein, the token requester may no longer need to store the PAN associated with the token after the requester receives the token in response to the token request message. The requester may be an application, device, process, or system configured to perform actions associated with the token. For example, the requester may request to register with a network token system, request token generation, token activation, token deactivation, token exchange, other token lifecycle management-related processes, and / or any other token-related processes. The requester may interface with the network token system via any suitable communication network and / or protocol (such as using HTTPS, SOAP, and / or XML interfaces, etc.). Some non-limiting examples of token requesters may include, for example, the communication device of an authorized account holder, a card-on-file merchant, an acquirer, an acquirer processor, a payment gateway operating on behalf of a merchant, a payment enabler (e.g., an original equipment manufacturer, a mobile network operator, etc.), a digital wallet provider, an issuer, a third-party wallet provider, and / or a payment processing network. In some embodiments, the token requester may request tokens for multiple domains and / or channels. The token requester may be uniquely registered and identified by a token service provider within the tokenization ecosystem. During the registration of the token requester, the token service provider may formally process the application of the token requester to participate in the token service system. The token service provider may collect information about the nature of the requester and the related use of the token to verify and formally approve the token requester and establish appropriate domain restriction controls. A token requester identifier may be assigned to the successfully registered token requester, and the token requester identifier may also be entered into and maintained in a token library. The token requester may be revoked or assigned a new token requester identifier. This information may be reported and audited by the token service provider.

[0068] A "token request indicator" may refer to an indicator used to indicate that a message containing the indicator relates to a token request. The token request indicator may be passed as part of an identification and verification (ID&V) method as needed to notify the issuer of the reason for performing an account status check.

[0069] A "payment network" may refer to an electronic payment system used to accept, transmit, or process transactions made by a payment device for funds, goods, or services. The payment network may transfer information and funds between an issuer, an acquirer, a merchant, and a payment device user.

[0070] Figure 1A block diagram of a system 100 for pre-provisioning a token according to an embodiment of the present invention is shown. The system 100 includes a token requester computer 102, a token provider computer 104, a first authorization computer 106, and a second authorization computer 108 that may be associated with a user 101.

[0071] The token requester computer 102, the token provider computer 104, the first authorization computer 106, and the second authorization computer 108 may all be operatively communicable with each other via any suitable communication channel or communication network. Suitable communication networks may be any one and / or combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an operation task as an Internet node (OMNI), a secure custom connection, a wide area network (WAN), a wireless network (e.g., employing protocols such as but not limited to Wireless Application Protocol (WAP), i-mode, etc.), and so on. Messages between computers, networks, and devices may be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc.

[0072] The token requester computer 102 may be configured to receive input from the user 101 that indicates the token requester computer 102 initiates a token pre-provisioning process via the token provider computer 104 to pre-provision a token. In some embodiments, the token requester computer 102 may be a communication device of the user 101 (e.g., a mobile phone, a PC, etc.) that receives instructions from the user 101 to pre-provision a token for the communication device. In some embodiments, and as described in the embodiments below, the token requester computer 102 and the communication device to be pre-provisioned may be the same device. However, it should be understood that in other embodiments, they may be different devices. For example, the token requester computer 102 may request a token on behalf of another communication device and then transmit the token to the other communication device for storage after receiving the token.

[0073] In some embodiments, the token requester computer 102 may execute a token requester application, such as a digital wallet, which may be responsible for requesting, storing, and / or managing one or more tokens received by the token provider computer 104. In some embodiments, the token requester computer 102 may also execute an issuer application, such as a mobile banking application, a cloud service application, a public transportation account application, etc. The issuer application may be responsible for sending a token request message to the token requester application to initiate a pre-provisioning process via the token provider computer 104. However, in other embodiments, the token requester computer 102 may not include an issuer application.

[0074] The token provider computer 104 can be a computer associated with the token provider. The token provider computer 104 can facilitate the request, determination (e.g., generation), and / or issuance of tokens. For example, the token provider computer 104 can receive a token request message from the token requester computer 102, and then facilitate a series of message exchanges with the first authorization computer 106 and the second authorization computer 108. After that, the token provider computer 104 provides the activated token to the token requester computer 102. In some embodiments, the token provider computer 104 can also maintain a mapping of tokens to identifiers in a repository (e.g., a token repository). For example, the token provider computer 104 can maintain a mapping from tokens to intermediate access identifiers, initial access identifiers, etc. The token provider computer 104 can include or communicate with a token repository in which the generated tokens are stored. The token provider computer 104 can support token processing of a transaction submitted using a token by detokenizing the token to obtain the associated identifier (e.g., the intermediate access identifier), and then transmitting the associated identifier to the first authorization computer 106 for further processing.

[0075] The first authorization computer 106 can be a server computer that acts as an intermediary between the token provider computer 104 and the second authorization computer 108. In some embodiments, the first authorization computer 106 can be associated with a third-party entity (e.g., an issuer processor) that acts as a trusted agent for the issuer entity (e.g., a bank). In other embodiments, the first authorization computer 106 can be directly associated with the issuer entity. In some embodiments, both the first authorization computer 106 and the token provider computer 104 are operated by the token provider, and / or their respective functions can be performed by the same server computer. During the token provisioning process, the first authorization computer 106 can be responsible for obtaining (e.g., generating) an intermediate access identifier based on the initial access identifier and maintaining a mapping between the initial access identifier and the intermediate access identifier. During the transaction processing phase, the first authorization computer 106 can receive the intermediate access identifier from the token provider computer 104, retrieve the initial access identifier using the mapping, and then transmit the initial access identifier to the second authorization computer 108 for transaction authorization.

[0076] The second authorization computer 108 can be a server computer associated with the issuer. During the token provisioning phase, the second authorization computer 108 can be responsible for approving or rejecting a token activation request received from the token provider computer 104 on behalf of the token requester computer 102. During the transaction processing phase, the second authorization computer 108 can be responsible for authorizing or rejecting an authorization request received from the token provider computer 104 on behalf of the token requester computer 102.

[0077] Figure 2A block diagram of a token requester computer 102 showing a system according to an embodiment of the present invention. In some embodiments, the token requester computer 102 can be a communication device (such as a mobile phone) that can be used for making payments or a device that can allow a user to obtain access to a certain location. An exemplary token requester computer 102 can include a computer-readable medium 102-B and a memory 102-C that can be present within a body 102-J of the token requester computer 102. The body 102-J can be in the form of a plastic substrate, a housing, or other structures. In some cases, the memory 102-C can be a secure element and / or can also store information such as access data, such as tokens, PANs, tickets, etc. The information in the memory 102-C can be transmitted by the token requester computer 102 to another device using an antenna 102-D or a contactless element 102-I.

[0078] The computer-readable medium 102-B can include code that can be executed by a processor to implement a method according to an embodiment. The computer-readable medium 102-B can contain an issuer application 110 and a token requester application 120. The issuer application 110 can be used to "push" a provisioned token for the token requester computer 102 by transmitting a token request message to the token requester application 120. The issuer application can also provide functions provided by the issuer and can allow the token requester computer 120 to communicate with an issuer computer (such as a second authorization computer 108). Examples of the issuer application can include banking applications, payment applications, merchant applications, transportation applications, applications for accessing secure data, etc. The token requester application 120 can allow the token requester computer 102 to communicate with a token provider computer 104. Examples of the token requester application can include various types of digital wallet applications (such as for money transfer / personal payment, mobile commerce, accessing secure data, etc.). The token requester application 120 can be used to facilitate the enrollment process to provision a token onto the token requester computer 102. The token requester application can also subsequently be used to conduct transactions using the token without the user 101 having to enter an account number or present a physical card.

[0079] In some embodiments, the token requester computer 102 may also include a contactless element 102-I, which is typically implemented in the form of a semiconductor chip (or other data storage element) having associated wireless transmission (e.g., data transfer) elements such as an antenna. Data or control instructions transmitted via a cellular network may be applied to the contactless element 102-I via a contactless element interface (not shown). The contactless element 102-I is capable of transmitting and receiving data using short-range wireless communication capabilities. Thus, the token requester computer 102 is capable of transmitting and transferring data or control instructions via a cellular network (or any other suitable wireless network, e.g., the Internet or other data network) and short-range communication.

[0080] The token requester computer 102 may also include a processor 102-A (e.g., a microprocessor) for processing the functions of the token requester computer 102 and a display 102-G that allows a user to view information. The token requester computer 102 may also include an input element 102-E (e.g., a touch screen, keyboard, touch pad, sensors such as biometric sensors, etc.), a speaker 102-H, and a microphone 102-F. The token requester computer 102 may also include an antenna 102-D for wireless data transmission.

[0081] Figure 3 A block diagram of a token provider computer 104 of a system according to an embodiment of the present invention is shown. Figure 3 A token provider computer 104 and a token library 130 coupled to the token provider computer 104 are shown.

[0082] The token library 130 may store tokens and their associated credentials in a database. The token library 130 may store data in a token record database such as an Oracle TM database. In some embodiments, the token library 130 may store a mapping between tokens and one or more associated credentials (e.g., intermediate access identifiers and / or initial access identifiers) in the database.

[0083] The token provider computer 104 may include a processor 104-A, which may be coupled to a system memory 104-B and an external communication interface 104-C. A computer-readable medium 104-D may also be operatively coupled to the processor 104-A.

[0084] The computer-readable medium 104-D may include several software modules, the software modules including a communication module 104-D1, an encryption module 104-D2, a token provisioning module 104-D3, an authentication module 104-D4, and an enrollment facilitation module 104-D5.

[0085] The communication module 104-D1 may include code that enables the processor 104-A to generate messages, forward messages, reformat messages, and / or communicate with other entities in other ways.

[0086] In an embodiment of the present invention, the encryption module 104-D2 may include code that includes any suitable encryption algorithm for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, etc. It may also store encryption keys that can be used with such encryption algorithms. The encryption module 104-D2 may utilize symmetric or asymmetric encryption techniques to encrypt and / or authenticate data.

[0087] The token provisioning module 104-D3 may include code that enables the processor 104-A to provide tokens. For example, the token provisioning module 104-D3 may contain logic that enables the processor 104-A to generate payment tokens and / or associate a payment token with a set of payment credentials (such as an intermediate access identifier). The token record may then be stored in the token record database of the token library 130 to indicate that the payment token is associated with a particular user or set of payment credentials (i.e., mapped to the user or payment credentials).

[0088] The verification module 104-D4 may include code that enables the processor 104-A to verify a token request before providing a token. For example, the verification module 104-D4 may contain logic that enables the processor 104-A to confirm the authenticity of the token request message by decrypting the password included in the message, by confirming that the payment credentials are genuine and associated with the requesting device (such as the token requester computer 102), and / or by evaluating the risk associated with the requesting device.

[0089] The registration facilitation module 104-D5 may include code that causes the processor 104-A to transmit a message to one or more entities to facilitate the token provisioning process. For example, the registration facilitation module 104-D5 may contain logic that causes the processor 104-D5 to transmit a message containing an initial access identifier received from the token requester computer 102 to the first authorization computer 106. The registration facilitation module 104-D5 may also receive back an intermediate access identifier from the first authorization computer 106. In some embodiments, the registration facilitation module 104-D5 may then exchange messages with the token requester computer 102 to receive input from the user 101 to continue the registration process (e.g., agree to terms). In some embodiments, based on receiving the intermediate access identifier from the first authorization computer 106 and / or input from the user 101 indicating agreement to the terms, the registration facilitation module 104-D5 may then send a token activation request message to the second authorization computer 108 and receive back a token activation response message indicating approval or rejection of the activation request. The registration facilitation module 104-D5 may then forward this indication back to the token requester computer 102. Assuming the second authorization computer 108 approves the activation request, the registration facilitation module 104-D5 may provide the token to the token requester computer 102 and store the mapping of the token to one or more credentials (e.g., the intermediate access identifier) in the token repository 130.

[0090] Figure 4 A block diagram of the first authorization computer 106 of a system according to an embodiment of the present invention is shown. The first authorization computer 106 may be coupled to a record database (not shown), whereby the first authorization computer 106 stores a mapping between identifiers. For example, the database may store a mapping between an initial access identifier and an intermediate access identifier. In some embodiments, the mapping may also include other associations, such as a mapping between the initial access identifier and a user identifier corresponding to the user 101. In some embodiments, for example, if the first authorization computer 106 and the token provider computer 104 operate as a single entity, the record database of the first authorization computer 106 and the token record database of the token repository 130 may correspond to the same database. In such a case, the token repository 130 may store a mapping between the token, the initial access identifier, the intermediate access identifier, and / or the user identifier.

[0091] The first authorization computer 106 may include a processor 106-A, which may be coupled to a system memory 106-B and an external communication interface 106-C. A computer-readable medium 106-D may also be operably coupled to the processor 106-A.

[0092] The computer-readable medium 106-D may include several software modules, the software modules including a communication module 106-D1, an encryption module 106-D2, an identifier conversion module 106-D3, an authentication module 106-D4, and an authorization request transformation module 106-D5.

[0093] The communication module 106-D1 may include code that causes the processor 106-A to generate a message, forward a message, reformat a message, and / or otherwise communicate with other entities.

[0094] In an embodiment of the present invention, the encryption module 106-D2 may include code that includes any suitable encryption algorithm for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, etc. It may also store encryption keys that may be used with such encryption algorithms. The encryption module 106-D2 may utilize symmetric or asymmetric encryption techniques to encrypt and / or authenticate data.

[0095] The identifier conversion module 106-D3 may include code that causes the processor 106-A to obtain (e.g., generate or retrieve from an existing pool in a record database) an intermediate access identifier based on a received initial access identifier. In some embodiments, e.g., in the case of retrieving from an existing pool, the identifier conversion module 106-D3 may maintain a record of intermediate access identifiers mapped to active (e.g., unexpired or not deactivated) initial access identifiers as well as non-active initial access identifiers. For example, the first authorization computer 106 may receive an update from the token provider computer 104 regarding which initial access identifiers are active. If, after receiving a request for an intermediate access identifier based on a received initial access identifier, the identifier conversion module 106-D3 determines that an existing intermediate access identifier is currently mapped to a non-active initial access identifier, the identifier conversion module 106-D3 may provide the existing intermediate access identifier and remap the intermediate access identifier to the initial access identifier received as input. In other embodiments, after receiving a request, the identifier conversion module 106-D3 may generate a new intermediate access identifier and map it to the initial access identifier received as input. In some embodiments, the generated or updated intermediate access identifier and the corresponding mapping may be stored in a record database.

[0096] The verification module 106-D4 may include code that causes the processor 106-A to verify an identifier request before providing an identifier (such as an intermediate access identifier). For example, the verification module 106-D4 may contain logic that causes the processor 106-A to confirm the authenticity of a request message by decrypting a password included in the message, by verifying that credentials (such as an initial access identifier, a user identifier, etc.) are authentic and associated with the requesting device (such as the token requester computer 102, the token provider computer 104), and / or by evaluating the risk associated with the requesting device. As described above, the first authorization computer 106 may be a trusted third party agent or otherwise associated with the issuer of the initial access identifier. Thus, the first authorization computer 106 may also receive predefined rules from the issuer (such as the second authorization computer 108) that correspond to whether a particular initial access identifier meets the conditions for the issuance of an intermediate access identifier. For example, the rule may determine that only initial access identifiers (such as IBAN) within a certain range of values are eligible to be mapped to an intermediate access identifier (such as a virtual PAN).

[0097] The authorization request transformation module 106-D5 may include code that causes the processor 106-A to retrieve an identifier based on receiving another identifier during a transaction processing phase. For example, the authorization request transformation module 106-D5 may receive an authorization request message that contains an intermediate access identifier (such as one generated during a token provisioning phase previously performed by the identifier transformation module 106-D3). Based on the intermediate access identifier, the authorization request transformation module 106-D5 may retrieve the associated initial access identifier from a record database. The authorization request transformation module 106-D5 may then modify the authorization request message to include the initial access identifier and then transmit the modified message to another entity (such as the second authorization computer 108) for transaction authorization.

[0098] It should be understood that, as described herein, the stored mapping may be bidirectional. For example, the mapping stored in the token library 130 between a token and an initial access identifier may be operable such that the initial access identifier can be used to retrieve the token and vice versa. In another example, the mapping between an initial access identifier and an intermediate access identifier may be operable such that the intermediate access identifier can be used to retrieve the initial access identifier and vice versa. Thus, for example, if the first authorization computer 106 receives an authorization response message from the second authorization computer 108 that contains an initial access identifier, the first authorization computer 106 may use the initial access identifier to retrieve the associated intermediate access identifier and transmit the intermediate access identifier to another entity (such as a transaction processing computer) for further processing. In this way, messages can be correctly routed in both directions.

[0099] Figure 5A block diagram of a processing computer 150 of a system according to an embodiment of the present invention is shown. Figure 5 A processing computer 150 and a token library 130 coupled to the processing computer 150 are shown. It should be understood that in some embodiments, the processing computer 150 and the token provider computer 104 may be housed within a unit and / or associated with the same token provisioning system.

[0100] The processing computer 150 may include a processor 150-A that can be coupled to a system memory 150-B and an external communication interface 150-C. A computer-readable medium 150-D may also be operably coupled to the processor 150-A.

[0101] The computer-readable medium 150-D may include several software modules, which include a communication module 150-D1, an encryption module 150-D2, a token exchange module 150-D3, and an authentication module 150-D4.

[0102] The communication module 150-D1 may include code that enables the processor 150-A to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0103] In an embodiment of the present invention, the encryption module 150-D2 may include code that includes any suitable encryption algorithm for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, etc. It may also store encryption keys that can be used with such encryption algorithms. The encryption module 150-D2 may utilize symmetric or asymmetric encryption techniques to encrypt and / or authenticate data.

[0104] The token exchange module 150-D3 may include code that enables the processor 150-A to retrieve an identifier based on a received token (or vice versa). For example, in some embodiments, after receiving a token in an authorization request message (e.g., from a token requester computer 102), the token exchange module 150-D3 may retrieve an intermediate access identifier from the token library 130. The intermediate access identifier may have been previously stored in the token library 130 by the token provider computer 104 during a token provisioning process, such that the token maps to the intermediate access identifier. After retrieving the identifier, the token exchange module 150-D3 may transmit the identifier to another entity. For example, the token exchange module 150-D3 may modify the authorization request message to include the intermediate access identifier and then transmit the modified message to another entity (e.g., a first authorization computer 106) for further processing.

[0105] The verification module 150-D4 may include code that causes the processor 150-A to verify an authorization request message based on a token received as input to proceed with a transaction. For example, the verification module 150-D4 may contain logic that causes the processor 104-A to verify an authorization request message by decrypting a password included in the message, confirming that a token included in the message is authentic (e.g., associated with the requesting device), and / or by assessing a risk associated with the requesting device. The verification module 150-D4 may also verify that token attributes (e.g., user identifier, token requester identifier, token expiration date, usage frequency, etc.) comply with a set of predetermined rules. The predetermined rules may be determined by an entity (e.g., an issuing bank) having a trusted relationship with the processing computer 150.

[0106] Figure 6 and 7 respectively show block diagrams of a system and a flow sequence according to an embodiment of the present invention, showing different options for provisioning a token to a device: a first "push" provisioning process, and a second "manual" provisioning process. In Figure 6 the "push" provisioning process, the issuer application 110 (e.g., a banking application) may provide a user ID (e.g., a customer ID) and an initial access identifier (e.g., an IBAN) to the token requester application 120 ("the token requester") (e.g., a digital wallet). The token requester 120 may then initiate a provisioning process via the token provider computer 104. In Figure 7 the "manual" provisioning process, the user may directly provide the user ID and the initial access identifier to the token requester 120. The token requester 120 may then initiate a provisioning process via the token provider computer 104.

[0107] Turning to Figure 6 , more specifically, a block diagram 600 of a system and a flow sequence is shown, showing the "push" provisioning process. Figure 6 A token requester computer 102 that may request a token from the token provider computer 104 is shown. In some embodiments, the token requester computer 102 may be a mobile communication device (e.g., a mobile phone). Additionally, although Figure 6 the issuer application 110 and the token requester application 120 are depicted as being on the same device, embodiments of the present invention should not be construed as being limited thereto. In any case, under the "push" provisioning method, the issuer application 110 may communicate with the token requester 120. The token provider computer 104 may be associated with a token library 130 (e.g., containing the token library or communicating with the token library). The token library 130 may be a database that stores tokens and their associated authentic credentials or intermediate access identifiers. The token provider computer 104 may communicate with a first authorization computer 106 and a second authorization computer 108.

[0108] In the illustrated flow, at step S601, a user may log in to the issuer application 110 via the mobile communication device 102. In some embodiments, the issuer application 110 may correspond to a banking account issued by a bank. The bank may provide the user with one or more payment credentials that may be associated with the banking account and stored by the issuer application 110 on the mobile communication device 102. In some embodiments, the payment credentials may include multiple elements such as a user identifier (e.g., a username, a user email address, a user phone number, etc.), an account number (e.g., a PAN), an expiration date, a CVV2 value, etc. However, in some embodiments, the payment credentials may include fewer elements. For example, the payment credentials provided to the user and / or the issuer application may include only the account number and the user identifier. In other embodiments, e.g., in cases where the account may be shared by multiple users, the payment credentials may include only the account number. In such cases, when the user 101 logs in to the issuer application (e.g., by entering the account number and password), the user identifier may be dynamically provided to the user 101 by the bank. In some embodiments, the account number may be an IBAN, which may have a different format from the PAN. For example, the IBAN may contain an alphanumeric string of characters (e.g., "DE89 3704 0044 0532 0130 00"), while the PAN may be only numeric characters (e.g., "1234 56788765 4321"). In some embodiments, the bank may also issue a payment card (e.g., a debit card) that may be associated with the account and have one or more payment credentials (e.g., a username, an account number, etc.) printed thereon.

[0109] In the flow sequence discussed below with reference to Figure 6 the payment credentials stored by the issuer application 110 on the mobile communication device may include the account number as an IBAN, which may correspond to an initial access identifier. The payment credentials may also include a user identifier that is generated before or at the time of the user 101 logging in. Although, as discussed below, the user identifier is a data element separate from the initial access identifier, embodiments of the present invention should not be construed as being limited thereto. For example, in some embodiments, the initial access identifier may include multiple fields, including the user identifier. It should be noted that in the Figure 6 example, the payment credentials stored on the mobile communication device 102 (and / or printed on the payment card issued to the user 101) may not include certain fields, such as the CVV2 value.

[0110] Continuing with step S601, the issuer application 110 may prompt the user 101 to select a specific application for which to provision the token. The user 101 may then select the token requester application 120, which may be a digital wallet in this example. After selecting the token requester 120, the issuer application 110 may encrypt a payload containing the initial access identifier and the user identifier and transmit the payload to the token requester 120.

[0111] In step S602, the token requester 120 may transmit a token request message that will be received by the token provider computer 104. The token request message may contain the initial access identifier and the user identifier to register the initial access identifier with the token provider computer 104. In some embodiments, the token requester 120 may first decrypt the payload from the issuer application 110 to obtain the initial access identifier and the user identifier. In some embodiments, the token requester 120 may include other information in the token request message, including for example a token requester identifier (e.g., mobile device 102 identifier, digital wallet provider identifier, token domain, etc.). In some embodiments, the token request message may be encrypted.

[0112] In step S604, the token provider computer 104 may then transmit the user identifier and the initial access identifier to the first authorization computer 106, for example by invoking the registration facilitation module 104-D5. Before transmitting the user identifier and the initial access identifier, the token provider computer 104 may first decrypt and / or verify the token request message received from the token requester 120. For example, the token provider computer 104 may invoke the verification module 104-D4 to verify the password from the token requester 120, to authenticate the token requester 120 and to evaluate the risk level of the request. In some embodiments, if the verification module 104-D4 determines that the initial access identifier and / or the device 102 do not meet the criteria, the token provider computer 104 may return an error to the token requester 120.

[0113] After receiving the user identifier and the initial access identifier, the first authorization computer 106 may then obtain (e.g., generate or retrieve from an existing pool) an intermediate account identifier, for example, by invoking the identifier conversion module 106-D3. In some embodiments, the first authorization computer 106 may first invoke the verification module 104-D4 to verify that the initial access identifier meets the criteria, and if it does not, an error may be returned to the token provider computer 104. In some embodiments, assuming successful verification, the obtained intermediate account identifier may correspond to an account identifier that is different in format (e.g., different fields and / or field formats) from the initial access identifier (e.g., virtual PAN). More specifically, the intermediate account identifier may be a virtual debit card number, and it may have an expiration date and a CVV2 value associated therewith (e.g., in contrast to the initial access identifier, which may be an IBAN that does not have an associated CVV2 value). In some embodiments, the intermediate account identifier may be associated with an expiration date that is independent of the expiration date of the initial access identifier. In other embodiments, the expiration date may be the same as the expiration date of the initial access identifier (or derived from the expiration date of the initial access identifier using any suitable method). After generating the intermediate account identifier, the first authorization computer 106 may also invoke the identifier conversion module 106-D3 to store the mapping of the initial access identifier (and associated fields, such as the user identifier) to the intermediate access identifier (and associated fields, such as the expiration date) in a record database.

[0114] In some embodiments, the intermediate account identifier may not be used to directly conduct access transactions, but may be a channel for provisioning a token to the communication device 102 and facilitating token-based transactions. For example, in some embodiments, the intermediate account identifier may not be used by someone to conduct a payment transaction. However, in other embodiments and as discussed below, the intermediate account identifier can be used to conduct transactions, for example, at an e-commerce website.

[0115] In step S606, the first authorization computer 106 may transmit the intermediate access identifier to the token provider computer 104. In some embodiments, the first authorization computer 106 may also transmit the expiration date associated with the intermediate access identifier to the token provider computer 104.

[0116] In some embodiments, after receiving the intermediate access identifier and the expiration date from the first authorization computer 106, the token provider computer 104 may engage in a message exchange process with the token requester 120 ( Figure 6 not shown in the figure, but depicted in Figure 7 steps S708 and S710). As Figure 6As depicted, instead of sending a registration confirmation message to the token requester application 120, the token provider computer 104 automatically proceeds with the registration process as described below.

[0117] In step S608, based at least in part on the intermediate access identifier received in step S606, the token provider computer 104 may transmit a token activation request message to the second authorization computer 108. In some embodiments, the token activation request message may include at least the initial access identifier. In some embodiments, any suitable information enabling the second authorization computer 108 to verify the token activation request message may be included in the message, including but not limited to the initial access identifier and / or the user identifier. In some embodiments, the second authorization computer 108 may use the initial access identifier to query the user 101 of the token requester computer 102 and authenticate the user using an ID&V process (e.g., via a one-time password or OTP) if necessary.

[0118] In step S610, the second authorization computer 108 may respond with a token activation response message, which is received by the token provider computer 104. The token activation response message may indicate whether the token activation request is approved (e.g., authorized) or rejected.

[0119] In steps S612 and S614, assuming the second authorization computer 108 agrees to provide a token to the token requester 120, the token provider computer 104 may retrieve a token that may have been previously stored by the token provisioning module 104-D3 from the token repository 130. As described above, the mapping between the token and the intermediate access identifier may also be stored in the token repository 130 along with the associated token.

[0120] In step S616, the token provider computer 104 may provide (e.g., transmit) a token activation notice to the second authorization computer 108.

[0121] In step S618, the token provider computer 104 may provide (provision) the token to the token requester 120. The token requester 120 may store the token in a memory, such as the secure memory 120C of the token requester computer 102. The token may be permanent, semi-permanent, or dynamic.

[0122] Figure 7 A block diagram 700 showing a system and a sequence of operations according to an embodiment of the present invention, showing a second provisioning process using manual provisioning. Similar to Figure 6 as depicted in Figure 7Shows a token requester computer 102 that can request a token from a token provider computer 104. In some embodiments, the token requester computer 102 can be a mobile communication device (e.g., a mobile phone). However, compared to Figure 6 , the token requester application 120 ("token requester") on the token provider computer 104 (e.g., a digital wallet) can be configured to receive input directly from the user 101 to initiate a provisioning process, rather than having an issuer application that pushes the initiation request and payload to the token requester. Similar to Figure 6 , the token requester 120 can communicate with the token provider computer 104. The token provider computer 104 can be associated with a token repository 130 (e.g., contain the token repository or communicate with the token repository). The token repository 130 can be a database that stores tokens and their associated true credentials or intermediate access identifiers. The token provider computer 104 can communicate with a first authorization computer 106 and a second authorization computer 108.

[0123] In the illustrated flow, at step S701, the token requester 120 can receive input from the user 101 to initiate a provisioning process. For example, the user 101 can enter credentials, such as an IBAN and a user identifier (e.g., an email address, a username, etc.), through an input element 102-E (e.g., a keyboard). The token requester 120 can receive the credentials using any suitable method. The entered credentials can be similar to Figure 6 the credentials encrypted within the payload transmitted from the issuer application 110 to the token requester 120 in

[0124] Steps S702 - S706 can be substantially the same as steps S602 - S606 of Figure 6 . The description thereof is incorporated herein and need not be repeated.

[0125] At step S708, as previously referenced in Figure 6As described as an optional step, the token provider computer 104 may send a registration confirmation message to the token requester 120. In some embodiments, after receiving the registration confirmation message, the token requester 120 may prompt the user 101 to agree to the token provisioning terms. In some embodiments, the registration confirmation message sent to the token requester 120 may contain an intermediate access identifier and an expiration date that can be stored on the token requester computer 102 and presented to the user 101. This can be done, for example, in cases where the issuer enables the user 101 to conduct transactions directly through the intermediate access identifier. However, in other embodiments, the intermediate access identifier is completely hidden from the user 101 (e.g., managed between the token provider computer 104 and the first authorization computer). In some embodiments, the registration confirmation message may also contain a reference number associated with the token registration session, and the token requester 120 may return the reference number to the token provider computer 104 to continue the registration process, as discussed below in step S710.

[0126] In step S710, after the user 101 agrees to the terms and / or selects other provisioning options presented by the token requester 120, the token requester 120 may transmit a registration confirmation response message containing the reference number and other appropriate information to the token provider computer 104, indicating that the user 101 will continue the provisioning process. After receiving the reference number back from the token requester computer 102, the token provider computer 104 may use the reference number to look up and retrieve information from the token library to continue the registration process (e.g., an initial access identifier, a user identifier, etc.).

[0127] Steps S712 - S722 may be substantially the same as Figure 6 steps S608 - S618 respectively. The description thereof is incorporated herein without repetition.

[0128] Figure 8 A block diagram 800 showing a system and a sequence of flow diagrams according to an embodiment of the present invention, showing the use of a token after a user communication device has been provisioned with the token. Figure 8 A system is shown, including a communication device 102 of the user 101, an access device 820 (e.g., a POS terminal), a transmission computer 840 (e.g., an acquirer computer), a processing computer 150 (e.g., in a payment processing network such as VisaNet), a first authorization computer 106, and a second authorization computer 108, all of which communicate with each other. A token library 130 may communicate with the processing computer 150.

[0129] Before step S802, the communication device 102 may be provisioned with a token, as described above with reference to Figure 6 and 7As described. At step S802, communication device 102 may interact with access device 820 according to any suitable token presentation mode (such as NFC communication). In other embodiments, such as for e-commerce transactions, communication device 102 may submit the token to a website associated with access device 820 over the Internet. During this process, access device 820 may receive other content associated with the token information (such as token expiration date, other token attributes).

[0130] At step S804, an authorization request message including the token may be generated by access device 820 and then transmitted to transmission computer 840.

[0131] At step S806, transmission computer 840 may transmit the authorization request message including the token to be received by processing computer 150. Processing server computer 150 may be in a payment processing network. The payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet TM . Such as VisaNet TM and other payment processing networks are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet TM Specifically includes the VIP system (Visa Integrated Payment System) for processing authorization requests and the BaseII system for performing clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the Internet.

[0132] At step S808, processing computer 150 may verify the authorization request message by executing verification module 150-D4. After successful verification, processing computer 150 may invoke token exchange module 150-D3, which may provide the token (such as through token provider computer 104) to token library 130.

[0133] At step S810, token exchange module 150-D3 may then retrieve (e.g., receive) the intermediate access identifier associated with the token from token library 130.

[0134] At step S812, processing computer 150 may provide (e.g., transmit) the intermediate access identifier to first authorization computer 106. In some embodiments, token exchange module 150-D3 may modify the authorization request message to include the intermediate access identifier and then transmit the modified authorization request message to first authorization computer 106 for further processing.

[0135] In step S814, the first authorization computer 106 may retrieve the initial access identifier based on the intermediate access identifier received from the processing computer 150. In some embodiments, the first authorization computer 106 may execute the authorization request transformation module 106-D5 to transform the intermediate access identifier into (e.g., substitute or additionally include) the initial access identifier in the modified authorization request message. The first authorization computer 106 may then transmit the modified message including the initial access identifier to the second authorization computer 108 for authorization of the transaction.

[0136] If approved (e.g., authorized), the second authorization computer 108 may transmit an authorization response message back to the access device 820 through the transmission computer 840, the processing computer 150, and the first authorization computer 106 ( Figure 8 step sequence not shown). In some embodiments, the authorization response message may be routed back to the access device 820 based on the initial access identifier, the intermediate access identifier, and / or the token. For example, after the first authorization computer 106 receives the authorization response message containing the initial access identifier, the first authorization computer 240 may switch the initial access identifier to the intermediate access identifier and then transmit the modified authorization response message to the processing computer 150. The processing computer 150 may then switch the intermediate access identifier to a token in the authorization response message (e.g., retrieve the token from the token library 130 based on a mapping stored in the token library 130). The processing computer 150 may then transmit the authorization response message to the transmission computer 840 based on the token attributes and other appropriate information in the authorization request message initially received in step S806. The authorization response message may be similarly routed from the transmission computer 840 to the access device 820 and / or the mobile device 102.

[0137] In some embodiments, the second authorization computer 108, the first authorization computer 106, the processing computer 150, and the transmission computer 840 may execute a settlement process to settle the transaction.

[0138] Figure 9 A block diagram 900 of a system according to an embodiment of the present invention is shown, showing the use of a token. Figure 9 A system including a communication device 102 of a user 101, an access device 920 (e.g., a gateway server), and a cloud service file server 930 is shown. The access device 920 may further communicate with other intermediate party computers between the access device 920 and the file server 930 (not shown), similar to Figure 8 as depicted (e.g., the processing computer 150, the first authorization computer 106, the second authorization computer 150, the token library 130).

[0139] In Figure 9 the mobile device 102 may be preconfigured with a token, as described above with reference toFigure 6 and 7 as described. The mobile device 102 may interact with the access device 920 according to any suitable token presentation mode (e.g., via the Internet). In this process, the access device 920 may receive the token and other information (e.g., expiration date). The access device 920 may then proceed with a series of steps to request authorization on behalf of the user 101 to access a remote file on the file server 930. In some embodiments, the steps may be substantially similar to Figure 8 steps S804 - S814 of

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

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

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

[0143] Unless clearly indicated to the contrary, the recitation of "a" or "the" is intended to mean "one or more".

[0144] All patents, patent applications, publications, and descriptions mentioned above are hereby incorporated by reference in their entirety for all purposes. It is not admitted that they are prior art.

Claims

1. A method for facilitating the provisioning of a token to a token requester computer, the method comprising: Receiving, by a token provider computer, a token request message from the token requester computer, the token request message including an initial access identifier; Transmitting, by the token provider computer, the initial access identifier to a first authorization computer; Receiving, by the token provider computer, an intermediate access identifier from the first authorization computer, the intermediate access identifier including a virtual primary account number that is not operable for direct transactions and having a different format from the initial access identifier; Transmitting, by the token provider computer, a token activation request message to a second authorization computer at least in part based on the intermediate access identifier; Receiving, by the token provider computer, a token activation response message from the second authorization computer, the token activation response message indicating whether the token activation request is approved or rejected; Retrieving, in the case where the token activation request is approved by the second authorization computer, the token from a token library of the token provider computer; Storing, by the token provider computer, a mapping between the intermediate access identifier and the token based on the token activation response message; And Providing, by the token provider computer, the token to the token requester computer.

2. The method according to claim 1, wherein the initial access identifier includes an alphanumeric value corresponding to an account identifier of an account.

3. The method according to claim 2, wherein transmitting the initial access identifier further includes transmitting a user identifier of an authorized user associated with the account.

4. The method according to claim 1, wherein providing the token to the token requester computer further includes retrieving the token from the token library.

5. The method according to claim 1, wherein the provided token is operable to be stored by the token requester computer for future use in transactions.

6. The method according to claim 1, wherein the token provider computer provides the token to the token requester computer at least in part based on a successful result of an identification and verification process.

7. A token provider computer, comprising: 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 token request message from a token requester computer, the token request message including an initial access identifier; Transmitting the initial access identifier to a first authorization computer; Receiving an intermediate access identifier from the first authorization computer, the intermediate access identifier including a virtual primary account number that is not operable for direct transactions and having a different format from the initial access identifier; Transmitting a token activation request message to a second authorization computer at least in part based on the intermediate access identifier; Receiving a token activation response message from the second authorization computer, the token activation response message indicating whether the token activation request is approved or rejected; In the case where the token activation request is approved by the second authorization computer, retrieve a token from the token library of the token provider computer; Based on the token activation response message, store, by the token provider computer, the mapping between the intermediate access identifier and the token; and Provide the token to the token requester computer.

8. The token provider computer according to claim 7, wherein the initial access identifier includes an alphanumeric value corresponding to an account identifier of an account.

9. The token provider computer according to claim 8, wherein transmitting the initial access identifier further includes transmitting a user identifier of an authorized user associated with the account.

10. The token provider computer according to claim 7, wherein the token activation request message includes the initial access identifier.

11. The token provider computer according to claim 7, wherein the method further includes: After receiving the intermediate access identifier, transmit, to the token requester computer, a registration confirmation message including a reference number associated with the intermediate access identifier; And Receive, from the token requester computer, a registration confirmation reply message including the reference number, wherein the token provider computer retrieves the intermediate access identifier using the reference number.

12. The token provider computer according to claim 11, wherein the registration confirmation message further includes the intermediate access identifier.

13. The token provider computer according to claim 7, wherein the intermediate access identifier is associated with an expiration date and / or a CVV2 value, and the expiration date matches a second expiration date associated with the initial access identifier.

14. The token provider computer according to claim 7, wherein the token provider computer provides the token to the token requester computer at least partially based on a successful result of an identification and verification process.

15. The token provider computer according to claim 14, wherein the identification and verification process is performed by the second authorization computer and includes verifying that a user of the token requester computer is authorized to receive the token.

16. A method for facilitating the provisioning of a token to a token requester computer, the method including: Receive, by a first authorization computer, an initial access identifier from a token provider computer; Obtain, by the first authorization computer, at least partially based on the initial access identifier, an intermediate access identifier, the intermediate access identifier including a virtual primary account number that cannot be used directly for transactions and having a format different from that of the initial access identifier; Store, by the first authorization computer, the mapping between the initial access identifier and the intermediate access identifier; And Transmit, by the first authorization computer, the intermediate access identifier to the token provider computer, wherein the token provider computer transmits, at least partially based on the intermediate access identifier, a token activation request message to a second authorization computer to authorize the token to be provisioned to the token requester computer.

17. The method according to claim 16, wherein the initial access identifier comprises an alphanumeric value corresponding to an account identifier of the account.

18. The method according to claim 17, wherein receiving the initial access identifier further comprises receiving a user identifier of an authorized user associated with the account.

19. The method according to claim 18, wherein obtaining the intermediate access identifier comprises generating the virtual primary account number associated with the authorized user and the account.

20. The method according to claim 18, further comprising: storing, by the first authorized computer, the mapping between the user identifier, the initial access identifier, and the intermediate access identifier.

21. The method according to claim 16, wherein the intermediate access identifier is associated with an expiration date and / or a CVV2 value.

22. The method according to claim 21, wherein the expiration date does not match a second expiration date associated with the initial access identifier.

23. A first authorized computer, comprising: a processor; and a non-transitory computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement a method for facilitating the provisioning of a token to a token requester, the method comprising: receiving, from a token provider computer, an initial access identifier; obtaining, at least in part based on the initial access identifier, an intermediate access identifier, the intermediate access identifier comprising a virtual primary account number that cannot be operated to directly conduct a transaction and having a different format from the initial access identifier; storing, by the first authorized computer, the mapping between the initial access identifier and the intermediate access identifier; and transmitting the intermediate access identifier to the token provider computer, wherein the token provider computer transmits a token activation request message to a second authorized computer, at least in part based on the intermediate access identifier, to authorize the token to be provisioned to the token requester computer.

24. The first authorized computer according to claim 23, wherein the initial access identifier comprises an alphanumeric value corresponding to an account identifier of the account.

25. The first authorized computer according to claim 24, wherein receiving the initial access identifier further comprises receiving a user identifier of an authorized user associated with the account.

26. The first authorized computer according to claim 25, wherein obtaining the intermediate access identifier comprises generating the virtual primary account number associated with the authorized user and the account.

27. The first authorized computer according to claim 25, further comprising: storing, by the first authorized computer, the mapping between the user identifier, the initial access identifier, and the intermediate access identifier.

28. The first authorized computer according to claim 27, wherein the method further comprises: after the token is provisioned to the token requester computer, receiving, from a processing computer, the intermediate access identifier, the intermediate access identifier being included within an authorization request message; Retrieve the initial access identifier at least partially based on the mapping; Modify the authorization request message by including the initial access identifier; And Transmit the modified authorization request message to the second authorization computer to authorize the transaction.

29. The first authorization computer according to claim 23, wherein the intermediate access identifier is associated with an expiration date and / or a CVV2 value.

30. The first authorization computer according to claim 29, wherein the expiration date is not associated with a second expiration date associated with the initial access identifier.

31. A method for facilitating the provisioning of a token to a token requester computer, the method comprising: Receiving, by a processing computer, an authorization request message including the token; Providing, by the processing computer, the token to a token provider computer in a transaction; Receiving, by the processing computer, an intermediate access identifier associated with the token; Modifying, by the processing computer, the authorization request message to include the intermediate access identifier; And Transmitting, by the processing computer, the authorization request message including the intermediate access identifier to a first authorization computer, wherein the first authorization computer modifies the authorization request message to include an initial access identifier associated with the intermediate access identifier, stores a mapping between the initial access identifier and the intermediate access identifier, and transmits the authorization request message with the initial access identifier to a second authorization computer to authorize the transaction, wherein the intermediate access identifier includes a virtual primary account number that cannot be used directly for transactions and has a different format from the initial access identifier.

32. The method according to claim 31, wherein the initial access identifier includes an alphanumeric value corresponding to an identifier of a resource.

33. The method according to claim 32, wherein the resource corresponds to a file on a remote file server.

34. The method according to claim 31, wherein the intermediate access identifier is associated with an expiration date.

35. The method according to claim 31, the method further comprising: After the second authorization computer authorizes the transaction, receiving, by the processing computer, an authorization response message from the first authorization computer, the authorization response message including the intermediate access identifier, and the first authorization computer has replaced the initial access identifier included in the original authorization response message received from the second authorization computer with the intermediate access identifier; Retrieving, by the processing computer, the token from the token provider computer at least partially based on the intermediate access identifier; Including, by the processing computer, the token in a modified authorization response message; And Transmitting, by the processing computer, the modified authorization response message to an access device.

36. The method according to claim 31, wherein the intermediate access identifier is received from the token provider computer, and the token provider computer maintains a second mapping from the token to the intermediate access identifier.

37. A processing computer, comprising: 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 for facilitating the provisioning of a token to a token requester computer, the method including: Receiving an authorization request message including the token; Providing the token to a token provider computer in a transaction; Receiving an intermediate access identifier associated with the token; Modifying the authorization request message to include the intermediate access identifier; and Transmitting the authorization request message including the intermediate access identifier to a first authorization computer, wherein the first authorization computer modifies the authorization request message to include an initial access identifier associated with the intermediate access identifier, stores a mapping between the initial access identifier and the intermediate access identifier, and transmits the authorization request message with the initial access identifier to a second authorization computer to authorize the transaction, wherein the intermediate access identifier includes a virtual primary account number that is not operable for direct transactions and has a different format from the initial access identifier.

38. The processing computer according to claim 37, wherein the initial access identifier includes an alphanumeric value corresponding to an identifier of a resource.

39. The processing computer according to claim 38, wherein the resource corresponds to a file on a remote file server.

40. The processing computer according to claim 37, wherein the intermediate access identifier is associated with an expiration date.

41. The processing computer according to claim 37, wherein the method further includes: After the second authorization computer authorizes the transaction, receiving, by the processing computer, an authorization response message from the first authorization computer, the authorization response message including the intermediate access identifier, the first authorization computer having replaced the initial access identifier included in the original authorization response message received from the second authorization computer with the intermediate access identifier; Retrieving, by the processing computer, the token from the token provider computer at least partially based on the intermediate access identifier; Including, by the processing computer, the token in a modified authorization response message; And Transmitting, by the processing computer, the modified authorization response message to an access device.

42. The processing computer according to claim 37, wherein the intermediate access identifier is received from the token provider computer, and the token provider computer maintains a second mapping of the token to the intermediate access identifier.

Images