Efficient and secure token provisioning

Abstract

A registration data packet including device information of the user and resource provider information is received by the processing computer from the authorized entity computer. The processing computer generates a token request push packet including user information and the device information, and transmits the token request push packet to a user device. The user device then transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information. A provisioning request generated based on the request to initiate provisioning of the token is received by the processing computer from the resource provider computer and transmitted to a token serving computer. The supply request comprises the token request to push the data packet. Upon receiving the provisioning request, the token service computer determines token data using the device information and the user information, and provides the token data to the resource provider computer.

Description

[0001] Cross-reference to related applications

[0002] This application is a PCT application claiming priority to U.S. Provisional Application No. 63 / 342,839, filed on May 17, 2022, the entirety of which is incorporated herein by reference. Background Art

[0003] Users can use tokens as an alternative to credentials to access services or products. During transactions, tokens can be exchanged for real credentials (e.g., primary account number (PAN) or some other payment information) that can be used in the transaction authorization process. Using tokens ensures higher security for sensitive information.

[0004] However, tokenization systems cannot keep up with the tokenization demands from users and / or resource providers. The number of tokens that have been generated in recent years is in the billions, and this trend is expected to continue.

[0005] Many resource providers rely on associated service providers to implement tokenization and transaction processing. Due to this dependency, if a resource provider wants to support a new feature, such as push provisioning, the resource provider cannot do so until the service provider enables technical changes to support the new feature. However, the infrastructure required to implement the new feature involves additional resources, so the service provider may be reluctant to make the required changes. This creates barriers for users and resource providers and creates bottlenecks in the tokenization process.

[0006] Embodiments of the present disclosure address the above-referenced problems and other problems individually and collectively. Summary of the invention

[0007] According to one aspect of the embodiment, a method is provided. The method includes: receiving a registration data packet including a user's device information and resource provider information from an authorization entity computer by a processing computer; generating a token request push data packet including the user information and the device information by the processing computer; transmitting the token request push data packet to a user device by the processing computer, wherein the user device subsequently transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information; receiving a provisioning request generated based on the request to initiate token provisioning from the resource provider computer by the processing computer; and transmitting a provisioning request including the token request push data packet to a token service computer by the processing computer, wherein upon receiving the provisioning request, the token service computer determines token data using the device information and user information from the token request push data packet, and provides the token data to the resource provider computer.

[0008] According to one aspect of the embodiment, a processing computer is provided. The processing computer includes a processor; and a computer-readable medium including code, which, when executed by the processor, causes the processor to perform a method including the following items: receiving a registration data packet including a user's device information and resource provider information from an authorization entity computer; generating a token request push data packet including user information and device information; transmitting the token request push data packet to a user device, wherein the user device then transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information; receiving a provisioning request generated based on the request to initiate token provisioning from the resource provider computer; and transmitting a provisioning request including a token request push data packet to a token service computer, wherein upon receiving the provisioning request, the token service computer determines token data using the device information and user information from the token request push data packet, and provides the token data to the resource provider computer.

[0009] According to one aspect of the embodiment, a method is provided. The method includes: a user device operated by a user transmits the user's device information and the resource provider information of the resource provider to an authorization entity computer, wherein the authorization entity computer subsequently generates a registration data packet including the device information and the resource provider information and transmits it to a processing computer; a token request push data packet including the user information and the device information is received by the user device; and in response to receiving the token request push data packet, the user device transmits a request for initiating token supply to a resource provider computer associated with the resource provider information, wherein the resource provider computer subsequently transmits a supply request generated based on the request for initiating token supply to the processing computer, wherein the processing computer transmits a supply request including the token request push data packet to a token service computer, and wherein upon receiving the supply request, the token service computer generates token data using the device information and user information from the token request push data packet, and provides the token data to the resource provider computer.

[0010] A better understanding of the nature and advantages of embodiments of the present invention may be obtained by reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A system and swim-lane flow chart illustrating a method according to at least one embodiment are presented.

[0012] Figure 2 A simplified block diagram of a system in accordance with at least one embodiment is presented.

[0013] Figure 3 A simplified block diagram of a system in accordance with at least one embodiment is presented.

[0014] Figure 4 A simplified block diagram of a system in accordance with at least one embodiment is presented.

[0015] Figure 5 A simplified block diagram of a user device is shown in accordance with at least one embodiment.

[0016] Figure 6 A simplified block diagram of a token service computer is shown in accordance with at least one embodiment.

[0017] Figure 7 A simplified block diagram of a processing computer is shown in accordance with at least one embodiment. DETAILED DESCRIPTION

[0018] Before discussing the embodiments of the present disclosure, some terms may be described in further detail.

[0019] An "application" may be computer code or other data stored on a computer-readable medium (eg, a memory element or a secure element) that is executable by a processor to perform tasks.

[0020] "Access device" can be any suitable device that provides access to a resource. The access device can take any suitable form. Some examples of access devices include vending machines, self-service machines, POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), Web servers, etc. The access device can use any suitable contact or contactless operation mode to transmit or receive data from or associated with a user's mobile communication device. In some embodiments, the access device may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operation mode. For example, an exemplary reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader for interacting with a payment device and / or a mobile communication device.

[0021] "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 for a payment account. Account information may include PAN, payment token, expiration date, card verification value (e.g., CVV, CVV2), dynamic card verification value (dCVV, dCVV2), an identifier of the issuer holding the account, etc. In other embodiments, the access data may include data that can be used to access a location or access secure data. Such information may be ticket information for an event, data for accessing a building, transit ticket information, passwords, biometrics, or other credentials for accessing secure data, etc.

[0022] An "authorized entity" may be an entity that authorizes a request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, etc. An authorized entity may operate an authorized entity computer.

[0023] An "issuer" may refer to a commercial entity (eg, a bank) that issues and optionally maintains a user account. An issuer may also issue payment credentials to a consumer that may be stored on a user device.

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

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

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

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

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

[0029] A "user device" may be a device operated by a user. Examples of user devices may include mobile phones, smart phones, cards, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, thin client devices, tablet PCs, etc. In addition, the user device may be any type of wearable technology device, such as a watch, headphones, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. Examples of input sensors include accelerometers, cameras, microphones, etc. The user input obtained by the input sensor may come from a variety of data input types, including but not limited to audio data, visual data, or biometric data. The user device may include any electronic device that can be operated by a user, and the electronic device may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (e.g., 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).

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

[0031] A "resource provider computer" may be a computer operated by a resource provider. An example of a resource provider computer may be an access device.

[0032] A "credential" may be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters that may be presented or contained in any object or document that may serve as confirmation.

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

[0034] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or 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 bank account number, PAN (primary account number or "account number"), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. CVV2 is generally understood to be a static verification value associated with a payment device. The CVV2 value is usually visible to the user (e.g., a consumer), while the CVV and dCVV values ​​are usually embedded in a memory or authorization request message, which is not easily known to the user (although they are known to the issuer and payment processor). Payment credentials may be any information that identifies a payment account or is associated with a payment account. Payment credentials may be provided to make payments from a payment account. Payment credentials may also include username, expiration date, gift card number or code, and any other suitable information.

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

[0036] A "payment token" may include an identifier of a payment account that is a replacement for an account identifier such as a bank account number, a primary account number (PAN), and / or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a replacement for an original account identifier. For example, the token "4900 00000000 0001" may be used in place of the PAN "41470900 0000 1234". In some embodiments, the token may be "format-retained" and may have a numeric format that conforms to account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token may be used in place of a PAN to initiate, authorize, process, or settle a payment transaction, or to represent an original credential in other systems that would normally provide the original credential. In some embodiments, a token value may be generated such that recovery of the original PAN or other account identifier from the token value may not be computationally possible. Furthermore, 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.

[0037] "Tokenization" is the process of replacing sensitive data with alternative data. For example, real payment credentials (e.g., bank account numbers, primary account numbers (PAN), etc.) can be tokenized by replacing real account identifiers with alternative numbers that can be associated with the real credentials. In addition, tokenization can be applied to any other information, thereby replacing implicit information with a token. "Token exchange" or "de-tokenization" can be the process of recovering data that was replaced during tokenization. For example, token exchange can include replacing a payment token with a primary account number (PAN) associated with the payment token. In addition, de-tokenization or token exchange can be applied to any other information to retrieve the replaced information from the token. In some embodiments, token exchange can be achieved via a transaction message (such as an ISO message), an application programming interface (API), or another type of web interface (e.g., a web request).

[0038] A "token service computer" may include a system that services tokens. In some embodiments, a token service computer may facilitate requesting, determining (e.g., generating) and / or issuing tokens, and maintaining an established mapping of tokens to payment credentials such as bank account numbers or primary account numbers (PANs) in a repository (e.g., a token library). In some embodiments, a token service computer may establish a token assurance level for a given token to indicate a confidence level in the binding of the token to the PAN. The token service computer may include or communicate with a token library that stores generated tokens. The token service computer may support token processing for payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PAN.

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

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

[0041] A "token provisioning message" (e.g., a provisioning message) may be an electronic message for requesting a token. The token request message may include information that may be used to identify a payment account or digital wallet, and / or information for generating a payment token. For example, the token request message may include payment credentials, mobile communication device identification information (e.g., a telephone number or MSISDN), a digital wallet identifier, information identifying a token service provider, a merchant identifier, a ciphertext, and / or any other suitable information. The information included in the token request message may be encrypted (e.g., using an issuer-specific key). In some embodiments, the token request message may include a flag or other indicator specifying that the message is a token request message.

[0042] A "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 is approved or denied. The token response message may also include a payment token, mobile communication device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a token service provider, a merchant identifier, a ciphertext, and / or any other suitable information. The information included in the token response message may be encrypted (e.g., using an issuer-specific key). In some embodiments, the token response message may include a flag or other indicator specifying that the message is a token response message.

[0043] An "authorization request message" may be a message requesting permission to interact. For example, an authorization request message may include an electronic message sent to a payment processing network and / or an issuer associated with a payment credential to request authorization for a transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information", including, by way of example only: service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant identifier, merchant location, and any other information that may be used to determine whether to identify and / or authorize a transaction.

[0044] An "authorization response message" may be an electronic message reply to an authorization request message. In some embodiments, the authorization response message may be generated by the issuing financial institution or a payment processing network. By way of example only, the authorization response message may include one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the issuing bank returns to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (directly or via the payment processing network) indicating that the transaction is approved. The code may serve as evidence of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

[0045] A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a web server. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers. A server computer may be a cloud computer.

[0046] Figure 1 A swim-lane flow chart illustrating a method according to an embodiment is shown. Figure 2 is a simplified block diagram of a token provisioning system 101 according to some embodiments.

[0047] Figure 1 and 2A user device 100, an authorization entity computer 102, a processing computer 104, a resource provider computer 106, a service provider computer 108, and a token service computer 110 are shown. In at least one example, the authorization entity computer 102 may be operated by or on behalf of an issuer (e.g., a financial institution associated with a user's payment credentials). In some embodiments, the resource provider computer 106 may be operated by a resource provider (e.g., a merchant) that conducts recurring transactions. The service provider computer 108 may have a relationship with the resource provider computer 106. The processing computer 104 may communicate with the authorization entity computer 102 and the token service computer 110 to authorize activation and creation of tokens.

[0048] Figure 1 and 2 Each of the entities shown may communicate via any suitable communication channel or communication network. Suitable communication networks may be any one and / or a combination of: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operating mission as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, wireless application protocol (WAP), I-mode, etc.); etc. Secure communication protocols such as, but not limited to, file transfer protocol (FTP), hypertext transfer protocol (HTTP), secure hypertext transfer protocol (HTTPS), secure socket layer (SSL), ISO (e.g., ISO 8583), etc. may be used to transmit messages between computers, networks, and devices.

[0049] However, as described below, in some instances, some entities may not have a direct communication connection, such as a communication relationship. For example, in some embodiments, a resource provider may not have a relationship with a token provider.

[0050] The user device 100 may be configured to receive input from a user instructing the user device 100 to initiate a token provisioning process with the token service computer 110 to provision a token. In some embodiments, the user device 100 may be a user's mobile communication device that receives instructions from the user to provision a token to the mobile communication device.

[0051] In some embodiments, the user device 100 may execute a token requestor application, such as a digital wallet, which may be responsible for requesting, storing and / or managing one or more tokens received by the user device 100. In some embodiments, the user device 100 may also execute an application, such as an authorization entity application 202, such as a mobile banking application, a cloud service application, a public transportation account application, etc. As an example, the authorization entity application 202 may be provided as a graphical user interface (GUI) on a display of the user device 100.

[0052] The authorization entity application 202 may be responsible for transmitting a registration request to the authorization entity computer 102 to initiate a provisioning process with the token service computer 110 .

[0053] The processing computer 104 and the token service computer 110 may be computers affiliated with a token provider. The processing computer 104 and the token service computer 110 may facilitate requesting, determining (eg, generating), and / or issuing tokens.

[0054] For example, the processing computer 104 may receive a registration request message from the authorization entity computer 102. The processing computer 104 may then initiate processing and, as a result of the processing, generate a token request push packet. The processing computer 104 may transmit the token request push packet to the user device 100, thereby invoking a token requester (TR) application 204 on the user device 100. As an example, the TR application 204 may be displayed as a GUI on a display of the user device 100. In some embodiments, the TR application 204 may communicate with the user device 100 to request a token. Figure 2 The resource provider application 206 in the example embodiment may be the same as the resource provider application 206 in the example embodiment, or it may be a different application that works in conjunction with the resource provider application 206.

[0055] The TR application 204 can facilitate the authentication of the user by the resource provider computer 106. Successful authentication causes the resource provider computer 106 to transmit a provisioning request to the processing computer 104. The processing computer 104 can then directly request the issuance of a token for the user by communicating with the token service computer 110. The token service computer 110 can activate the token and notify the service provider computer 108 associated with the resource provider computer 106 of the token creation. The service provider computer 108 can then obtain the token data from the token service computer 110 and provide the token data to the resource provider computer 106. The token data may include a token and / or a token reference identifier.

[0056] The described techniques can provision tokens for users and resource providers without involving a service provider operating the service provider computer 108. After provisioning a token, the token data is released to the service provider computer 108, which can provide the token data to the resource provider computer 106.

[0057] According to the described techniques, a service provider computer of a service provider associated with a resource provider operating a resource provider computer can be used to process a request to provision a token to a user. In this way, the described techniques overcome the problems of the related art, in which provisioning requests from a resource provider computer are routed to a token service computer via a service provider computer as an intermediary. In addition, the described techniques improve the functionality of a computer system by reducing computing resources and network traffic.

[0058] Continue to refer Figure 1 and 2 At operation S100, a user operating the user device 100 may transmit a login request to the authorization entity computer 102 to log in to a user account managed by the authorization entity computer 102. For example, the user may access an application (e.g., the authorization entity application 202) installed on the user device 100, or access a website to transmit a login request. The login request may include authentication information, and the authentication information includes at least one of a user name, a password, and an account number associated with the user. The authorization entity computer 102 may receive the login request, allow the user to log in, authenticate the user based on the authentication information (e.g., the login credentials), and allow the user to log in and access the user account.

[0059] After the user logs into a user account managed by the authorization entity computer 102, the user may select a primary account number (PAN) by selecting a card (e.g., a debit card or a credit card), and may select a resource provider, for example, from a list of resource providers using the user device 100. The selected resource provider may be an entity to which the user wishes to provision a token associated with the selected primary account.

[0060] At operation S102, the user device 100 may transmit a data packet to the authorization entity computer 102. The data packet may include information about the account selected by the user and the resource provider selected by the user, such as the name of the primary account number and the merchant.

[0061] Based on the data packet from the user device 100 including information about the user-selected primary account and the user-selected resource provider, the authorization entity computer 102 may generate an enrollment data packet for the authenticated user.

[0062] In some embodiments, the registration data packet may include information received in a data packet from the user device 100. For example, the registration data packet may include the user's device information (e.g., a PAN or primary account number, such as a credit, debit, or prepaid account number) and information related to the user's personal information (e.g., the user's email, phone number, and / or address). The registration data packet may further include resource provider information, such as a merchant's name, merchant identifier, etc.

[0063] At operation S104, the authorization entity computer 102 may transmit a registration data packet to the processing computer 104. The authorization entity computer 104 may select between a proxy or an API.

[0064] At operation S106, after receiving the registration data packet from the authorization entity computer 102, the processing computer 104 can determine the type of resource provider based on the resource provider information in the registration data packet. For example, the processing computer 104 can determine whether the resource provider is an on behalf of (OBO) resource provider or a non-OBO resource provider. An OBO resource provider can have a relationship with a service provider that operates the service provider computer 108, but has no relationship with the entity that supplies the token (e.g., the token service computer 110). A non-OBO resource provider can have a relationship with a service provider that operates the service provider computer 108, and also has a relationship with the entity that supplies the token (e.g., the token service computer 110).

[0065] If at operation S106, the processing computer 104 determines that the resource provider is an OBO resource provider, the method proceeds to operation S108, where the processing computer 104 generates a token request push packet formatted for the OBO resource provider. Otherwise, the method proceeds to operation S110, where the processing computer 104 generates a token request push packet formatted for a non-OBO resource provider. The token request push packet includes information including user information and device information, which can be generated differently for OBO resource providers and non-OBO resource providers, as described below.

[0066] In the case of an OBO resource provider, in operation S108, the processing computer 104 may verify the payment information of the user received in the registration data packet. For example, the processing computer 104 may check with the authorized entity computer 102 to determine whether the payment information (e.g., a primary account number) is valid payment information and is not subject to any risk of fraudulent activity. The processing computer 104 may then generate a token request push data packet formatted for the OBO resource provider. For example, the processing computer 104 may encrypt the user's personal information and / or payment information. The user's personal information included in the token request push data packet formatted for the OBO resource provider may include at least some of the personal information provided in the registration data packet. The user's payment information included in the token request push data packet formatted for the OBO resource provider may include at least some of the payment information provided in the registration data packet, for example, the last four digits of the PAN and the expiration date.

[0067] In the case of a non-OBO resource provider, in operation S110, the processing computer 104 can verify the payment information of the user received in the registration data packet. For example, the processing computer 104 can check with the authorized entity computer 102 to determine whether the payment information (e.g., a primary account number) is valid payment information and is not subject to any risk of fraudulent activity. The processing computer 104 can then generate a token request push data packet formatted for the non-OBO resource provider. For example, the processing computer 104 can encrypt the user's personal information and / or payment information. The user's personal information included in the token request push data packet formatted for the non-OBO resource provider can include at least some of the personal information provided in the registration data packet.

[0068] The user's payment information included in the token request push data packet formatted for the non-OBO resource provider may be different from the payment information included in the token request push data packet formatted for the OBO resource provider. For example, the payment information provided in the token request push data packet formatted for the non-OBO resource provider may include a reference identifier corresponding to the user's primary account. For example, the non-OBO resource provider may use the reference identifier of the user's primary account so that the non-OBO resource provider cannot access the primary account.

[0069] The processing computer 104 may store the token request push data packet for the user and the user association information.

[0070] At operation S112, after generating the token request push data packet, the processing computer 104 may transmit the token request push data packet to the user device 100. When the user device 100 receives the token request push data packet, the user device 100 may call the TR application 204 on the user device 100. In some embodiments, the TR application 204 may include or access a resource provider application 206 associated with a resource provider selected by the user. As described above, in some embodiments, the TR application 204 is the same as the resource provider application. The resource provider application 206 may provide a GUI on the display of the user device 100. For example, receiving the token request push data packet by the user device 100 may call the resource provider application 206 on the user device 100.

[0071] At operation S114, after invoking the TR application 204, the user may access the resource provider application 206 managed by the resource provider computer 106. In response to the user device 100 accessing the resource provider application 206, the resource provider computer 106 may initiate an authentication process for the user with respect to the user device 100. In some embodiments, the resource provider computer 106 authenticates the user via the resource provider application 206, and based on the authenticated user, transmits a provisioning request to the processing computer 104, the provisioning request notifying the processing computer 104 that the resource provider computer 106 has authorized the registration of the user.

[0072] For example, in response to a user accessing the resource provider application 206, the resource provider computer 106 may control the authentication process such that the authentication process is performed differently for new users and returning users according to operations S116 and S118, respectively.

[0073] In operation S116, after accessing the resource provider application 206, the new user may create an account using the resource provider application 206. For example, the new user may enter a username and password and other user information (e.g., name, address, phone number, email, etc.) into the resource provider application 206 to register a resource provider account.

[0074] In operation S118, after accessing the resource provider application 206, the returning user may access an existing resource provider account in the resource provider application 206. For example, the returning user may log in to the resource provider account using authentication information (eg, username and password).

[0075] After the new user successfully completes the registration or the returning user successfully logs in, the resource provider computer 106 successfully completes the authentication process of the user. The user can submit a request to supply a token associated with the user's primary account to the resource provider application 206 via the user device 100. In some embodiments, the request to supply a token to the resource provider application 206 can be a supply request to issue a token. In other embodiments, the request to supply a token to the resource provider application 206 can be a request to initiate a supply request to issue a token.

[0076] At operation 119, after receiving a request for a supply token from the user device 100, the resource provider computer 106 may generate a supply request. For example, the resource provider computer 106 may access user information to automatically fill in the fields of the supply request. The resource provider computer 106 may access user information entered during the registration phase and stored in the user account to automatically fill in the supply request. However, this is not intended to be limiting. In some embodiments, the resource provider computer 106 may request the user to manually enter the user information into the fields of the supply request.

[0077] At operation S120 , the resource provider computer 106 may transmit a provisioning request including the user information to the processing computer 104 .

[0078] At operation S121, after receiving the provisioning request from the resource provider computer 106, the processing computer 104 may append additional data to the provisioning request to update the provisioning request. For example, the processing computer 104 may retrieve a token request push data packet corresponding to the user based on the user information included in the provisioning request. Then, the processing computer 104 may append the data included in the token request push data packet to the provisioning request. For example, the processing computer 104 may append device information including the primary account number from the token request push data packet to the provisioning request. In some embodiments, the processing computer 104 may also append the user information from the token request push data packet to the provisioning request.

[0079] At operation S122 , the processing computer 104 may transmit the updated provisioning request to the token service computer 110 .

[0080] At operation S123, after receiving the provisioning request from the processing computer 104, the token service computer 110 may generate or obtain a token, such as determining a token. For example, the token service computer 110 may tokenize the data in the token request push data packet to obtain the token. The token may be retrieved from a database of pre-existing tokens, or may be generated (e.g., mathematically) from the PAN.

[0081] After determining the token, the token service computer 110 can then generate a token creation notification. The token creation notification may include token information. The token information may include a supply request identifier, such as an identifier that uniquely identifies the supply request received by the token service computer 110 from the processing computer 104 and / or a token reference identifier that identifies the token determined by the user. In some embodiments, the resource provider computer 106 can provide the supply request identifier to the supply request when creating the supply request. However, this is not intended to be restrictive. For example, the supply request identifier can be provided to the supply request by the processing computer 104 or the token service computer 110.

[0082] At operation S124 , the token service computer 110 may transmit a token creation notification to the service provider computer 108 .

[0083] At operation S126, after receiving the token creation notification from the token service computer 110, the service provider computer 108 may transmit a request to provide token data including a token to the token service computer 110. For example, the request to provide token data may include token information from the token creation notification, such as a provisioning request identifier and / or a token reference identifier.

[0084] At operation S127, the token service computer 110 may transmit the token data to the service provider computer 108. The token data may include the token, a token reference identifier, a token expiration date, and / or a token password.

[0085] However, the above description is not intended to be limiting. In some embodiments, the service provider computer 108 can retrieve token data from the token service computer 110 using an API upon receiving a token creation notification from the token service computer 110 .

[0086] At operation S128 , after retrieving or receiving the token data from the token service computer 110 , the service provider computer 108 may transmit the token data to the resource provider computer 106 .

[0087] In some embodiments, because the service provider computer 108 is not actively participating in the token provisioning process, the token service computer 110 may determine a token formatted for the existing environment of the service provider computer 108 .

[0088] At operation S130, after receiving the token data from the service provider computer 108, the resource provider computer 106 may store the token data in the storage device 210 for future use, such as for future interactions or transactions with the user. Figure 2 As shown, the storage device 210 may store multiple tokens for the same or at least partially different users and / or token data associated with the tokens.

[0089] However, the above description is not intended to be limiting. In some embodiments, the resource provider computer 106 can receive token data from the token service computer 110.

[0090] At operation S131, the resource provider computer 106 may transmit a notification indicating successful registration of the user, such as a token provisioning completion notification, to the authorization entity computer 102. The token provisioning completion notification provides an indication that the user's token data was successfully provided to and received by the resource provider computer 106.

[0091] At operation S132 , the authorization entity computer 102 may transmit a successful registration notification (eg, a token provisioning completion notification) to the user device 100 .

[0092] However, the above description is not intended to be limiting. In some embodiments, the resource provider computer 106 may transmit a successful registration notification to the user device 100, or to both the authorization entity computer 102 and the user device 100.

[0093] Figure 3 A block diagram of a transaction processing system 300 is shown, which may be a system that may utilize tokens provisioned to user devices as described above. Figure 3 A user 207 is shown who can operate a user device 100 (e.g., a mobile communication device). The user 207 can use the user device 100 to make payments for goods or services at a resource provider operating a resource provider computer 106, which stores token data as described above. The resource provider can communicate with the authorization entity computer 102 via an acquirer computer 240 and a payment processing network 250. Similar to the token service computer 110 described above, the token service computer 242 can communicate with the payment processing network 250. The payment processing network 250 can include the processing computer 104.

[0094] Payment processing network 250 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. Exemplary payment processing networks may include VisaNet TM For example, VisaNet TM Payment processing networks such as VisaNet can process credit card transactions, debit card transactions, transactions involving financial accounts, and other types of commercial transactions. TM , in particular, including the VIP system (Visa Integrated Payment System) that processes authorization requests and the Base II system that performs clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet. In some embodiments, the processing computer 104 and / or the token service computer 110 can be part of the payment processing network 250.

[0095] In a typical payment transaction flow, a user 207 uses a resource provider computer 106 to initiate a transaction with a resource provider operating the resource provider computer 106, or the resource provider computer 106 may initiate a transaction on behalf of the user 207 (e.g., as in a recurring payment transaction). The resource provider computer 106 may then generate an authorization request message with the stored token and additional transaction information (e.g., transaction amount, merchant-specific information, etc.), and may electronically transmit the authorization request message to the acquirer computer 240. The acquirer computer 240 may then receive, process, and forward the authorization request message to the payment processing network 250 for authorization.

[0096] Once the payment processing network 250 obtains the token, the payment processing network 250 may communicate with the token services computer 242 to obtain the credentials associated with the token.

[0097] For example, before a credit or debit card transaction occurs, the payment processing network 250 has established an agreement with each issuer regarding how transactions with the issuer will be authorized. In some cases, such as when the transaction amount is below a threshold, the payment processing network 250 may be configured to authorize the transaction based on the information it has about the user's account without generating and transmitting an authorization request message to the authorization entity computer 102 (e.g., an issuer computer). In other cases, such as when the transaction amount is above a threshold, the payment processing network 250 may receive the authorization request message, determine the issuer associated with the user device 100, and forward the authorization request message including the credential to the authorization entity computer 102 for verification and authorization. Once the transaction is authorized, the authorization entity computer 102 may generate an authorization response message (which may include an authorization code indicating that the transaction is approved or denied) and transmit this electronic message to the payment processing network 250 via its external communication interface. The payment processing network 250 may then obtain the credential from the authorization response message and may obtain the token from the token service computer 242. The payment processing network 250 may then modify the authorization response message to include the token instead of the credential.

[0098] The payment processing network 250 may then forward the authorization response message including the token to the acquirer computer 240 , which in turn may then transmit an electronic message including the authorization indication to the resource provider computer 106 .

[0099] At the end of the day or at some other suitable time interval, a clearing and settlement process between the resource provider computer 106, the acquirer computer 240, the payment processing network 250, and the authorized entity computer 102 may be performed for the transaction.

[0100] Figure 4A system 400 is shown for accessing a building 430 (e.g., which may refer to any secure location) using a mobile communication device 410 according to various embodiments. In still other embodiments, the building may be a secure server computer housing secure data (e.g., secure and private data records) to be accessed. The mobile communication device 410 may correspond to the user device 100.

[0101] The user 406 may use the mobile communication device 410 to interact with the resource provider computer 106. For example, the resource provider computer 106 may retrieve a token or may request a token, as described in detail in the referenced Figure 1 and 2 The token may be sent to building 430, which may exchange the token for a real credential (e.g., a PIN) that may be used to access building 430. The real credential may be used to identify user 406, look up information about the user, and authenticate the user before allowing the user to enter building 430.

[0102] Figure 5 A block diagram showing a user device 100 that may be used in various embodiments. The user device 100 may be a mobile phone or an access card.

[0103] The user device 100 may include a computer-readable medium 502, which may be in the form of (or may be included in) a memory element storing data (e.g., a resource provider application) and may be in any suitable form (e.g., a microSD chip, a SIM card, or other type of memory element). The computer-readable medium 502 may include a transaction initiation module 502A, one or more applications 502B, and an operating system 502D for the user device 100. The transaction initiation module 502A may start a transaction at the request of a user or an application.

[0104] The user device 100 may additionally be a storage element 502C that stores real credentials and / or tokens. The storage element 502C may be part of the computer-readable medium 502, or may be a secure memory element separate from the computer-readable medium 502, such that the token or credential can only be accessed or altered by certain elements of the user device 100 and / or external devices.

[0105] In addition, the user device 100 may include device hardware 504, which includes a processor 506, a user interface 508, an input element 510, and an output element 512. The device hardware 504 may also include a long-range antenna 516 and a short-range antenna 514 for communicating with wireless networks and / or other devices. All elements in the device hardware 504 are coupled in an operational manner to enable mutual communication and data transfer.

[0106] The computer-readable medium 502 may store code that is executable by a processor for implementing a method including: transmitting device information of a user and resource provider information of a resource provider to an authorization entity computer 102, wherein the authorization entity computer 102 subsequently generates a registration data packet including the device information and the resource provider information and transmits it to a processing computer 104; receiving a token request push data packet including the user information and the device information; and in response to receiving the token request push data packet, transmitting a request to initiate token provisioning to a resource provider computer 106 associated with the resource provider information, wherein the resource provider computer 106 subsequently transmits a provisioning request generated based on the request to initiate token provisioning to the processing computer 104, wherein the processing computer 104 transmits the provisioning request including the token request push data packet to the token service computer 110, and wherein, upon receiving the provisioning request, the token service computer 110 generates token data using the device information and user information from the token request push data packet, and provides the token data to the resource provider computer 106.

[0107] In some embodiments, receiving the token request push packet causes the user device 100 to invoke a resource provider application 206 associated with a resource provider computer 106 on the user device 100 .

[0108] In some embodiments, the resource provider computer 106 authenticates the user via the resource provider application 206 and, based on the authentication of the user, transmits a provisioning request to the processing computer 104, wherein the provisioning request notifies the processing computer 104 that the resource provider computer 106 authorized the registration of the user.

[0109] In some embodiments, the token data includes a token stored by the resource provider computer 106 to be used in future interactions with the user.

[0110] In some embodiments, the token data includes at least one of a token reference identifier and a token corresponding to a primary account of the user.

[0111] refer to Figure 6 , a block diagram of a token service computer 110 according to various embodiments is shown. The token service computer 110 may include a processor 602 and a network interface 608 for receiving and transmitting messages (e.g., provisioning request messages, token creation messages, etc.) from / to an external source (e.g., an authorization entity computer 102, a service provider computer 108, a processing computer 104, etc.).

[0112] The token service computer 110 may include a non-transitory computer-readable medium 604, which includes a token generation module 604A and a verification module 604B. The token generation module 604A may include code that can be executed by the processor 602 to generate or obtain at least one token from an access credential. However, this module can also replace the token retrieval module, which connects the token service computer 110 to an external database (e.g., an issuer or an authorized entity) that can provide at least one token. The verification module 604B can be used in conjunction with the processor 602 to verify the token.

[0113] Figure 6 Also shown is a token database 612 operatively coupled to the processor 602. The token database 612 may store generated tokens as well as other token data, such as mappings to real credentials, passwords, and the like.

[0114] Figure 7 A block diagram of a processing computer 104 is shown according to an embodiment.

[0115] The processing computer 104 may include a processor 702, a computer readable medium 704, a data storage device 706, and a network interface 708 coupled to the processor 702 for receiving and transmitting messages.

[0116] The computer readable medium 704 may implement a user registration module 704A. The user registration module 704A may register (e.g., register) a user operating the user device 100. The user registration module 704A may map the user (e.g., user information, PAN, etc.), the authorized entity, and the resource provider information. The user registration module 704A may store the mapping between the above entities in the data storage device 706.

[0117] The computer readable medium 704 may also implement a password handling module 704B. The password handling module 704B may encrypt / decrypt user information and / or credentials of the user device 100 to implement the provisioning process as described herein.

[0118] The computer-readable medium 704 may also implement a token processing module 704C. The token processing module 704C may generate a token request push packet. The network interface 708 may then transmit the token request push packet to the user device 100 as described above. In addition, the token request push packet may be stored in the data storage device 706 in association with a user identifier (e.g., PAN and / or other user identification information).

[0119] The token processing module 704C can generate an updated provisioning request by appending a token request push packet to the provisioning request upon receiving the provisioning request from the resource provider computer 106 of the authenticated user. The network interface 708 can then transmit the updated provisioning request to the token service computer 110 to obtain a token, as described above.

[0120] The updated provisioning request and provisioning request identifier may be stored in data storage 706 in association with a user identifier (eg, PAN and / or other user identification information).

[0121] The computer readable medium 704 may also implement a resource provider determination module 704D. As described above, the resource provider determination module 704D may determine whether a resource provider is an OBO resource provider or a non-OBO resource provider.

[0122] The computer-readable medium 704 may also store code that can be executed by the processor 702 to implement a method including the following: receiving a registration data packet including a user's device information and resource provider information from the authorization entity computer 102; generating a token request push data packet including the user information and the device information; transmitting the token request push data packet to the user device 100, wherein the user device 100 subsequently transmits a request to initiate token provisioning to the resource provider computer 106 associated with the resource provider information; receiving a provisioning request generated based on the request to initiate token provisioning from the resource provider computer 106; and transmitting a provisioning request including the token request push data packet to the token service computer 110, wherein, upon receiving the provisioning request, the token service computer 110 determines token data using the device information and user information from the token request push data packet, and provides the token data to the resource provider computer 106.

[0123] In some embodiments, the authorization entity computer 102 authenticates the user and generates a registration data packet based on the user being authenticated.

[0124] In some embodiments, the authorization entity computer 102 authenticates the user by allowing the user to log into the user account and evaluating the user's login credentials.

[0125] In some embodiments, the user device 100 invokes the resource provider application 206 on the user device 100 upon receiving the token request push data packet.

[0126] In some embodiments, the resource provider computer 106 authenticates the user via the resource provider application 206 and, based on authenticating the user, transmits a provisioning request to the processing computer 104 that notifies the processing computer 104 that the resource provider computer 106 authorized the user's registration.

[0127] In some embodiments, the resource provider information identifies the resource provider, and the method further includes: in response to receiving the registration data packet, determining whether the resource provider is an on-behalf-of (OBO) resource provider that communicates with the token service computer or a non-OBO resource provider that communicates with the token service computer.

[0128] In some embodiments, generating a token request push data packet further includes: in response to determining that the resource provider is an OBO resource provider, generating a token request push data packet to include user information and device information, wherein the device information includes a primary account; and in response to determining that the resource provider is a non-OBO resource provider, generating a token request push data packet to include user information and device information, wherein the device information includes a reference identifier corresponding to the primary account.

[0129] In some embodiments, the processing computer 104 appends a token request push packet to the provisioning request received from the resource provider computer prior to transmitting the provisioning request to the token service computer 110 to generate an updated provisioning request.

[0130] In some embodiments, the token data includes at least one of a token and a token reference identifier.

[0131] In some embodiments, the token data comprises a token that is 16 bits long.

[0132] In some embodiments, at least one of the token and the token reference identifier is stored by the resource provider computer 106 for use in future interactions with the user.

[0133] In some embodiments, the token service computer 110 provides token data to the resource provider computer 106 via the service provider computer 108 , and before providing the token data to the service provider computer 108 , the token service computer 110 generates a token creation notification including token information and provides the token creation notification to the service provider computer 108 .

[0134] In some embodiments, the token information includes a provisioning request identifier identifying the provisioning request and a token reference identifier identifying the token.

[0135] In some embodiments, before the processing computer 104 receives the registration packet, the user selects a resource provider associated with the resource provider information.

[0136] Any software components or functions described in this application can 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 can be stored as a series of instructions or commands on a computer-readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium (e.g., a hard drive or floppy disk), or an optical medium (e.g., a CD-ROM). Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices within a system or network.

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

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

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

[0140] All patents, patent applications, publications, and descriptions mentioned above are incorporated by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A method comprising: The processing computer receives a registration data packet from the authorization entity computer, wherein the registration data packet includes the user's device information and the resource provider information; The processing computer transmits a token request push data packet to a user device, wherein the user device generates a token request push data packet including user information and the device information through the processing computer; subsequently, transmitting a request to initiate token provisioning to a resource provider computer associated with the resource provider information; receiving, by the processing computer, from the resource provider computer, a provisioning request generated based on the request to initiate provisioning of the token; as well as The processing computer transmits the provisioning request including the token request push data packet to the token service computer, wherein, upon receiving the provisioning request, the token service computer uses the device information and the user information from the token request push data packet to determine token data, and provides the token data to the resource provider computer.

2. The method of claim 1, wherein the authorization entity computer authenticates the user and generates the enrollment data packet based on the user being authenticated. 3 . The method of claim 2 , wherein the authorization entity computer authenticates the user by allowing the user to log into a user account and evaluating the user's login credentials. 4 . The method according to claim 1 , wherein the user device receives the token request push data packet to invoke a resource provider application on the user device.

5. The method of claim 4, wherein the resource provider computer authenticates the user via the resource provider application and, based on authenticating the user, transmits the provisioning request to the processing computer, the provisioning request notifying the processing computer that the resource provider computer authorizes the registration of the user.

6. The method according to claim 1, wherein: The resource provider information identifies the resource provider, and The method further comprises: In response to receiving the registration packet, the processing computer determines whether the resource provider is an off-behalf (OBO) resource provider in communication with the token service computer or a non-OBO resource provider in communication with the token service computer.

7. The method according to claim 6, wherein said generating said token request push packet further comprises: In response to determining that the resource provider is the OBO resource provider, generating the token request push data packet to include the user information and the device information, wherein the device information includes a primary account; and In response to the determination that the resource provider is the non-OBO resource provider, the token request push data packet is generated to include the user information and the device information, wherein the device information includes a reference identifier corresponding to a primary account.

8. The method according to claim 1, further comprising: The token request push data packet is appended by the processing computer to the provisioning request received from the resource provider computer prior to transmitting the provisioning request to generate an updated provisioning request, wherein the provisioning request sent to the token service computer is the updated provisioning request.

9. The method of claim 1, wherein the token data comprises at least one of a token and a token reference identifier.

10. The method of claim 9, wherein the token data comprises a 16-bit long token.

11. The method of claim 9, wherein the at least one of the token and the token reference identifier is stored by the resource provider computer for use in future interactions with the user.

12. The method of claim 1, wherein: The token service computer provides the token data to the resource provider computer via the service provider computer, and Prior to providing the token data to the service provider computer, the token service computer generates a token creation notification including token information and provides the token creation notification to the service provider computer.

13. The method of claim 12, wherein the token information comprises a provisioning request identifier identifying the provisioning request and a token reference identifier identifying a token.

14. The method of claim 1, wherein the resource provider associated with the resource provider information is selected by the user prior to receiving the registration packet by the processing computer.

15. A processing computer comprising: processor; as well as A computer readable medium comprising code which, when executed by the processor, causes the processor to perform a method comprising: receiving a registration data packet from an authorization entity computer, the registration data packet including device information of the user and resource provider information; Generate a token request push data packet including user information and the device information; transmitting the token request push data packet to a user device, wherein the user device subsequently transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information; receiving, from said resource provider computer, a provisioning request generated based on said request to initiate said token provisioning; as well as The provisioning request including the token request push data packet is transmitted to a token service computer, wherein upon receiving the provisioning request, the token service computer uses the device information and the user information from the token request push data packet to determine token data and provides the token data to the resource provider computer.

16. A method comprising: a user device operated by a user transmitting device information of the user and resource provider information of a resource provider to an authorization entity computer, wherein the authorization entity computer then generates a registration data packet including the device information and the resource provider information and transmits the registration data packet to a processing computer; The user device receives a token request push data packet including user information and the device information; as well as In response to receiving the token request push data packet, the user device transmits a request to initiate token provisioning to a resource provider computer associated with the resource provider information, wherein the resource provider computer subsequently transmits to the processing computer a provisioning request generated based on the request to initiate the token provisioning, wherein the processing computer transmits the provisioning request including the token request push data packet to a token service computer, and Wherein, upon receiving the provisioning request, the token service computer generates token data using the device information and the user information from the token request push data packet, and provides the token data to the resource provider computer.

17. The method of claim 16, wherein receiving the token request push packet causes the user device to invoke a resource provider application on the user device that is associated with the resource provider computer.

18. The method of claim 17, wherein the resource provider computer authenticates the user via the resource provider application and based on authenticating the user, transmits the provisioning request to the processing computer, wherein the provisioning request notifies the processing computer that the resource provider computer authorizes the registration of the user.

19. The method of claim 16, wherein the token data comprises a token, and Wherein the token is stored by the resource provider computer for use in future interactions with the user.

20. The method of claim 16, wherein the token data comprises at least one of a token reference identifier and a token corresponding to a primary account of the user.

Images