Method for processing access tokens in transactions using an access device

Abstract

A method includes providing, by an access device, an initial communication to a user device. The access device can receive a user identifier and an access token, and receive a secret associated with a user. The access device can determine whether a transaction is authorized by an authorizing entity computer associated with the access device or by an authorizing entity not associated with the access device using the user identifier and / or the access token. If the transaction is authorized by the authorizing entity computer associated with the access device, the access device can send an authorization request message including the user identifier, the secret, and the access token to the authorizing entity computer. The authorizing entity computer verifies the secret, retrieves authentic credentials of the user using the user identifier, and authorizes the transaction.

Description

[0001] Cross-referencing related applications

[0002] This application is a PCT application claiming priority to U.S. Patent Application No. 16 / 918,739, filed July 1, 2020, which is incorporated herein by reference. Background Technology

[0003] Users can initiate interactions with access devices (e.g., ATMs) using a payment card. Users can initiate interactions with access devices using a payment card associated with a specific authorized entity computer. After reading the payment card, the access device can prompt the user to enter a PIN. The access device can then send a message containing the user's account number and PIN (e.g., in a PIN block) to the ATM controller (ATMC).

[0004] An ATM controller (ATMC) is a system used to route transactions between ATMs, the core banking system, and other banks. An ATMC can be referred to as a switch. Messages can enter an ATMC from an ATM, another ATMC, or a third party. When a message is received, the ATMC examines the message, verifies the PIN block (if present), and then routes the message based on the first few digits of the referenced account number.

[0005] The routed message can be sent to the core banking system to check available balances and authorize the transaction, or it can be sent to the ATMC of another bank. For example, if a customer of bank A uses their card at an ATM belonging to bank B, the message will be forwarded to bank B's ATMC. Bank B's ATMC will examine the message and determine, based on the account number, that the appropriate ATMC to contact is bank A. The message will then be forwarded to bank A's ATMC for authorization.

[0006] To ensure the security of the aforementioned transactions, tokens may be used as an alternative to genuine account credentials. However, network-based tokenization is designed for access device (e.g., point-of-sale (POS) devices) environments and currently does not support closed-loop or "on-us" access device services, nor does it support access device access to secondary accounts. Closed-loop or "on-us" services are services that can be provided within the access device's network, while open-loop or "off-us" services are services provided by the authorizing entity's computer in a different network than the network used by the access device. Tokens cannot be used for closed-loop or on-us transactions in a conventional system because the de-tokenization process performed on the token is executed by a computer outside the range of the network containing the access device. These current limitations may require the authorizing entity to disallow access devices from performing proximity-based on-us interactions with user devices (e.g., mobile devices) that hold tokens. Even if the authorizing entity could allow access devices to communicate with user devices holding tokens, it might require significant message routing outside the access device's network and back to the origin, significantly increasing transaction time and complexity.

[0007] The embodiments of this disclosure address this problem and other problems individually and collectively. Summary of the Invention

[0008] The embodiments relate to methods and systems for interaction with access devices based on selective token processing.

[0009] One embodiment relates to a method comprising: providing initial communication by an access device to a user device associated with a user in a transaction; receiving a user identifier and an access token from the user device by the access device; receiving a secret associated with the user by the access device; determining, using the user identifier and / or the access token, whether the transaction is authorized by an authorized entity computer associated with the access device or by an authorized entity not associated with the access device; if the transaction is authorized by an authorized entity computer associated with the access device, sending an authorization request message including the user identifier, the secret, and the access token to the authorized entity computer, wherein the authorized entity computer verifies the secret, retrieves the user's authentic credentials using the user identifier, and authorizes the transaction; and if the transaction is not associated with an authorized entity computer, sending an authorization request message including the user identifier, the secret, and the access token to a token service computer, wherein the token service computer detoxifies the access token to obtain authentic credentials, replaces the access token with the authentic credentials in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to another authorized entity computer for authorization.

[0010] Another embodiment relates to an access device, comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for implementing a method comprising: providing initial communication to a user device associated with a user in a transaction; receiving a user identifier and an access token from the user device by the access device; receiving a secret associated with the user; determining, using the user identifier and / or the access token, whether the transaction is authorized by an authorization entity computer associated with the access device or by an authorization entity not associated with the access device; if the transaction is authorized by an authorization entity computer associated with the access device, sending an authorization request message including the user identifier, the secret, and the access token to the authorization entity computer, wherein the authorization entity computer verifies the secret, retrieves the user's authentic credentials using the user identifier, and authorizes the transaction; and if the transaction is not associated with an authorization entity computer, sending an authorization request message including the user identifier, the secret, and the access token to a token service computer, wherein the token service computer detoxifies the access token to obtain authentic credentials, replaces the access token with the authentic credentials in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to another authorization entity computer for authorization.

[0011] Another embodiment relates to a method comprising: receiving, during a transaction, an authorization request message including a user identifier, a secret, and an access token from an access device communicating with a user device associated with the user, wherein the transaction is determined by the access device to be authorized by an authorization entity computer associated with the access device; verifying the secret by the authorization entity computer; retrieving the user's authentic credentials using the user identifier by the authorization entity computer; authorizing the transaction by the authorization entity computer based on whether the secret has been verified and / or whether the authentic credentials have been retrieved; generating an authorization response message including an indication of whether the transaction has been authorized and an access token by the authorization entity computer; and providing the authorization response message to the access device by the authorization entity computer.

[0012] Further details regarding embodiments of this disclosure can be found in the detailed description and the accompanying drawings. Attached Figure Description

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

[0014] Figure 2 A block diagram showing the components of an access device according to an embodiment.

[0015] Figure 3 A flowchart illustrating the pre-fitting process according to an embodiment is shown.

[0016] Figure 4A flowchart illustrating the authorization process according to an embodiment is shown.

[0017] Figure 5 A flowchart illustrating a device communication method according to an embodiment is shown. Detailed Implementation

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

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

[0020] A “user device” can be a device operated by a user. Examples of user devices can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (e.g., automobiles), simplified client devices, tablet PCs, and so on. Furthermore, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by the user, and said electronic device can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (e.g., the Internet or a private network).

[0021] A “user identifier” can include any piece of data that can identify a user. A user identifier can include any suitable alphanumeric string. In some embodiments, the user identifier can be derived from user identification information. The user identifier can be a user information file identifier, also known as a customer information file identifier (CIF ID). In some embodiments, the user identifier can be a payment account reference (PAR) value, in which case the value is associated with a user rather than a single account.

[0022] A "user information file" can be an electronic document that stores relevant information about a user. The user information file may be associated with a user information file identifier (e.g., a user identifier). In some embodiments, the user information file may include the user's personal information and / or user account information. For example, a bank's user information file may include the user's credit history, accounts held, and ownership information.

[0023] An "access device" can be any suitable device that provides access to a remote system. Access devices can also be used to communicate with a coordinating computer, communication network, or any other suitable system. Access devices can typically be located anywhere suitable, such as at the merchant's location. Access devices can take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), vending machines, automatic teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc.

[0024] The access device can use any suitable contact or contactless operating mode to send or receive data from or associated with a mobile communication device or payment device. For example, the access device may have a card reader, which may include electrical contacts, a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with portable devices such as payment cards.

[0025] A “credential” can include any evidence of authorization, rights, or privileges. For example, an access credential can include permission to access certain tangible or intangible assets (such as buildings or documents). Instances of credentials can include passwords, passcodes, or confidential messages. In another instance, a payment credential can include any suitable information associated with and / or identifying an account (e.g., a payment account and / or a payment device associated with said account). This information can be directly related to the account or derived from account-related information. Instances of account information can include “account identifiers” such as PAN (primary account number or “account number”), tokens, sub-tokens, gift card numbers or codes, prepaid card numbers or codes, usernames, expiration dates, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. An instance of a PAN is a 16-digit number, such as “41470900 0000 1234”. In some embodiments, credentials can be considered sensitive information.

[0026] A "token" can be an alternative value to a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0027] A "payment token" may include a payment account identifier that substitutes for an account identifier such as a PAN or IBAN. For example, a payment token may include a series of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "49000000 0000 0001" may be used in place of the PAN "4147 09000000 1234". In some embodiments, the payment token may be "reserved format" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some embodiments, the payment token may substitute for a PAN used to initiate, authorize, settle, or resolve a payment transaction, or represent an original document in other systems that typically provide the original document. In some embodiments, the payment token may be generated such that the recovery of the original PAN or other account identifier from the token value can be done without computation. Additionally, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0028] Tokenization can include the process of replacing data with alternative data. For example, a payment account identifier (e.g., a master account number (PAN)) can be tokenized by replacing the master account identifier with an alternative number (e.g., a token) that can be associated with the payment account identifier. Additionally, tokenization can be applied to any other information that can be replaced with an alternative value (i.e., a token). Tokenization improves the efficiency and security of transactions.

[0029] A “password” can include obscure text, such as encrypted text. A password can be formed by encrypting input data using an encryption key (e.g., a symmetric encryption key). In some embodiments, the password is reversible, allowing the same symmetric key to be used to obtain the input used to form the password for decryption. In some embodiments, the password can also be a digital signature if the input data is encrypted using the private key of a public / private key pair. The digital signature can be verified using the public key of the public / private key pair. In some embodiments, the password can include a dynamic card verification value (dCVV).

[0030] In embodiments of the invention, the password can be generated in any suitable manner. In some embodiments, the password input may include data elements, including account identifiers such as a master account and variable data elements such as a counter, time of day, or interaction value. Such data can be included using encryption processes such as DES, Triple DES, or AES using any suitable encryption key. The encryption key may also be a unique derived key or UDK and may be generated based on device-specific information such as an account, which can be encrypted using a master derived key (MDK). The password can be verified by another computer, such as a remote computer, by decrypting the password to its decrypted form and verifying the decrypted form with other data (e.g., the account number stored in a file), or by encrypting other input and comparing the encrypted result with the password.

[0031] A "secret" can include something that is kept or intended to be kept from being known or seen by others. The secret can be known by both the user of the user device and the authorized entity of the authorized entity computer. For example, a secret can be a Personal Identification Number (PIN). In some embodiments, during provisioning and / or registration, a user can create a secret and provide it to the authorized entity computer to obtain credentialing credentials. In other embodiments, the authorized entity computer can create a secret, then assign and provide it to the user. In some embodiments, a secret can include a One-Time Password (OTP).

[0032] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the message is sent to the transaction processing computer and / or the issuer of the payment card to request authorization for the transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that can be associated with the 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, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), access token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0033] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or transaction processing computer. For example, an 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 – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0034] "Authorizing entity" can be the entity requesting authorization. Examples of authorizing entities include issuers, government agencies, document repositories, access administrators, etc. An authorizing entity can operate an authorizing entity's computer. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. An issuer can also issue payment credentials stored on a user device, such as a cellular phone, smart card, tablet computer, or laptop computer, to consumers, or in some embodiments, to portable devices.

[0035] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment.

[0036] "Interaction data" can include data related to the interaction and / or data recorded during the interaction. In some embodiments, interaction data can be transaction data of network data. Transaction data can include multiple data elements with data values.

[0037] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, site and residential operators, etc.

[0038] The term "verification" and its derivatives can refer to the process of using information to determine whether a potential subject is valid under a given set of conditions. Verification may include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0039] A “processor” can include means for performing a task. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

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

[0041] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one 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 serve requests from one or more client computers.

[0042] I. Introduction

[0043] As described above, current network-based tokenization is designed for access device (e.g., point-of-sale (POS) devices) environments and currently does not support closed-loop or "peer" access device services, nor does it support access device access to secondary accounts. Closed-loop or "peer" services are those that can be provided within the access device's network, while open-loop or "cross-peer" services are those provided by the authorizing entity's computer in a different network than the network used by the access device. In conventional systems, closed-loop or peer transactions cannot use tokens because the detoxification process for the token is performed by a computer outside the scope of the network containing the access device. These current limitations may require the authorizing entity to disallow access devices from performing proximity-based peer interactions with user devices (e.g., mobile devices) that hold tokens. Alternatively, the authorizing entity may allow access devices to communicate with user devices that hold tokens, but this could require significant message routing outside the access device's network and back to the origin, significantly increasing transaction times.

[0044] Embodiments of this disclosure allow for an access device that efficiently performs interactions with a user device containing an access token and associated with a user. For example, the access device may provide initial communication to the user device, in response of which the user device may retrieve a user identifier and an access token from memory. The user device may then provide the user identifier and access token to the access device. Subsequently, in some embodiments, the access device may prompt the user to enter a secret associated with the user.

[0045] In various embodiments, the access token may be associated with a user identifier created by the authorizing entity's computer. In some embodiments, the user identifier may be, for example, a Customer Information File Identifier (CIF ID). The user identifier may be stored in a tag (e.g., tag 9F10 (IAD)) provided to the access device. The access device may read the pre-configured AID on the user device and then determine the Bank Identification Number (BIN) created by the authorizing entity or the range of tokens assigned.

[0046] Next, the access device can determine whether the transaction is 1) authorized by an authorized entity computer associated with the access device (e.g., peer interaction) or 2) authorized by an authorized entity not associated with the access device (e.g., non-peer interaction). For example, the access device can use a user identifier and / or access token to determine the authorized entity computer.

[0047] If the transaction is authorized by an authorizing entity computer associated with the access device, the access device may send an authorization request message to the authorizing entity computer, including a user identifier, a secret, and an access token. Upon receiving the authorization request message, the authorizing entity computer may verify the secret, retrieve the user's authentic credentials using the user identifier, and authorize the transaction. In some embodiments, the authorizing entity computer may determine whether the user's authentic credentials are associated with an access token. In some embodiments, the user identifier may be encrypted, enabling the authorizing entity computer to identify and / or access the plaintext user identifier.

[0048] In some embodiments, the authorized entity computer can verify a secret by comparing the received secret with a previously stored secret associated with the genuine credentials. For example, a previously stored secret could be a PIN created by the user of the genuine credentials.

[0049] In some embodiments, the access device may read the user identifier from a first marker (e.g., 9F10) and in some embodiments, the access device may read the user identifier from the last four digits of a second marker (e.g., marker 9F19) to determine which account options and service features to display to the user on the access device after authorization by the authorized entity computer.

[0050] If the transaction is not associated with an authorizing entity computer, the access device can send an authorization request message to the token service computer, which includes a user identifier, a secret, and an access token. The token service computer can detoxify the access token to obtain a legitimate credential. The token service computer can then replace the access token with the legitimate credential in the authorization request message to form a modified authorization request message, which is then forwarded to another authorizing entity computer for authorization.

[0051] Various embodiments can facilitate both peer and non-peer access device processing. While non-peer access device processing can utilize access to a specified primary account, peer access device processing can facilitate access to both primary and secondary accounts linked to a single user credential (e.g., PAN).

[0052] II. System

[0053] Figure 1A system 100 according to an embodiment of the present disclosure is illustrated. System 100 includes a user device 102, an access device 104, an access device network 106, an authorization entity computer A 108, a transmission computer 110, a processing network computer 112, a token service computer 114, and a plurality of authorization entity computers 116. User device 102 can operatively communicate with access device 104. Access device 104 can operatively communicate with access device network 106 and transmission computer 110. Access device network 106 can operatively communicate with processing network computer 112 and authorization entity computer A 108. Processing network computer 112 can operatively communicate with authorization entity computer A 108, transmission computer 110, token service computer 114, and the plurality of authorization entity computers 116.

[0054] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown are either fewer or more components.

[0055] At least Figure 1 Messages between devices in System 100 can be sent using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583), etc. The communication network can include any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (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.); etc. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some instances, the communication channel can include a secure communication channel, which can be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0056] User device 102 may include a device operated by a user. In some embodiments, user device 102 may include a digital wallet storing an access token. User device 102 may be configured to communicate with one or more access devices (e.g., access device 104). User device 102 may provide access tokens and user identifiers to access device 104 during interactions (e.g., payment transactions, location access interactions, data access interactions, account access interactions, etc.). In some embodiments, a user may use user device 102 to perform any suitable interaction with access device 104. For example, through interaction, a user may make deposits, access multiple accounts, purchase goods, or any combination thereof.

[0057] Access device 104 may include a means for reading data, for example, from user device 102, and determining an authorized entity computer (e.g., authorized entity computer A108) associated with access device 104 from a plurality of authorized entity computers 116. In some embodiments, access device 104 may be an automated teller machine (ATM).

[0058] Access device 104 may be associated with an authorized entity computer (e.g., authorized entity computer A108). Access device 104 and authorized entity computer A108 may be associated in any suitable manner. For example, access device 104 and authorized entity computer A108 may be operated by the same entity (e.g., a bank, security company, data provider, etc.). In some embodiments, access device 104 may be associated with authorized entity computer A108 by being located in or related to the same or similar location. For example, access device 104 may be located at a secure building, and a user may access the secure building in connection with an access token associated with the secure building. Authorized entity computer A108 may also be associated with a secure building. For example, authorized entity computer A108 may be a computer located at a secure building and may authorize users to access the secure building (e.g., authorize users to enter the secure building).

[0059] Access device network 106 may include any suitable network that allows access device 104 to communicate with authorized entity computer A108. Access device network 106 may include one or more computers that can route messages between access device 104 and authorized entity computer A108. Access device network 106 may process transactions provided by access device 104 in a manner specific to access device 104. For example, access device network 106 may be associated with access device 104 (e.g., operated by the same or similar entity, etc.). Therefore, access device network 106 may be configured to process data received from access device 104 that is associated with authentic credentials issued to a user. When a user's authentic credentials and access device 104 are associated with the same issuing entity, access device 104 may present the user with additional options (e.g., depositing cash, depositing checks, etc.). If a user's authentic credentials and access device 104 are not associated, the user may select an option that might not otherwise exist. Access device network 106 can be configured to handle these user-available options, but if the user's credentials are associated with different issuing entities, access device network 106 may not be configured to process data related to the credentials (or access tokens associated with the credentials). In this case, access device network 106 can send any relevant data to different access device networks associated with different issuing entities. If access device network 106 and the credentials are not associated with the same entity, access device network 106 can route transaction data to different access device networks.

[0060] Furthermore, the access device network 106 may not be configured to send data to authorized entity computers not associated with it. In some cases, the access device network 106 may only provide data (e.g., transaction data, authorization request messages, etc.) to associated authorized entity computers, but not to unassociated authorized entity computers. This may be for various reasons, such as communication between the access device network 106 and associated authorized entity computers having a unique format and / or utilizing specific cryptographic protocols, preventing different access device networks from communicating directly with authorized entity computers.

[0061] The transmission computer 110 may include a computer that routes messages between the access device 104 and the processing network computer 112. The transmission computer 110 may be operated by an acquiring party, which may typically be a commercial entity (e.g., a commercial bank) with a business relationship with a particular merchant or other entity.

[0062] The processing network computer 112 may include a server computer for processing interactive data (e.g., transaction data, access data, etc.). In some embodiments, the processing network computer 112 may be coupled to a database and may include any hardware, software, other logic, or combinations thereof for serving requests from one or more client computers. The processing network computer 112 may include one or more computing devices and may use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers. In some embodiments, the processing network computer 112 may operate multiple server computers. In such embodiments, each server computer may be configured to process transactions in a given region or to process a specific type of transaction based on transaction data.

[0063] The processing network computer 112 may include a data processing subsystem, network, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary processing network computer 112 may include VisaNet. TM Including VisaNet TM The network, including VisaNet, can process credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, this includes an integrated payment system (ICS) for processing authorization requests and a BaseII system for performing clearing and settlement services. The network computer 112 can use any suitable wired or wireless network, including the Internet.

[0064] The processing network computer 112 can perform operational communication with the token service computer 114. The processing network computer 112 can provide an access token to the token service computer 114. The token service computer 114 can determine the authentic credentials associated with the access token (e.g., in a database). The token service computer 114 can then provide the authentic credentials to the processing network computer 112.

[0065] Figure 2 A block diagram of an access device 200 according to some embodiments is shown. An exemplary access device 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, an input element 210, an output element 212, and a computer-readable medium 208. The computer-readable medium 208 may include a communication module 208A and an authorized entity computer determination module 208B.

[0066] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (e.g., RAM, DRAM, ROM, flash memory, or any other suitable memory device). For example, memory 202 can store BIN tables, routing tables, etc.

[0067] One or more input elements 210 may include any suitable means capable of inputting data into access device 200. Examples of input elements 210 include buttons, touch screens, touchpads, microphones, etc.

[0068] One or more output elements 212 may include any suitable means capable of outputting data. Examples of output elements 212 may include a display screen, a speaker, and a data transmitting device. For example, output element 212 may include a display screen capable of displaying response values ​​to a user of access device 200.

[0069] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: providing initial communication by an access device to a user device associated with a user in a transaction, wherein the user device then retrieves a user identifier and an access token from memory in the user device; receiving the user identifier and access token from the user device by the access device; receiving a secret associated with the user by the access device; determining by the access device, using the user identifier and / or access token, whether the transaction is authorized by an authorized entity computer associated with the access device or by an authorized entity not associated with the access device; if the transaction is authorized by an authorized entity computer associated with the access device, sending an authorization request message including the user identifier, the secret, and the access token to the authorized entity computer, wherein the authorized entity computer verifies the secret, retrieves the user's authentic credentials using the user identifier, and authorizes the transaction; and if the transaction is not associated with an authorized entity computer, sending an authorization request message including the user identifier, the secret, and the access token to a token service computer, wherein the token service computer de-tokenizes the access token to obtain authentic credentials, replaces the access token with the authentic credentials in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to another authorized entity computer for authorization.

[0070] Communication module 208A can be configured or programmed to perform and receive, send and generate electronic messages for transmission at access device 200. Figures 1-5The access device 200 may send some or all of its associated functionalities from any of the entities shown (e.g., user devices, access device networks, transmission computers, etc.). When the access device 200 receives an electronic message via network interface 206, it may pass the electronic message to communication module 208A. Communication module 208A may identify and parse the relevant data based on a specific messaging protocol (e.g., EMV 2.0, etc.) used in the access device 200. Communication module 208A may then send any received information to the appropriate module within the access device 200 (e.g., authorization entity computer determination module 208B). Communication module 208A may also receive information from one or more modules in the access device 200 and generate an electronic message in an appropriate data format conforming to the sending protocol used in the access device 200, such that the message can be sent to one or more entities within the system. The electronic message may then be passed to network interface 206 for transmission.

[0071] The authorized entity computer determination module 208B may include code or software executable by the processor 204 to determine the authorized entity computer. In conjunction with the processor 204, the authorized entity computer determination module 208B can use a user identifier and / or access token to determine whether a transaction was authorized by an authorized entity computer associated with the access device or by an authorized entity not associated with the access device.

[0072] The authorized entity computer determination module 208B, in conjunction with the processor 204, can use a user identifier to determine whether a transaction was authorized by an authorized entity computer associated with access device 200 or by an authorized entity not associated with access device 200. For example, the authorized entity computer determination module 208B, in conjunction with the processor 204, can determine that a specific portion of a number (e.g., the first four digits, the last two digits, etc.) corresponds to a specific authorized entity computer. For example, the authorized entity computer determination module 208B, in conjunction with the processor 204, can receive the user identifier 123456789. Then, the authorized entity computer determination module 208B of access device 200 can, in conjunction with the processor 204, determine that the last two digits 89 correspond to a first authorized entity computer. In some embodiments, the last two digits 89 may also correspond to access device 200.

[0073] The authorized entity computer determination module 208B, in conjunction with the processor 204, can use an access token to determine whether a transaction was authorized by an authorized entity computer associated with the access device 200 or by an authorized entity not associated with the access device 200. For example, the access device may store a token range table (e.g., a BIN range table). The authorized entity computer determination module 208B can determine the authorized entity computer based on the access token received from the user device.

[0074] As an illustrative example, an access token could be “0123456789012345”. The authorized entity computer determination module 208B, in conjunction with the processor 204, can determine that the access token falls within, for example, the token range of 0123456780000000-0123456790000000. Each token range can be associated with an authorized entity computer.

[0075] Network interface 206 may include an interface that allows access device 200 to communicate with an external computer. Network interface 206 enables access device 200 to transfer data to and from another device. Some examples of network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TM Data transmitted via network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0076] III. Methods

[0077] A. Pre-mixed

[0078] Figure 3 A flowchart illustrating a pre-configuration method according to an embodiment is shown. This will be described in the context of an authorized entity pre-configuring a user identifier for a user device. Figure 3 The method described herein. However, it should be understood that the invention can be applied to other situations. Typically, during the provisioning process, a user of a user device may choose to input credentials (e.g., a PAN) into a digital wallet application on the user device. After receiving and storing the credentials, the user device may request a token to associate it with the credentials from the processing network computer. Upon receiving the token request, the processing network computer sends a provisioning request for a user identifier to the authorized entity computer. After receiving the user identifier, the processing network computer may send the token to the user device.

[0079] Figure 3The described method includes a provisioning process initiated by an authorized entity computer 302. In step 1, the authorized entity computer 302 may initiate a provisioning of a token and user identifier for user device 306. In some embodiments, the authorized entity computer 302 may generate a user identifier. In other embodiments, the authorized entity computer 302 may retrieve an existing user identifier associated with a user of user device 306. The authorized entity computer 302 may provide the user identifier to the processing network computer 304. For example, the authorized entity computer 302 may provide the processing network computer 304 with a token provisioning request including the user identifier.

[0080] In step 2, after receiving the token pre-provisioning request, the processing network computer 304 can create an access token associated with the user. The access token can be generated in any suitable manner. For example, in some embodiments, the access token can be generated based on user credentials (e.g., PAN) associated with the user of user device 306. For example, the processing network computer 304 can receive user credentials from the authorized entity computer 302, or it can have a database storing user credentials and user identifiers associated with those credentials. In other embodiments, the access token can be randomly generated and then assigned to the user identifier and / or user credentials (e.g., associating the access token with the user identifier and / or user credentials). The processing network computer 304 can then provide the access token to a digital wallet and / or a database (e.g., a resource provider card-on-file database). The access token can also be provided directly from the processing network computer 304 to user device 306 and / or a digital wallet stored on user device 306.

[0081] In some embodiments, the processing network computer 304 can personalize the access token. As an illustrative example, the following personalization profiles can be associated with the access tokens depicted in Tables 1 and 2, where Table 1 describes the values ​​associated with the access token and Table 2 describes the possible detoxification options for the access token.

[0082] A dedicated Application Identifier Extension Code (PIX) and a Registered Application Provider Identifier (RID) can be provided. The PIX can be a variable-length suffix that can be assigned by the card process to distinguish multiple applications (e.g., credit card and debit card applications) provided by said process. The value of any PIX may be dedicated to each process and, if present, can be appended to the RID to create an Application Identifier (AID) for each application. The RID can be a fixed-length unique identifier assigned to each card process to identify the EMV application provided by said process. The process can then suffix the RID with the PIX to further distinguish multiple products supported by the process, and the RID and PIX together form the AID. The AID can be used to uniquely identify each EMV (Europay MasterCard Visa) application supported by the access device, and the AID can have associated card processes and parameters related to how the application needs to be processed. The access device can contain any number of such applications, and a list of each supported AID is used during the candidate list creation process to generate a list of applications mutually supported by both the terminal and the card.

[0083]

[0084] Table 1: Example Global RID / PIX / AID Values

[0085]

[0086] Table 2: Detoxification Options

[0087] B. Authorization

[0088] Figure 4 A flowchart illustrating the authorization process according to an embodiment is shown. The process will be described in the context of a first user device performing an authorization process with the access device (e.g., peer interaction), followed by a second user device performing an authorization process with the access device (e.g., non-peer interaction). Figure 4 The method described herein. However, it should be understood that the invention is applicable to other situations (e.g., any suitable number of user devices performing and accessing the device authorization process in any order, etc.). In some embodiments, reference is made to... Figure 4 The described licensing process can be referred to as a peer licensing process.

[0089] In some cases, a user device can provide a token to an access device. Upon receiving the token, the access device can route it to a de-tokenizing computer (e.g., a token service computer). De-tokenization enhances security within the user control device (e.g., the user device) and facilitates the authorization entity computer in determining which account and / or genuine credentials are associated with the token.

[0090] refer to Figure 4 The described embodiments have various advantages. For example, refer to Figure 4 The following process is described as efficient and takes less time to process transactions because it does not involve fewer steps (e.g., detoxification process).

[0091] Prior to step 420, the first user device 402 may receive an access token via a provisioning process, for example, by referring to... Figure 3 As described.

[0092] In step 420, access device 404 may provide initial communication to a first user device 402 associated with the user during the transaction. The initial communication may be, for example, a Near-Field Payment System (PPSE) environment selection command. In some embodiments, the initial communication may allow the user device and access device to determine the processing environment for subsequent communication. PPSE commands and responses may be followed by commands and responses to obtain processing options and read records. However, it should be understood that communication between access device 404 and the first user device 402 may include any suitable communication. In some embodiments, access device 404 is allowed to... Figure 4 The communications that retrieve data from the user device at the beginning and / or near the beginning of the described process can be collectively referred to as initial communications. (See reference) Figure 5 Further details regarding the initial communication are described in more detail.

[0093] Initial communication can be provided to the first user device 402 after it enters the communication range with the access device 404. For example, the access device 404 can determine that the first user device 402 has entered short-range communication (e.g., NFC, Bluetooth, BLE, etc.).

[0094] In step 422, after receiving the initial communication from the access device 404, the first user device 402 may determine to provide a user identifier and an access token to the access device 404. The first user device 402 may retrieve the user identifier and access token from its memory. The user identifier may be a user information file identifier, also known as a customer information file identifier (CIFID). The access token may be a token corresponding to the user's actual credentials.

[0095] In step 424, the first user device 402 may provide a user identifier and an access token to the access device 404. In some embodiments, the first user device 402 may provide the user identifier and access token in the same response message or different response messages (e.g., a first response message and a second response message). About Figure 5 The communication between the first user device 402 and the access device 404 is discussed in further detail.

[0096] For example, the user identifier can be alphanumeric and, in some embodiments, can be unique to the user. For example, the user identifier provided from the first user device 402 to the access device 404 could be “NU486F100A”. The access token could be a value such as “0123456789123456”.

[0097] In step 426, after receiving the user identifier and access token from the first user device 402, the access device 404 may further receive a secret associated with the user. The access device 404 may prompt the user to enter the secret (e.g., a PIN). For example, the access device 404 may display a message to the user on its display screen. This message may instruct the user to enter the secret into the access device 404 via one or more input elements.

[0098] In some embodiments, at any appropriate time during steps 420-426, the user may select one or more options displayed to the user on access device 404. For example, the user may select to perform a withdrawal, perform a deposit, view account history, perform a transaction, etc. As an illustrative example, the user may select to perform a withdrawal (e.g., to obtain currency) from access device 404. The option to perform a withdrawal may be included in the authorization request and authorization response messages described below.

[0099] In step 428, access device 404 can use a user identifier and / or access token to determine whether the transaction was authorized by an authorized entity computer associated with the access device or by an authorized entity not associated with the access device. The authorized entity computer associated with the access device may belong to the same entity and / or be operated by the same entity. Authorized entities not associated with the access device may not belong to the same entity and / or be operated by the same entity. For example, authorized entity computer A 408 may be an authorized entity computer associated with the access device. Authorized entity computer B 414 may be an authorized entity computer not associated with access device 404.

[0100] For example, access device 404 can determine, based on an access token, whether a transaction is 1) authorized by an authorized entity computer associated with the access device or 2) authorized by an authorized entity computer not associated with the access device. For example, access device 404 can determine which BIN range the access token belongs to (e.g., numerically). The access token can be generated within a BIN range already associated with a specific authorized entity computer. Access device 404 can determine that a received access token is within a BIN range associated with an authorized entity further associated with the access device. Similarly, the BIN range can also be associated with access device 404 itself. If access device 404 determines that the access token is within a BIN range associated with access device 404, then access device 404 can determine that the transaction was authorized by an authorized entity computer associated with the access device.

[0101] Access device 404 may store a BIN table, which can be referenced to determine which authorized entity computer is authorized to authorize a transaction using the received access token.

[0102] As an illustrative example, access device 404 can evaluate the received access token 0123456789123456. Access device 404 can be associated with an authorizing entity computer (e.g., authorizing entity computer A408), where both devices correspond to the range 0123450000000000-0123459999999999. Access device 404 can determine that the received access token 0123456789123456 is a value within the range 0123450000000000-0123459999999999, and then determine that the access token is authorized by the authorizing entity computer associated with access device 404.

[0103] In step 430, access device 404 may generate an authorization request message including a user identifier, a secret, and an access token. If the transaction is authorized by an authorization entity computer (authorization entity computer A408) associated with access device 404, then in step 430, access device 404 may send the authorization request message including the user identifier, a secret, and an access token to access device network 406.

[0104] In step 432, after receiving the authorization request message from the access device 404, the access device network 406 may provide the authorization request message to the authorization entity computer A408.

[0105] In step 434, after receiving the authorization request message, the authorizing entity computer A 408 can verify the secret. For example, the secret could be a PIN that the user directly enters into the access device 404. The authorizing entity computer A 408 can compare the received PIN with a stored PIN (e.g., one previously created or assigned to a user). If the received PIN matches a stored PIN, the authorizing entity computer A 408 can determine that the user is reliable.

[0106] In step 436, the authorized entity computer A 408 can retrieve the user's authentic credentials using the user identifier. For example, the authorized entity computer A 408 can determine a user information file (e.g., a customer information file (CIF)) that is stored and / or includes the user identifier in association with it. The user information file may include one or more authentic credentials. The authorized entity computer A 408 can determine at least one authentic credential based on the received user identifier.

[0107] As an illustrative example, authorized entity computer A 408 can determine that the received user identifier NU486F100A is associated with a first user information file in a database. The first user information file may include the user identifier NU486F100A. The first user information file may include one or more accounts accessible to the user. For example, the first user information file may include a first account 0123455555123456 (which may be a valid credential), a second account 0123456888999999, and a third account 0123456777888999. The first user information file may include any suitable number of accounts, where each account may be used for the same or different types of accounts, including but not limited to checking accounts, savings accounts, money market accounts, brokerage accounts, investment retirement accounts, and / or any other accounts accessible to the user.

[0108] In some embodiments, after determining and retrieving the user's authentic credentials, the authorizing entity computer A408 may link the authentic credentials (e.g., PAN) to an access token. For example, the authorizing entity computer A408 may store information about the interaction (e.g., transaction) in an interaction log or other suitable database. The authorizing entity computer A408 may store the authentic credentials and access token together in the log, so that at any suitable point in time thereafter, the entity and / or device can determine that the interaction was performed using the access token and authentic credentials.

[0109] In step 438, the authorizing entity computer A 408 may determine whether to authorize the transaction. The authorizing entity computer A 408 may generate an indication of whether the transaction has been authorized. The authorizing entity computer A 408 may generate an authorization response message including the indication of whether the transaction has been authorized. In some embodiments, the authorizing entity computer A 408 may include one or more accounts that the user can access for the current interaction in the authorization response message.

[0110] In step 440, the authorizing entity computer A 408 may provide an authorization response message to the access device network 406.

[0111] In step 442, after receiving the authorization response message from the authorized entity computer A408, the access device network 406 may provide the authorization response message to the access device 404.

[0112] In step 444, after receiving the authorization response message, access device 404 can determine whether the transaction was authorized by the authorizing entity computer A 408. If the transaction is authorized, access device 404 can display any suitable information to the user on its display. For example, access device 404 can display one or more accounts and / or account options to the user. As another example, access device 404 can provide the user with the currency and / or goods associated with the transaction. As yet another example, access device 404 can provide access to secure buildings, secure web pages, secure data, etc.

[0113] For example, access device 404 may display options related to the user's initial selection (e.g., performing a withdrawal). Access device 404 may display one or more accounts received from authorized entity computer A 408 from which the user can select to withdraw funds. For example, in some embodiments, the user may choose to withdraw funds from an account associated with physical credentials and an access token. In other embodiments, the user may choose to withdraw funds from a displayed account that is not associated with physical credentials and an access token but is accessible to the user.

[0114] After the first user device 402 executes a transaction with the access device 404, the second user device 403 can execute a second transaction with the access device 404.

[0115] In step 446, access device 404 may provide initial communication in a transaction to a second user device 403 associated with another user. Transactions conducted using the first user device 402 may be performed by the first user. Transactions conducted using the second user device 403 may be performed by the second user. In step 446, the initial communication may request a user identifier and an access token.

[0116] Initial communication can be provided to the second user device 403 after it enters the communication range with the access device 404. For example, the access device 404 can determine that the second user device 403 has entered short-range communication (e.g., NFC, Bluetooth, BLE, etc.).

[0117] In step 448, after receiving initial communication from access device 404, the second user device 403 may determine to provide a user identifier and access token to access device 404. The second user device 403 may retrieve the user identifier and access token from its memory. In step 450, the second user device 403 may provide the user identifier and access token to access device 404. In some embodiments, the second user device 403 may provide the user identifier and access token in the same response message or different response messages (e.g., a first response message and a second response message).

[0118] In step 452, after receiving the user identifier and access token from the second user device 403, the access device 404 can use the user identifier and / or access token to determine whether the transaction was authorized by an authorized entity computer associated with the access device or by an authorized entity not associated with the access device. For example, authorized entity computer A 408 may be an authorized entity computer associated with the access device. Authorized entity computer B 414 may be an authorized entity computer not associated with the access device 404 (e.g., not on the same common network as the authorized entity computer).

[0119] Access device 404 may determine that the received access token is associated with an authorized entity not associated with the access device. For example, access device 404 may determine that the transaction was authorized by an authorized entity not associated with the access device (e.g., authorized entity computer B 414).

[0120] In some embodiments, access device 404 may further receive a secret associated with the user. Access device 404 may prompt the user to enter the secret (e.g., a PIN). For example, access device 404 may display a message to the user on its display screen. The message may instruct the user to enter the secret into access device 404 via one or more input elements of access device 404.

[0121] In step 454, access device 404 may generate an authorization request message including a user identifier, a secret, and an access token. Since the transaction is authorized by an authorization entity computer B414 that is not associated with access device 404, access device 404 may send the authorization request message including the user identifier, a secret, and an access token to transmission computer 410.

[0122] In step 456, the transmitting computer 410 may provide an authorization request message to the processing network computer 412.

[0123] In step 458, after receiving the authorization request message, the processing network computer 412 can determine the authentic credentials (e.g., PAN) associated with the access token. For example, the processing network computer 412 can provide the access token to the token service computer. The token service computer can use a database to determine the authentic credentials stored associated with the access token. The token service computer can then provide the authentic credentials to the processing network computer 412. The processing network computer 412 can then modify the authorization request message to include the authentic credentials and delete the access token.

[0124] In step 460, the processing network computer 412 may then provide an authorization request message (e.g., a modified authorization request message) to the authorization entity computer B 414.

[0125] In step 462, after receiving the authorization request message, the authorizing entity computer B 414 can determine whether to authorize the transaction. For example, the authorizing entity computer B 414 can determine whether to authorize the transaction based at least on the received authentic credentials. The authorizing entity computer B 414 can generate an authorization response message that includes an indication of whether the interaction is authorized and the authentic credentials. In some embodiments, the authorizing entity computer B 414 can also verify the received secret, as described herein.

[0126] In step 464, the authorizing entity computer B 414 may then provide an authorization response message to the processing network computer 412.

[0127] In step 466, after receiving an authorization response message that includes an indication of whether the interaction is authorized and the real credentials, the processing network computer 412 may modify the authorization response message to replace the real credentials with a token.

[0128] In step 468, after modifying the authorization response message, the processing network computer 412 may then provide the transmission computer 410 with an authorization response message (e.g., a modified authorization response message).

[0129] In step 470, after receiving the authorization response message, the transmission computer 410 may provide the authorization response message to the access device 404.

[0130] In step 472, after receiving an authorization response message (e.g., a modified authorization response message) from the transmission computer 410, the access device 404 may display the authorization response message and / or an indication of whether the interaction was authorized to the user of the second user device 403. For example, in some embodiments, if the interaction is authorized, the access device 404 may offer currency and / or goods to the user of the user device. In other embodiments, if the interaction is not authorized, the access device 404 may display an "interaction denied" message to the user. The access device 404 may then prompt the user to enter additional credentials and / or a user-known secret to retry the transaction.

[0131] In some embodiments, the aforementioned authorization process may optionally include detoxing performed by a token service computer. For example, during a closed-loop or "peer" transaction, the access token may be detoxified by the token service computer. By detoxing the access token during a closed-loop transaction, the genuine credentials used in the transaction can be provided to the authorizing entity computer for authorization. In some embodiments, a password may be provided from user device 402 to access device 404 during the detoxing process. For example, the password may be obfuscated text, such as encrypted text. The password can be formed by encrypting input data with an encryption key (e.g., a symmetric encryption key). In some embodiments, the password is reversible, allowing the same symmetric key to be used to obtain the input used to form the password for performing the decryption process. For example, the password may include a Dynamic Card Authentication Value (dCVV). The password can provide further security benefits to the system because it can be generated based on the current interaction between user device 402 and access device 404.

[0132] Passwords can be generated in any suitable manner. For example, password input may include data elements, such as account identifiers (e.g., master account numbers) and variable data elements such as counts, time of day, or interaction value. Such data can be included using encryption processes such as DES, Triple DES, or AES using any suitable encryption key. The encryption key may also be a uniquely derived key (UDK) or a uniquely derived key (MDK) and may be generated based on device-specific information, such as an account number, which can be encrypted using a master derived key (MDK). The password can be verified by another computer, such as a remote computer, by decrypting the password and verifying the decrypted content with other data (e.g., the account number stored in a file), or by encrypting other input and comparing the encrypted result with the password.

[0133] After receiving an authorization request message containing a password from access device 404 at step 406, access device network 406 can determine that the token in the authorization request message should be de-tokenized by processing network computer 412. Access device network 406 can send the authorization request message to processing network computer 408. After receiving the authorization request message, processing network computer 408 can determine the authentic credentials (e.g., PAN) associated with the access token through one or more communications with a token service computer (not shown). After receiving the access token from processing network computer 408, the token service computer can determine the authentic credentials associated with the received access token. For example, the authentic credentials can be stored in association with the access token (e.g., associated with the access token) in a security token database (e.g., a token vault).

[0134] The token service computer can provide the genuine credentials to the processing network computer 408. After receiving the genuine credentials from the token service computer, the processing network computer 408 can then modify the authorization request message to include the genuine credentials.

[0135] In some embodiments, the processing network computer 408 can verify the password provided from the user device 402 to the access device 404. By verifying the password, the processing network computer 408 can authenticate the user device 402, since only the user device 402 can provide the correct password. Therefore, by performing an optional detoxification process, the processing network computer 408 can provide additional security benefits by authenticating the user device 402.

[0136] Then, the processing network computer 412 can provide a modified authorization request message to the access device network 406 for authorization. After the interaction is authorized or unauthorized, the system can perform a tokenization process, in which the processing network computer 412, in conjunction with a token server computer, determines a token based on the real credentials and replaces the real credentials with the token in the authorization response message.

[0137] C. Communication Details

[0138] Figure 5 A flowchart illustrating a device communication method according to an embodiment is shown. The method will be described in the context of communication between the access device and the user device. Figure 5 The method described herein. However, it should be understood that the invention can be applied to other situations.

[0139] In step S505, access device 504 may perform application selection together with user device 502 to select applications for further processing. For example, access device 504 may determine which applications are supported by both user device 502 and access device 504. In some embodiments, when access device 504 detects the presence of user device 502, access device 504 may send an available application request (which may be a “selection command”) to user device 502 to request information (e.g., a list of AIDs) about which payment applications are available at user device 502. In some embodiments, the application selection command may be a PPSE command.

[0140] User device 502 can respond by sending an available application response back to access device 504. The available application response (which may be a "selection response") may include a list of available AIDs (application identifiers).

[0141] Then, access device 504 can select a suitable application from the list of applications received in the available application response (e.g., by selecting an AID from the available AIDs). Access device 504 can also send an application selection message with the selected AID (which may be a "read record" or "select AID" command) to user device 502.

[0142] Upon receiving a Select AID command, User Device 502 may send a response to transaction data (e.g., a "Read Record Response") to Access Device 504, which may be required to execute a transaction using the selected application / AID. The request may include a list of transaction data identifiers, and the list may be in the form of a Processing Options Data Object List (PDOL).

[0143] In step S510, access device 504 may initiate application processing with user device 502. For example, access device 504 may request user device 502 to indicate the selected application and the data used by the supported functions (e.g., a list of files containing the data). In some embodiments, access device 504 may send a Get Processing Option (GPO) command. Access device 504 may also (e.g., via a GPO command) provide transaction information to user device 502.

[0144] Upon receiving a GPO command, user device 502 may use at least some of the received transaction data to generate dynamic transaction processing information and (via a "GPO response") send a set of transaction processing information to access device 504. The transaction processing information may include one or more Application File Locators (AFLs), which may be used by access device 504 as file addresses to read account data stored on user device 502. In some embodiments, in response to a GPO command, user device 502 may retrieve a user identifier (e.g., a CIFID) from memory. User device 502 may provide the user identifier to access device in a GPO response. For example, the user identifier may be included in tag 9F10, which may include Issuer Application Data (IAD). The user identifier included in tag 9F10 may have a variable length of up to, for example, 32 bytes.

[0145] In step S515, access device 504 can read application data. For example, access device 504 can send a "read record command" to user device 502 to read account data stored at user device 502.

[0146] User device 502 may send account data to access device 504 (e.g., via a "read log response"). Account data may include, for example, track 2 equivalent data (e.g., account identifier and / or other payment credentials) and cardholder name, and / or other account-related data accessible at the AFL location. In some embodiments, in response to a read log command, user device 502 may retrieve a token (e.g., an access token) from memory. User device 502 may provide the token to access device 504 in a read log response.

[0147] The embodiments of this disclosure offer numerous advantages. For example, embodiments provide peer token processing for ATM transactions. When an access device is associated with an authorizing entity computer for an authorized transaction, embodiments provide efficient processing of token transactions. For instance, embodiments do not require routing each authorization request message through a token service computer. Embodiments allow the authorizing entity computer to associate a determined credential with an access token without needing to detoxify the access token at the token service computer during the transaction. Once determined, the credential can be used for the transaction. Embodiments of the invention also allow users with access tokens to transact with authorizing entity computers without using a detoxification server outside the network. This saves multiple messages and communications, and therefore also saves processing time.

[0148] Although the steps in the flowcharts and process flows above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and they may still be present in embodiments of the invention.

[0149] Another embodiment includes a method comprising: receiving initial communication from an access device in a transaction by a user device associated with a user; retrieving a user identifier and an access token from memory in the user device in response to the initial communication; and providing the user identifier and access token to the access device by the user device, wherein the user provides a secret to the access device, wherein the access device uses the user identifier and / or access token to determine whether the transaction is authorized by an authorization entity computer associated with the access device or by an authorization entity not associated with the access device; and if the transaction is authorized by an authorization entity computer associated with the access device, the access device sends an authorization request message including the user identifier, the secret, and the access token to the authorization entity computer, wherein the authorization entity computer verifies the secret, retrieves the user's authentic credentials using the user identifier, and authorizes the transaction; and if the transaction is not associated with an authorization entity computer, the access device sends an authorization request message including the user identifier, the secret, and the access token to a token service computer, wherein the token service computer detoxifies the access token to obtain authentic credentials, replaces the access token with the authentic credentials in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to another authorization entity computer for authorization.

[0150] Additionally, in some embodiments, the initial communication includes a get processing options command and a read log command, and providing the user identifier and access token further includes: the user device providing an get processing options response including the user identifier in response to the get processing options command; and the user device providing a read log response including the access token in response to the read log command.

[0151] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media (e.g., hard disk drive or floppy disk), or optical media (e.g., optical disc (CD) or digital versatile optical disc (DVD)), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0152] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0153] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims together with their full scope or equivalents.

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

[0155] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one / a kind.”

Claims

1. A method for processing access tokens in a transaction, the method comprising: The access device provides initial communication to the user device associated with the user in the transaction; In response to providing the initial communication, the access device receives a user identifier and the access token from the user device; The access device receives a secret associated with the user; The access device uses the user identifier and / or the access token to determine whether the transaction was authorized by a first authorized entity computer associated with the access device or by a second authorized entity computer not associated with the access device; If the transaction is authorized by the first authorized entity computer associated with the access device, an authorization request message including the user identifier, the secret, and the access token is sent to the first authorized entity computer, wherein the first authorized entity computer verifies the secret, retrieves the user's true credentials using the user identifier, and authorizes the transaction; and If the transaction is not authorized by the first authorized entity computer, an authorization request message including the user identifier, the secret, and the access token is sent to the token service computer, wherein the token service computer detoxifies the access token to obtain the real credential, replaces the access token with the real credential in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to the second authorized entity computer for authorization.

2. The method according to claim 1, wherein the method further comprises: The access device receives an authorization response message from the first authorized entity's computer, which includes at least an indication of whether the transaction is authorized; as well as The access device displays an indication to the user of the user device on the display of the access device whether the transaction has been authorized.

3. The method according to claim 1, further comprising: The access device prompts the user to enter the secret via one or more input elements on the access device.

4. The method of claim 1, wherein if the transaction is authorized by the first authorized entity computer associated with the access device, the first authorized entity computer uses the authentic credentials to verify the access token.

5. The method according to claim 1, wherein the user identifier identifies the user information file, wherein the secret is a personal identification code, and wherein the authentic credential is a master account.

6. The method of claim 1, wherein the initial communication includes a command to obtain processing options and a command to read records.

7. The method of claim 6, wherein receiving the user identifier and the access token further comprises: The access device receives an acquisition processing option response, including the user identifier, in response to the acquisition processing option command; as well as The access device receives a read record response, including the access token, in response to the read record command.

8. The method of claim 1, wherein sending the authorization request message including the user identifier, the secret, and the access token to the first authorized entity computer if the transaction is authorized by the first authorized entity computer associated with the access device further comprises: The access device sends the authorization request message, which includes the user identifier, the secret, and the access token, to the first authorized entity computer via the access device network.

9. The method of claim 1, wherein the token service computer pre-configures the access token for the user device.

10. An access device, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: The access device provides initial communication to the user device associated with the user during the transaction; In response to providing the initial communication, a user identifier and an access token are received from the user device; Receive the secret associated with the user; The user identifier and / or the access token are used to determine whether the transaction was authorized by a first authorized entity computer associated with the access device or by a second authorized entity computer not associated with the access device; If the transaction is authorized by the first authorized entity computer associated with the access device, an authorization request message including the user identifier, the secret, and the access token is sent to the first authorized entity computer, wherein the first authorized entity computer verifies the secret, retrieves the user's true credentials using the user identifier, and authorizes the transaction; and If the transaction is not authorized by the first authorized entity computer, an authorization request message including the user identifier, the secret, and the access token is sent to the token service computer, wherein the token service computer detoxifies the access token to obtain the real credential, replaces the access token with the real credential in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to the second authorized entity computer for authorization.

11. The access device of claim 10, wherein if the transaction is not authorized by the first authorizing entity computer, the token service computer forwards a modified authorization response message to the access device via a transmission computer.

12. The access device of claim 11, wherein the method further comprises: The access device receives the modified authorization response message from the token service computer; as well as The access device displays an indication to the user of the user device on the display of the access device whether the transaction was authorized by the second authorized entity computer.

13. The access device of claim 10, wherein if the transaction is authorized by the first authorized entity computer associated with the access device, the method further comprises: The access device sends the authorization request message to the first authorized entity computer via the access device network.

14. The access device of claim 13, wherein the first authorizing entity computer generates an authorization response message including at least an indication of whether the transaction is authorized and the real credential and provides the authorization response message to the token service computer, wherein the token service computer tokenizes the real credential to obtain the access token, replaces the real credential with the access token to form a modified authorization response message, and forwards the modified authorization response message to the access device, wherein the method further comprises: The modified authorization response message is received by the access device; as well as The access device displays an instruction on its display to the user of the user device indicating whether the transaction was authorized by the first authorized entity computer.

15. The access device of claim 10, wherein the initial communication is provided to the user device via a short-range communication channel.

16. The access device according to claim 10, wherein the user device is a first user device, the transaction is a first transaction, the initial communication is a first initial communication, the user identifier is a first user identifier, the access token is a first access token, the secret is a first secret, the authorization request message is a first authorization request message, the modified authorization request message is a first modified authorization request message, the authenticity credential is a first authenticity credential, and wherein the method further comprises: In the second transaction, a second initial communication is provided to a second user device associated with the second user, wherein the second user device then retrieves a second user identifier and a second access token from memory in the second user device. The access device receives the second user identifier and the second access token from the second user device; Receive the second secret associated with the second user; The second user identifier and / or the second access token are used to determine whether the second transaction was authorized by the first authorized entity computer associated with the access device or by the second authorized entity computer not associated with the access device. If the second transaction is authorized by the first authorized entity computer associated with the access device, a second authorization request message including the second user identifier, the second secret, and the second access token is sent to the first authorized entity computer, wherein the first authorized entity computer verifies the second secret, retrieves the second user's second authentic credentials using the second user identifier, and authorizes the second transaction; and If the second transaction is not authorized by the first authorized entity computer, a second authorization request message including the second user identifier, the second secret, and the second access token is sent to the token service computer, wherein the token service computer detoxifies the second access token to obtain the second real credential, replaces the second access token with the second real credential in the second authorization request message to form a second modified authorization request message, and forwards the second modified authorization request message to the second authorized entity computer for authorization.

17. The access device of claim 10, wherein the transaction is a location access transaction, wherein if the location access transaction is authorized, the method further comprises: The access device provides the user with access to the location of the location access transaction.

18. The access device of claim 10, wherein the transaction is a data access transaction, wherein if the data access transaction is authorized, the method further comprises: The access device provides data corresponding to the data access transaction to the user's user device.

19. A method for processing access tokens in a transaction, the method comprising: During the transaction, a first authorizing entity computer receives an authorization request message, including a user identifier, a secret, and the access token, from an access device that communicates with a user device associated with the user, wherein the transaction is determined by the access device to be authorized by the first authorizing entity computer associated with the access device. The secret is verified by the computer of the first authorized entity. The first authorized entity computer uses the user identifier to retrieve the user's true credentials; The transaction is authorized by the first authorized entity computer based on whether the secret has been verified and / or whether the authentic credentials have been retrieved; The first authorized entity computer generates an authorization response message including an indication of whether the transaction is authorized and the access token; as well as The authorization response message is provided by the first authorized entity computer to the access device. The access device is programmed to: Initial communication is provided to the user device associated with the user in the transaction. In response to providing the initial communication, the user identifier and the access token are received from the user device. Receive the secret associated with the user. The user identifier and / or the access token are used to determine whether the transaction was authorized by a first authorized entity computer associated with the access device or by a second authorized entity computer not associated with the access device. If the transaction is authorized by the first authorized entity computer associated with the access device, an authorization request message including the user identifier, the secret, and the access token is sent to the first authorized entity computer, wherein the first authorized entity computer verifies the secret, retrieves the user's true credentials using the user identifier, and authorizes the transaction; and If the transaction is not authorized by the first authorized entity computer, an authorization request message including the user identifier, the secret, and the access token is sent to the token service computer, wherein the token service computer detoxifies the access token to obtain the real credential, replaces the access token with the real credential in the authorization request message to form a modified authorization request message, and forwards the modified authorization request message to the second authorized entity computer for authorization.

20. The method of claim 19, wherein the first authorizing entity computer receives the authorization request message from the access device via the access device network, and wherein the first authorizing entity computer provides the authorization response message to the access device via the access device network.

Images