Location-matching authentication systems and methods

Abstract

According to some embodiments of the present invention, an authentication method is provided. Transaction data for a transaction is received at a communication device from an access device or a resource provider. The transaction data includes the location of the access device. The location of the communication device is determined by the communication device itself. It is determined whether the distance between the location of the access device and the location of the communication device is within a predetermined threshold. If the distance between the location of the access device and the location of the communication device is not within the predetermined threshold, then the transaction is not authorized.

Description

[0001] This application is a divisional application of Chinese patent application No. 201780009300.8, entitled "Authentication System and Method Using Location Matching".

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 294,471, filed February 12, 2016, entitled “AUTHENTICATION SYSTEMS AND METHODS USING MERCHANT AND CONSUMER LOCATIONS”, the entire contents of which are incorporated herein by reference. Background Technology

[0004] Typically, users authenticate transactions when requesting them from resource providers. For example, cardholders can authenticate purchases at a point of sale. Sensitive user information, such as the primary account number (PAN), access number, or PIN, can be conveyed by the device used to execute the transaction (e.g., credit card, mobile device, communication device, security device, etc.). However, users may not want to share their sensitive information with resource providers due to security concerns.

[0005] Therefore, a secure and efficient method is needed to enable more users to conduct transactions using their devices while keeping their sensitive information hidden from resource providers. This reduces the number of parties to whom sensitive information is communicated, thus lowering both the risk of resource providers committing fraud and the risk of sensitive information being intercepted and misused.

[0006] To further prevent fraud by unauthorized parties, authorizing entities can operate authentication systems to ensure that sensitive information is being used by authorized users in transactions. However, for face-to-face transactions, better authentication methods are needed. Authorizing entities can see authorization request messages containing sensitive user information from resource providers, but cannot verify that the authorized user of the sensitive information is actually at the resource provider's location. For example, an unauthorized user might steal and misuse this sensitive information (e.g., a stolen credit card). Embodiments of the present invention individually and collectively address this and other problems. Summary of the Invention

[0007] According to some embodiments of the present invention, systems and methods are provided that allow users to perform payment transactions using their communication devices, without requiring the use of contactless components or dedicated hardware at the merchant's location. Furthermore, systems and methods are also provided for authenticating users based on their location in face-to-face transactions with resource providers.

[0008] According to some embodiments of the present invention, a method for executing a transaction between a user and a resource provider is provided. The method includes receiving transaction data for the transaction from an access device associated with the resource provider at a user's communication device. The transaction data may include the location of the access device and sensitive information. The method further includes determining the location of the communication device by the communication device. The method further includes determining, by the communication device or a remote computer communicating with the communication device, whether the distance between the location of the access device and the location of the communication device is within the predetermined threshold. If the distance between the location of the access device and the location of the communication device is not within the predetermined threshold, then the transaction is not authorized. If the distance between the location of the access device and the location of the communication device is within the predetermined threshold, then the transaction is further processed using a token corresponding to the sensitive information.

[0009] Embodiments of the present invention also relate to a communication device including a processor and a non-transitory computer-readable medium. The computer-readable medium may include code executable by the processor for implementing the methods described above or any of the methods described herein.

[0010] Embodiments of the present invention also relate to a server computer including a processor and a non-transitory computer-readable medium. The computer-readable medium may include code executable by the processor for implementing any of the methods described herein.

[0011] These and other embodiments of the present invention will be described in more detail below. Attached Figure Description

[0012] Figure 1 A block diagram is shown illustrating an authentication system and method employing location matching according to some embodiments of the present invention.

[0013] Figure 2 A flowchart illustrating an authentication method employing location matching according to some embodiments of the present invention is shown.

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

[0015] Figure 4 A block diagram of an application provider computer according to some embodiments of the present invention is shown.

[0016] Figure 5 A block diagram of a token server according to some embodiments of the present invention is shown.

[0017] Figure 6A block diagram of a building access system according to some embodiments of the present invention is shown. Detailed Implementation

[0018] According to some embodiments of the present invention, systems and methods are provided that allow users to perform transactions using their communication devices, said systems and methods not requiring the use of contactless components or dedicated hardware at the resource provider. Furthermore, systems and methods are also provided for authenticating users based on their location during face-to-face transactions with resource providers.

[0019] Before discussing specific implementation schemes and examples, the following provides some descriptions of the terminology used in this article.

[0020] 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 merchant's computer, transaction processing computer, authentication computer, 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, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, and access systems. Access devices can use any suitable contact or contactless operating mode to send or receive data to or from a user's mobile device, or to associate with a user's mobile device. In some implementations where an access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and / or a mobile device. A POS terminal may or may not initiate transaction processing.

[0021] An "acquiring party" can typically be a commercial entity (such as a commercial bank) with a business relationship with a particular merchant or other entity. Some entities can perform the functions of both an issuer and an acquirer. Some implementations may include such a single entity as an issuer-acquiring party. The acquiring party can operate an acquiring party computer, which may also be collectively referred to as a "transfer computer".

[0022] An "authorization request message" can be an electronic message sent to a payment processing network and / or the issuer of a payment card to request authorization for a transaction. According to some implementations, authorization request messages may conform to ISO 8583 (International Organization for Standardization), a system standard for exchanging information on electronic transactions associated with payments made by consumers using payment devices or payment accounts. Authorization request messages may include an issuer account identifier that can be associated with the payment device or payment account. Authorization request messages may also include additional data elements corresponding to "identification information," such as, for example, service code, CVV (Card Verification Value), dCVV (Dynamic Card Verification Value), expiration date, etc. Authorization request messages may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction.

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

[0024] An "authorizing entity" can be the entity making the authorization request. Instances of an authorizing entity can be publishers, government agencies, document repositories, access administrators, etc.

[0025] A “code” can be any system of words, letters, numbers, graphics, and / or other symbols that represent data. Exemplary codes include barcodes, QR codes, SKUs, etc.

[0026] "Communication device" can include any suitable electronic device that can be operated by a user and also provides the ability to communicate remotely with a network. Examples of remote communication capabilities include the use of 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 network access such as the Internet or a private network. Examples of communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, watches, fitness trackers, anklets, rings, earrings, etc., as well as automobiles with remote communication capabilities. Communication devices can include any suitable hardware and software for performing such functions and can also include multiple devices or components (e.g., two devices used together when the device remotely accesses a network by being attached to another device—i.e., using another device as a modem—can be considered a single communication device).

[0027] "Consumer" can include an individual or user who operates a communication device to conduct transactions on an account or otherwise manages the account. A consumer may also be referred to as a cardholder, account holder, or user. The term "consumer" is used interchangeably with "user."

[0028] A "digital wallet" can include electronic applications or devices that allow individuals to conduct e-commerce transactions. An e-wallet can store user profile information, payment credentials, bank account information, one or more digital wallet identifiers, and can be used in a variety of transactions, such as, but not limited to, e-commerce, social networks, money transfers / personal payments, mobile commerce, in-game payments, and / or gaming, for retail purchases, digital goods purchases, utility payments, purchasing games or game credits on gaming websites or systems, and transferring funds between users. Digital wallets can be designed to simplify the purchasing and payment process. A digital wallet can allow users to load one or more payment cards to it for payments without entering an account number or presenting a physical card. A digital wallet can also store transaction records (e.g., electronic receipts).

[0029] "Issuer" can typically refer to a commercial entity that maintains user accounts (e.g., a bank). An issuer can also issue payment credentials stored on communication devices.

[0030] "Location" refers to a specific place or location of something. Location can be physical (e.g., the location of a house) or intangible (e.g., a website or IP address). Location can be represented by any appropriate means, including address, GPS coordinates, latitude, longitude, and / or combinations of latitude and longitude.

[0031] "Supply" can include the process of providing data for use. For example, supply can include providing, delivering, or enabling tokens on a communication device. Supply can be performed by an entity within or outside the transaction system. For example, in some implementations, the issuer or transaction processing network can supply tokens to mobile devices. The supplied tokens may have corresponding token data stored and maintained in a token vault or token registry. In some implementations, the token vault or token registry can generate tokens that can later be supplied or delivered to devices.

[0032] 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, access devices, secure data access points, etc. A "merchant" can typically be an entity that participates in transactions and can sell goods or services, or provide access to goods or services.

[0033] "Sensitive information" can be any suitable information that, if disclosed, could be used in a manner that would cause harm to the legitimate holder of the sensitive information. Sensitive information can take any suitable form. Examples of sensitive information may include account numbers, PINs, device identifiers, secure element identifiers, etc.

[0034] 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 operating like cells. In one instance, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the foregoing for serving requests from one or more client computers. A server computer can include one or more computing devices and can use any computing architecture, arrangement, and compilation from a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0035] A "service provider" or "application provider" can be an entity that can provide services or applications. An example of a service provider is a digital wallet provider.

[0036] A "token" may include a substitute identifier for a particular piece of information. For example, a payment token may include an identifier for a payment account, which is a substitute for an account identifier such as a Master Account Number (PAN). For example, a token may include a string of alphanumeric characters that can be used as a substitute for the original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the PAN "41470900 0000 1234". In some implementations, the token may be "preserved format," having a numerical format consistent with account identifiers used in existing payment processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some implementations, the token may be used in place of the PAN to initiate, authorize, settle, or complete a payment transaction. In other systems where the original certificate is typically provided, the token may also be used to represent the original certificate. In some implementations, the token value may be generated such that the original PAN or other account identifier cannot be recovered from the token value through computation. Additionally, in some implementations, 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.

[0037] "Tokenization" is the process of replacing sensitive data with alternative data. For example, an actual account identifier (e.g., a master account number (PAN)) can be tokenized by replacing it with an alternative number that can be associated with the actual account identifier. Tokenization can also be applied to any other information, replacing implicit information with a token. "Token exchange" or "detoxing" is the process of recovering data that was replaced during tokenization. For example, token exchange can include replacing a payment token with the master account number (PAN) associated with it. Furthermore, detoxing or token exchange can be applied to any other information to retrieve the replaced information from the token. In some implementations, token exchange can be implemented via transaction messages (e.g., ISO messages), application programming interfaces (APIs), or other types of web interfaces (e.g., web requests).

[0038] "Transaction data" can include any data associated with or representing a transaction between a resource provider (e.g., a merchant) and a user (e.g., a consumer). For example, transaction data can include resource provider data (e.g., merchant ID, card acceptor ID, etc.), user data, location data, transaction details (e.g., transaction ID, transaction amount, etc.), and / or combinations thereof.

[0039] A "transaction processing computer" may include a network of one or more devices capable of processing and routing transaction request messages. An exemplary transaction processing computer may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception handling services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing system may include VisaNet. TM Such as VisaNet TM The transaction processing system can handle credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet TM Specifically, this may include a VIP system (account-integrated payment system) for processing authorization requests and a Base II system for performing clearing and settlement services.

[0040] Figure 1 A block diagram of a location-matching authentication system and method 100 according to some embodiments of the present invention is shown. In step S110, a user of communication device 10 can select a payment method at access device 20 (e.g., a point-of-sale terminal associated with the resource provider) during a transaction with a resource provider (e.g., the purchase of goods or services). In step S115, access device 20 can provide a code to communication device 10. The code may be previously generated by access device 20 or may be generated by access device 20 in real time. The code may be static (i.e., the same for multiple transactions) or dynamic (i.e., different for different transactions). The code may be displayed electronically by access device 20, or may be printed on a piece of paper, or may be displayed to communication device 10 in other non-electronic ways.

[0041] The code can encode transaction data, which includes resource provider data (e.g., resource provider identifier, card recipient identifier, etc.), the selected payment method, the location of access device 20, the location of access device 20 or resource provider computer 25, transaction details such as the transaction amount, identifiers associated with transmission computer 50, application identifiers (AIDs), and / or combinations thereof. In some embodiments, some of this transaction data, such as the transaction amount, may be omitted and / or provided later. In some embodiments, the code may be a QR code, barcode, or any other code that can be used to represent data. In some embodiments, the code can be standardized across different transaction processing computers 60 (i.e., the code can be the same regardless of the transaction processor associated with the transaction). In some embodiments, the code may differ depending on the specific transaction processing computer 60.

[0042] In some implementations, transaction data may further include the transaction type, such as a flag or indicator indicating how the transaction will be processed (e.g., whether a Card Verification Number (CVN), Token Authentication Verification Value (TAVV), or Original Credit Transaction (OCT) is used). The transaction data can be analyzed to determine if the transaction type indicator is one of several transaction type indicators associated with a variety of different transaction types. Transaction processing can then be initiated based on the transaction type indicator. The transaction type can be determined by which types(s) a particular resource provider 25 and / or delivery computer 50 is capable of processing. For example, the resource provider computer 25 and a directory of registered transaction types can be queried. The transaction type can indicate the parties involved and the sequence of steps taken to process the transaction. However, this information can remain transparent to the user (e.g., the consumer), thus maintaining a consistent user experience regardless of the transaction type.

[0043] In step S120, the user of communication device 10 can open an application and use communication device 10 to scan a code at access device 20. For example, communication device 10 can use a camera integrated into communication device 10 or any other visual inspection device integrated into or associated with communication device 10 to scan the code. In step S130, the application residing on communication device 10 reads the code to extract transaction data, including the location of access device 20, and optionally displays it to the user. If the transaction data is displayed, the user can then confirm the transaction data. In other embodiments, the code may be in the form of data that can be transmitted via wireless or contact-based communication protocols. Wireless protocols may include NFC, Bluetooth, IR, etc.

[0044] In some implementations, the transaction amount (e.g., purchase amount, number of accesses to be provided, access to what, etc.) may not be provided in the code. Therefore, the transaction amount may not be included in the transaction data extracted from the code. In these implementations, the user can enter the transaction amount into the communication device 10 after scanning the code. In some implementations, the communication device 10 may display a list of sensitive information used to complete the transaction (e.g., a list of master account (PAN), payment device, password, PIN, etc.) and allow the user to select one or more pieces of sensitive information from the list.

[0045] Furthermore, in step S130, the application on the communication device 10 can enable the communication device 10 to determine its current location. For example, it can be determined by a GPS device within the communication device 10 or operatively connected to the communication device 10, as further described herein. However, it is conceivable that the current location of the communication device 10 can be determined by any method, including, for example, triangulation between cell towers.

[0046] In some implementations, an application on communication device 10 can determine whether the distance between the location of access device 20 and the location of communication device 10 is within a predetermined threshold. The predetermined threshold can be any threshold distance indicating that a user of communication device 10 is present at or near access device 20, and the predetermined threshold can be set by the user of communication device 10, application provider computer 40, or any party involved in the transaction. For example, the predetermined threshold could be 100 feet. In these implementations, in step S136, the application on communication device 10 can encrypt transaction data, selected sensitive information for the transaction, and the indication that the distance is within the predetermined threshold, and provide it to application provider computer 40. Application provider computer 40 can be the provider of the application on communication device 10. In some implementations, application provider computer 40 is the same computer as or associated with the same entity as authorized entity computer 70.

[0047] In some implementations, the application on communication device 10 does not determine whether the distance between the location of access device 20 and the location of communication device 10 is within a predetermined threshold. Instead, in step S136, the application on communication device 10 may encrypt transaction data (including the location or address of access device 20 or the resource provider and / or the identifier of access device 20 or the resource provider), selected sensitive information for the transaction, and the location of communication device 10 (e.g., latitude and longitude), and provide this information to application provider computer 40. Application provider computer 40 may decrypt the data and determine whether the distance between the location of access device 20 and the location of communication device 10 is within the predetermined threshold. In such implementations, the location of access device 20 may be pre-stored as latitude and longitude coordinates, or the latitude and longitude coordinates of access device 20 or the resource provider associated with access device 20 may be determined using the identifier (e.g., address) of access device 20 or the resource provider associated with access device 20.

[0048] In some implementations, if the distance between the location of access device 20 and the location of communication device 10 is not within a predetermined threshold, the application provider computer 40 may not process the transaction. In some implementations, if the distance is not within the predetermined threshold, the application provider computer 40 may process the transaction, but may generate data to be transmitted to the authorizing entity computer 70 indicating that the distance is not within the predetermined threshold. In the latter implementation, the authorizing entity computer 70 then determines whether to authorize the transaction based on the generated data and any other available authentication and / or authorization data.

[0049] In some implementations, if the distance is within a predetermined threshold, the application provider computer 40 can process the transaction. Specifically, in step S140, the application provider computer 40 can verify the transaction data and route a request for a token associated with selected sensitive information, along with at least some of the transaction data (e.g., a transaction identifier), to a token server 30. The token server 30 can generate a token for the transaction, which is associated with the selected sensitive information and stored along with at least some of the transaction data. This allows the token server 30 to uniquely identify the implicit transaction. For example, the token can be stored along with the transaction identifier.

[0050] Simultaneously, in step S150, access device 20 can send transaction data to resource provider computer 25. In step S152, resource provider computer 25 can send a request for a token for the transaction to token server 30. The request may include identifying transaction data, for example, a transaction identifier previously provided to token server 30 by application provider computer 40. In step S154, token server 30 can retrieve the token associated with the identifying transaction data and provide it to resource provider computer 25. Although shown as communicating directly with token server 30, it is conceivable that in some embodiments, application provider computer 40 may act as an intermediary between resource provider computer 25 and token server 30.

[0051] Authorization can then be implemented. For example, in step S160, the resource provider computer 25 can construct an authorization request message using the token and transaction data and submit the message to the transmission computer 50. In step S162, the transmission computer 50 can forward the authorization request message to the transaction processing computer 60. In step S164, the transaction processing computer 60 can request sensitive information associated with the token from the token server 30 and receive the sensitive information in step S166. In step S168, the transaction processing computer 60 can replace the token with the sensitive information in the authorization request message and forward it to the authorization entity computer 70 for authorization. The authorization entity computer 70 can approve or reject the transaction request based on several factors, including whether there are sufficient funds and / or credit in the account, whether the transaction indicates fraud, etc.

[0052] In step S170, the authorizing entity computer 70 may send an authorization response message (i.e., denying or allowing the transaction based on available funds, requested access volume, etc.) to the transaction processing computer 60. Optionally, the transaction processing computer 60 may use a token instead of the sensitive information in the authorization response message. In step S172, the transaction processing computer 60 may forward the authorization response message to the transmitting computer 50. The transmitting computer 50 may forward the authorization response message to the resource provider computer 25 in step S174, and the resource provider computer 25 may then forward the authorization response message or an instruction to approve or deny the transaction to the access device 20 in step S176. In some embodiments, a receipt or other proof of transaction completion may then be provided to the user of the communication device 10. The clearing and settlement process may occur at the end of the day or at any other suitable time after the transaction is completed.

[0053] To simplify the explanation, Figure 1 A specific 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 the components shown have fewer or more components. Furthermore, Figure 1 The components can communicate using any appropriate communication protocol through any suitable communication medium (including the Internet).

[0054] Moreover, it can be envisioned Figure 1 Other variations of the process flow. For example, instead of sending the token from the token server 30 to the resource provider computer 25, the token can be sent to the application provider computer 40, the communication device 10, and / or the access device 20 for initial authorization processing. Furthermore, although embodiments of the invention are related to... Figure 1While the specific process described herein is as described, it is also conceivable to incorporate embodiments of the invention into other processes, such as those described in U.S. Patent Application No. 15 / 421,891, filed February 1, 2017, entitled “SYSTEMS AND METHODS FOR CODE DISPLAY AND USE,” the entire contents of which are incorporated herein by reference.

[0055] Figure 2 A flowchart illustrating an authentication method employing location matching according to some embodiments of the present invention is shown. In step 210, the authentication method can be performed on the user's communication device used for the transaction (…). Figure 1 The transaction data is received at the communication device 10. The transaction data may be received from an access device (e.g., access device 20) associated with a resource provider (e.g., resource provider computer 25). The transaction data may include the location of the access device. The location of the access device may be provided in any suitable format. For example, the location of the access device may be a physical address (e.g., 123 Main Street, Pleasantville, OH) or as latitude and longitude coordinates. The transaction data may also include sensitive information, such as an account number. In some embodiments, the transaction data may further include a timestamp associated with the transaction data (i.e., a timestamp indicating the time when the location of the access device was determined and sent).

[0056] In step 220, the location of the communication device can be determined by the communication device itself. For example, the location of the communication device can be determined by a GPS device that is used in conjunction with or associated with the communication device. In another example, triangulation of the location of the communication device can be performed using cellular towers. The location of the communication device can have any suitable format. For example, the location of the communication device can be represented as coordinates, such as latitude and longitude. In some embodiments, the location of the communication device can also have an associated timestamp (i.e., a timestamp indicating the time when the location of the communication device was determined).

[0057] In step 230, the communication device or a remote computer communicating with the communication device can determine whether the distance between the location of the access device and the location of the communication device is within a predetermined threshold. The distance between the locations can be determined by any suitable method, for example, by mapping the locations and measuring the distance between them. For example, the remote computer could be... Figure 1The resource provider computer 25, application provider computer 40, transaction processing computer 60, and / or authorized entity computer 70. Furthermore, in embodiments where the location of the access device and the location of the communication device have associated timestamps, the communication device or a remote computer communicating with the communication device can compare these timestamps in step 230 to ensure they are within a predetermined threshold time period.

[0058] In an embodiment where the communication device determines whether the distance is within a predetermined threshold, the communication device may transmit an indicator to a remote computer indicating whether the distance is within the predetermined threshold. The indicator may simply be a binary value, such as 1 or 0 indicating "yes" or "no". Alternatively, the indicator may be the distance between the communication device and the access device (e.g., 50 feet, 2 miles, etc.). In an embodiment where the remote computer determines that the distance is within (or not within) the predetermined threshold, the communication device may transmit the location of the access device and the location of the communication device to the remote computer.

[0059] If the distance is within a predetermined threshold, the transaction can be processed in step 240A. Furthermore, in embodiments using timestamps, if each timestamp falls within a predetermined threshold time period, the transaction can be processed in step 240A. For example, a transaction may be indicated as authentic and sent via a transaction processing network for authorization. In some embodiments, transaction processing may include the generation and use of tokens corresponding to transaction-sensitive information.

[0060] If the distance is not within a predetermined threshold, the transaction can be rejected in step 240B. In other words, if the distance is not within a predetermined threshold, the transaction may not be authorized. Furthermore, in embodiments using timestamps, if each timestamp is not within a predetermined threshold time period, the transaction can be rejected in step 240B. For example, if the location of the accessed device was sent more than two days before the time the location of the communication device was determined, the transaction can be rejected because the two locations were not determined at times close to each other.

[0061] Although the illustrations and descriptions in the text indicate that the transaction is processed in step 240A and rejected in step 240B, it is conceivable that from... Figure 2 The steps performed can produce any number of different results. For example, in step 240B, the transaction can be flagged for further authentication processing before authorization. In another example, different business rules can be applied to the transactions in steps 240A and 240B.

[0062] Figure 3A block diagram of a communication device 300 according to some embodiments is shown. The communication device 300 can be used, for example, to implement... Figure 1 The communication device 10. The communication device 300 may include device hardware 304 coupled to memory 302. Device hardware 304 may include processor 305, communication subsystem 309, and user interface 306. In some embodiments, device hardware 304 may include display 307 (which may be part of user interface 306). Device hardware 304 may also include camera 308, which may be used for scanning codes as described herein. However, embodiments of the invention are not limited to being able to scan codes. For example, additional hardware and / or software components may be included in the communication device 300 to implement any communication protocol or technology for receiving codes, including RF (contactless), Bluetooth, IR (infrared), etc. Device hardware 304 may also include GPS 311, which may be used for determining the location of the communication device 300 as described herein. However, embodiments of the invention are not limited to GPS 311. Any suitable hardware and / or software may be included in the communication device 300 to determine the location of the communication device 300.

[0063] Processor 305 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of communication device 300. Processor 305 may execute various programs in response to program code or computer-readable code stored in memory 302, and may hold multiple concurrently executing programs or processes. Communication subsystem 309 may include one or more RF transceivers and / or connectors that may be used by communication device 300 to communicate with other devices and / or connect to external networks. User interface 306 may include any combination of input and output elements to allow a user to interact with communication device 300 and invoke the functions of the communication device. In some embodiments, user interface 306 may include components (e.g., display 307) that can be used for both input and output functions.

[0064] Memory 302 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), any other non-transitory storage media, or combinations thereof. Memory 302 may store an operating system (OS) 320 and an application environment 310 in which one or more applications (including application 312 to be executed by processor 305) reside.

[0065] Application 312 may be an application that uses, accesses, and / or stores sensitive information or tokens. For example, application 312 may be a wallet or payment application that uses a PAN or token to conduct transactions via communication device 300. In some implementations, user access to application 312 may be protected by user authentication data (such as passwords, PINs, etc.). For example, when a user attempts to launch or execute application 312, the user may be required to enter valid user authentication data before being able to access application 312. Application 312 may include a download manager 318, an encrypted module 314, a code determination module 316, and a distance module 317. In some implementations, one or more of these components may be provided by another application or component that is not part of application 312.

[0066] Download manager 318 can be configured to work with processor 305 to provide application providers associated with application 312 (e.g., Figure 1 The download manager 318 communicates with the application provider computer 405 to download information via the application provider. The download manager 318 may cooperate with the processor 305 to request or otherwise manage the acquisition and / or storage of sensitive information and / or tokens. For example, the download manager 318 may cooperate with the processor 305 to request and obtain sensitive information or tokens from the application provider associated with application 312, and store the sensitive information or tokens in a sensitive information data repository. In some embodiments, sensitive information or tokens provided by the application provider may be received in encrypted form. For example, the sensitive information or tokens may be encrypted using a session key generated by a token server. The download manager 318 may also cooperate with the processor 305 to receive a session key in encrypted form from the application provider and store the encrypted session key in the sensitive information data repository.

[0067] The ciphertext module 314 can cooperate with the processor 305 to provide ciphertext functionality for application 312. For example, the ciphertext module 314 can cooperate with the processor 305 to implement and perform encryption / decryption operations for application 312 using encryption algorithms such as DES, AES, or TDES / TDE A and / or hash functions such as SHA. For example, when application 312 accesses a data repository in memory 302 to retrieve and use sensitive information or tokens stored therein (e.g., to execute a transaction), application 312 can invoke the ciphertext module 314 to cooperate with the processor 305 to decrypt the session key used to encrypt the stored sensitive information or token, and then use the decrypted session key to decrypt the sensitive information or token. The decrypted sensitive information or token can then be used by application 312.

[0068] The code determination module 316 can cooperate with the processor 305 to interpret or translate the code scanned by the camera 308 into transaction data (including the location of the access device), as further described herein. The distance module 317 can cooperate with the processor 305 to determine whether the distance between the location of the access device (translated by the code determination module 316) and the location of the communication device 300 (e.g., determined by GPS 311) is within a predetermined threshold, for example, a threshold specified by application 312. The distance module 317 can further cooperate with the processor 305 to generate data indicating whether the distance is within the predetermined threshold.

[0069] Figure 4 A block diagram of an application provider computer 400 associated with an application provider according to some embodiments is shown. For example, the application provider computer 400 may be a software application or service that provides an application associated with the communication device 10. Figure 1 Application provider computer 400. Application provider computer 400 may include processor 401 coupled to network interface 402 and computer-readable medium 406. In some embodiments, application provider computer 400 may also include hardware security module (HSM) 420. Application provider computer 400 may also include user database 403 or otherwise access to user database, which may be internal or external to application provider computer 400.

[0070] Processor 401 may include one or more microprocessors to run program components for performing token request functions of application provider computer 400. Network interface 402 may be configured to connect to one or more communication networks to allow application provider computer 400 to communicate with other entities, such as user-operated communication devices, token server computers, etc. Computer-readable medium 406 may include any combination of one or more volatile and / or non-volatile memories, such as RAM, DRAM, SRAM, ROM, flash memory, or any other suitable memory component. Computer-readable medium 406 may store code executable by processor 401 to implement some or all of the functions in the token request function of application provider computer 400. For example, computer-readable medium 406 may include code implementing registration module 410, token request module 408, and distance module 409. In some embodiments, application provider computer 400 may also include a hardware security module (HSM) 420 for implementing ciphertext engine 422.

[0071] Registration module 410 can cooperate with processor 401 to register users with application provider computer 400. For example, users can be registered with the application provider by providing the registration module 410 with: identification information for identifying the user; device information, such as a device identifier associated with the user's communication device (on which the application associated with the application provider is installed); and account information, such as an account identifier associated with the user's account. In some embodiments, users can set user authentication data (e.g., password, PIN, etc.) through registration module 410. When the application on the user's communication device communicates with application provider computer 400, application provider computer 400 can use the user authentication data to authenticate the user. Registration module 410 can cooperate with processor 401 to allow users to change or update user authentication data. Registration information can be stored in user database 403. In some embodiments, the registration process can be performed when a user first downloads an application for installation on their communication device, or when a user first launches and executes the application.

[0072] Token request module 408 is configured to cooperate with processor 401 to facilitate receiving requests for sensitive information or tokens from applications installed on a user's communication device. In some embodiments, upon receiving a request from an application on the user's communication device, token request module 408 may cooperate with processor 401 to authenticate the user and / or communication device by verifying user authentication data and the communication device's device identifier against previously registered information stored in user database 403. Subsequently, token request module 408 may cooperate with processor 401 to request sensitive information or a token from a token server for use on the communication device. Upon receiving sensitive information or a token from the token server, token request module 408 may cooperate with processor 401 to send the sensitive information or token to the application running on the communication device. In some embodiments, token request module 408 may also cooperate with processor 401 to track which sensitive information or token is provided to a particular communication device by storing such information in user database 403. Therefore, user database 403 may include a mapping between communication devices and the sensitive information or tokens supplied to those communication devices.

[0073] In some implementations, the distance module 409 may cooperate with the processor 401 to determine whether the distance between the location of the access device and the location of the communication device (received from the communication device) is within a predetermined threshold. The distance module 409 may further cooperate with the processor 401 to generate data indicating whether the distance is within the predetermined threshold.

[0074] Ciphertext engine 422 can cooperate with processor 401 to provide ciphertext functionality to application provider computer 400. In some implementations, ciphertext engine 422 can be implemented in HSM 420, which is a dedicated hardware component for performing ciphertext operations and managing ciphertext keys. Ciphertext engine 422 can cooperate with processor 401 to implement and perform encryption / decryption operations of application provider computer 400 using encryption algorithms such as AES, DES, TDES / TDEA, or other suitable encryption algorithms using ciphertext keys of any length (e.g., 56 bits, 128 bits, 169 bits, 192 bits, 256 bits, etc.). In some implementations, ciphertext engine 422 can also perform hash calculations using hash functions such as Secure Hash Algorithm (SHA). For example, when application provider computer 400 receives a session key for encrypting sensitive information or a token from a token server, application provider computer 400 can invoke ciphertext engine 422 to encrypt the session key, thereby enabling the session key to be provided in encrypted form to applications on the communication device. In some implementations, a hash value can be used to encrypt the session key, the hash value being calculated using user authentication data associated with the user requesting the sensitive information or token.

[0075] Figure 5 It is a token server 500 according to some embodiments of the present invention. Figure 1 A block diagram of a token server 30). In some embodiments, one or more token server computers 500 may be used to implement a network token system, for example. The token server computer 500 may include a processor 501 coupled to a network interface 502 and a computer-readable medium 506. In some embodiments, the token server computer 500 may also include a hardware security module (HSM) 520. The token server computer 500 may also include a token registration file 504 that may be located inside or outside the token server computer 500.

[0076] Processor 501 may include one or more microprocessors to run program components for performing token management functions 530 of token server computer 500. Network interface 502 may be configured to connect to one or more communication networks, thereby allowing token server computer 500 to communicate with other entities, such as user-operated communication devices, application provider computers or token request computers, merchant computers, acquiring computers, transaction processing network computers, issuing computers, etc. Computer-readable medium 506 may include any combination of one or more volatile and / or non-volatile memories, such as RAM, DRAM, SRAM, ROM, flash memory, or any other suitable memory component. Computer-readable medium 506 may store code executable by processor 501 to implement some or all of the functions of token management functions 530 of token server computer 500 described herein. For example, computer-readable medium 506 may include: a requester registration module 508, a user registration module 510, a token generation module 512, a verification and authentication module 514, a token exchange and routing module 516, and a token lifecycle management module 518.

[0077] The requester registration module 508 can register token requester entities (e.g., application providers) with the token registration file 504 and generate a token requester identifier (ID) for the registered entities. Each registered entity can use its corresponding token requester ID as part of a token service request to facilitate the identification and verification of the entity. In some implementations, the token requester entity can provide the requester registration module 508 with token requester information such as entity name, contact information, entity type (e.g., merchant, wallet provider, payment service provider, issuer, payment enabler, acquirer, etc.). In some implementations related to tokens and transactions, the token requester information may also include the token presentation mode (e.g., scanning, contactless, e-commerce, etc.), token type (e.g., static / dynamic, payment / non-payment), integration and connectivity parameters, and subscribed services (e.g., token requesting, authentication and verification, lifecycle management, etc.) and any other relevant information for onboard processes.

[0078] User registration module 510 can perform user and user account registration. In some embodiments, token server computer 500 may allow authorized entities to register consumer accounts (e.g., payment or financial accounts) on behalf of users with the network token system. For example, a registered token requester may provide: a token requester ID (e.g., received from requester registration module 508 at the time of registration), an account identifier or other sensitive information or sensitive information identifier that the token can substitute for, the consumer's name and contact information, the device identifier of the consumer's communication device, the token type, and any other relevant information for individual or bulk account registration. In some embodiments, user registration module 510 may store account details and sensitive information in token registration file 504 for use in all successful activation and registration requests. In some embodiments, authorized entities may also deregister users and accounts by providing the necessary information to token server computer 500.

[0079] The token generation module 512 can be configured to cooperate with the processor 501 to generate a token or retrieve sensitive information in response to a request for a token or sensitive information from a token requester (e.g., an application provider). Furthermore, the token generation module 512 can be configured to generate verification values ​​such as CVN and TAVV. In some embodiments, the token generation module 512 may receive a token requester ID and an account identifier or sensitive information identifier. In some embodiments, the token generation module 512 may also receive optional information such as user name, user address and postal code, the type of token or sensitive information requested (e.g., static, dynamic, non-payment, etc.), device identifier, and / or appropriate information. In some embodiments, the token generation module 512 may generate a response containing the requested token or requested sensitive information, a token validity date associated with the token, and / or a token security level associated with the token. In some embodiments, the token generation module 512 may verify the token requester ID and retain the token, the sensitive information or account identifier replaced by the token, and the associated token requester. In some implementations, the token generation module 512 may determine whether a token for a given token request already exists in the token registration file 504 before generating a new token. In some implementations, if a token cannot be supplied, the token response may include a corresponding reason code. In some implementations, the token generation module 512 may also provide an interface for token requesters to submit bulk token request files.

[0080] In some implementations, tokens can be generated on the fly using API calls. For example, upon receiving a request to tokenize an account identifier or other sensitive information, the token generation module 512 can determine the token range to be allocated. The token range can be allocated based on whether an issuer is supplying tokens (e.g., the token range allocated by the issuer) or whether a transaction processing network is supplying tokens on behalf of the issuer (e.g., the token range allocated by the transaction processing network). As an example, if the token range allocated by the transaction processing network includes "442400000-442400250", then "4424000000005382" can be allocated as the token value. The token registry 504 can store the relationship between the token range and the account identifier and can record token additions. In some implementations, the token generation module 512 can consider a list of token ranges associated with the account identifier range before allocating the token.

[0081] The verification and authentication module 514 can be configured to perform a consumer verification and authentication process and determine a token security level based on the results of the verification and authentication process. For example, the verification and authentication module 514 can perform consumer authentication and verification using a configured authentication scheme. In some embodiments, the authentication scheme may include verifying an account identifier, verification value, and expiration date based on customer information stored in a database associated with the transaction processing network. In some embodiments, the authentication scheme may include the issuer directly verifying the consumer using consumer credentials from its online banking system.

[0082] In some implementations, the authentication scheme may include verifying consumer credentials through the issuer's ACS (Access Control Server). For example, the issuer's ACS service may be as follows: The given 3D security protocol includes an authentication protocol segment. The ACS server can be associated with an issuer that may include registered consumer accounts and access information. The ACS can empower the issuer to authenticate consumers during online purchases, thereby reducing the likelihood of fraudulent use of consumer accounts. For example, the ACS can verify that a consumer is registered, perform consumer verification at the time of a transaction, and provide the merchant with a digitally signed response. In some implementations, the authentication scheme may include using a transaction processing network consumer authentication service (e.g., Visa). TM Consumer Authentication Service (VCAS) verifies accounts. For example, the VCAS service can authenticate consumers on behalf of the publisher before the authorization process.

[0083] In some implementations, user registration, token generation, and verification and authentication can be performed as part of a single token request process. In some implementations, for bulk requests, user registration and token generation can be performed by processing bulk files from the token requester. In such implementations, consumer verification and authentication can be performed in separate steps. In some implementations, the token requester can request multiple independent executions of the authentication and verification process for a specific account to reflect any changes in the token's security level over time.

[0084] The token exchange and routing module 516 can cooperate with the processor 501 to process requests for any implicitly sensitive information (e.g., account identifier) ​​associated with a given token. For example, a transaction processing computer, acquirer, issuer, etc., may issue a request for token exchange during transaction processing. The token exchange and routing module 516 can cooperate with the processor 501 to verify that the requesting entity is authorized to issue the request for token exchange. In some embodiments, the token exchange and routing module 516 can cooperate with the processor 501 to verify the mapping of the account identifier (or other sensitive information) to the token and the presentation mode based on the transaction timestamp and the token expiration timestamp. The token exchange and routing module 516 can cooperate with the processor 501 to retrieve the account identifier (or other sensitive information) from the token registration file 504 and provide it to the requesting entity along with an assurance level. In some embodiments, an error message can be provided if the mapping of the account identifier (or other sensitive information) to the token is invalid for the transaction timestamp and presentation mode.

[0085] The token lifecycle management module 518 can collaborate with the processor 501 to perform lifecycle operations on tokens managed by the token server computer 500. Lifecycle operations can include canceling a token, activating or deactivating a token, updating token attributes, updating a token with a new validity date, etc. In some implementations, a token requester entity can provide the token server computer 500 with a token requester ID, token number, lifecycle operation identifier, and one or more token attributes to perform the requested lifecycle operation on a given token. The token lifecycle management module 518 can collaborate with the processor 501 to verify the token requester ID and token association based on information in the token registration file 504. The token lifecycle management module 518 can collaborate with the processor 501 to perform the requested lifecycle operation on a given token and update the corresponding association in the token registration file 504. Examples of lifecycle operations can include a token activation operation to activate an inactive, suspended, or temporarily locked token and its associated tokens; a token deactivation operation to temporarily lock or suspend a token; a token cancellation operation to permanently mark a credential and its associated tokens as deleted to prevent any future transactions, etc. In some implementations, if the same token is used to submit the corresponding original transaction, the deleted token can be used during the return / refund process.

[0086] According to some implementations, the token server computer 500 may include an HSM 520 to perform security functions, such as encryption and decryption operations and the generation of ciphertext keys for encryption and decryption operations. For example, the HSM 520 may include a ciphertext engine 522 to perform encryption algorithms, such as AES, DES, TDES / TDEA, or other suitable encryption algorithms using ciphertext keys of any length (e.g., 56 bits, 128 bits, 169 bits, 192 bits, 256 bits, etc.). The HSM 520 may also implement a session key generator 524 to generate a session key for each token or sensitive information request processed by the token server computer 500. The generated session key can be used to encrypt the token or sensitive information generated or retrieved for the request, and the token or sensitive information can be provided to the token requester in encrypted form. For example, for each request received and processed by the token server computer 500, the session key generator 524 may generate a session key unique to each request received from a particular token requester, or a session key unique to each request associated with a particular user or account. In some implementations, the session key may be the same as or different from the encryption key used to establish a secure communication channel (e.g., TLS, SSL, etc.) between the token requester and the token server computer 500. The token generation module 512 may generate or retrieve a token or sensitive information to satisfy the request. The ciphertext engine 522 may encrypt the token or sensitive information using the session key and an encryption algorithm, and the encrypted token or sensitive information may be provided to the token requester. In some implementations, the generated session key will also be provided to the token requester along with the encrypted token or sensitive information.

[0087] Although the token server computer 500 and the application provider computer 400 are described with only some of their functions implemented in the HSM, it should be understood that other functions of each computer (e.g., token generation) may also be implemented within the HSM. Furthermore, some or all of the corresponding HSM functions may also be implemented outside the HSM.

[0088] The systems and methods described herein can be implemented in a wide variety of contexts. For example, to complete a payment transaction, a merchant can electronically generate a code representing transaction data (e.g., merchant data, merchant location data, transaction amount, etc.) and display it on an access device. For example, the code could be a QR code. A user can scan the code using their communication device with a camera or other visual sensor associated with that communication device. In one implementation, the code can be interpreted by an application on the communication device, and the transaction data can be displayed to the consumer. The consumer can request a token at the communication device corresponding to the payment device selected to execute the payment transaction. The token, transaction data, and consumer location can be provided to an application provider computer. If the consumer's location is within a predetermined threshold distance of the merchant's location, the application provider computer can use the transaction data and token to facilitate the completion of the transaction between the consumer and the merchant, as further described herein.

[0089] The system and methods described in this article can also be used to access transactions. For example, Figure 6 A block diagram of a building access system according to some embodiments of the present invention is shown. User 606 can access a communication device 610 (e.g., [missing information]) containing sensitive information (e.g., access code). Figure 1 Communication equipment 10 and / or Figure 3 The communication device 610 operates with the access device 615. The communication device 610 can interact with the access device 615 to receive the location of the access device 615. In some embodiments, the communication device 610 can determine its own current location and determine whether the distance between the location of the access device 615 and the location of the communication device 610 is within a predetermined threshold. If the distance is within the predetermined threshold, then the communication device 610 can transmit sensitive information to the access device 615.

[0090] Access device 615 can perform local analysis of sensitive information to determine whether access to building 670 should be permitted, or access device 615 can communicate with a server computer (not shown) located remotely. The server computer located remotely can analyze the sensitive information to determine whether access to building 670 should be permitted, and can transmit a signal indicating this result back to access device 615. Access device 615 can then, based on the sensitive information, grant or deny user 606 access to building 670.

[0091] A computer system can be used to implement any of the entities or components described above. Subsystems of the computer system can be interconnected via a system bus. Additional subsystems, such as printers, keyboards, fixed disks (or other memory including computer-readable media), monitors coupled to display adapters, and others, can be used. Peripherals and input / output (I / O) devices coupled to an I / O controller (which may be a processor or any suitable controller) can be connected to the computer system via any means known in the art, such as a serial port. For example, a serial port or external interface can be used to connect the computer device to a wide area network such as the Internet, a mouse input device, or a scanner. Interconnection via the system bus allows the central processing unit to communicate with each subsystem and control the execution of instructions from system memory or fixed disks, as well as the exchange of information between subsystems. System memory and / or fixed disks can embody computer-readable media. In some embodiments, the monitor may be a touch-sensitive display.

[0092] A computer system may include multiple identical components or subsystems connected together, for example, via external or internal interfaces. In some implementations, the computer system, subsystem, or device may communicate via a network. In this case, one computer may be considered a client and another a server, where each computer may be part of the same computer system. The client and server may each comprise multiple systems, subsystems, or components.

[0093] It should be understood that any embodiment of the present invention can be implemented in a modular or integrated manner using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or computer software in the form of control logic via a general-purpose programmable processor. As used herein, the processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units or networks on a single circuit board. Based on the disclosure and teachings provided herein, those skilled in the art will recognize and appreciate other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0094] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language (such as, for example, Java, C, C++, C#, Objective-C, Swift) or scripting language (such as Perl or Python) employing techniques such as conventional or object-oriented methods. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or DVDs (Digital Universal Discs), flash memory, etc. The computer-readable medium can be any combination of these storage or transmission devices.

[0095] 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 embodiments of the invention can be created using data signals encoded with such a program. Computer-readable media encoded with program code can be packaged using compatible means or provided separately from other means (e.g., for download 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. The computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0096] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon 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 and their full scope or equivalents.

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

[0098] Unless explicitly indicated otherwise, the use of the terms "a," "an," or "the / described" is intended to mean "one / a kind or a plurality of / kinds."

[0099] Similar reference numerals are used throughout the accompanying drawings to denote similar elements.

Claims

1. A method for implementing a transaction between a user and a resource provider, the method comprising: An access device of a resource provider system associated with the resource provider provides the user's communication device with code including transaction data for the transaction, the code providing the transaction data to an application provider computer, and the application provider computer providing the transaction data and a transaction identifier to a token server; as well as The access device transmits the transaction data and the transaction identifier to the resource provider computer in the resource provider system, whereby the resource provider computer then... Use the transaction identifier to retrieve the token from the token server. Construct an authorization request message including the transaction data and the token, and The authorization request message, which includes the transaction data and the token, is transmitted to the transaction processing computer. Sensitive information associated with the token is retrieved from the token server, and authorization for the transaction is obtained.

2. The method according to claim 1, further comprising: The resource provider's computer receives an authorization response message for the transaction from the transaction processing computer via a transmission computer.

3. The method of claim 1, wherein the application provider's computer hosts a digital wallet application that operates on the communication device.

4. The method according to claim 1, wherein the access device is a POS terminal.

5. The method of claim 1, wherein, The code is a QR code.

6. The method of claim 1, wherein obtaining authorization for the transaction comprises sending the authorization request message containing sensitive information associated with the token to an authorization entity computer for authorization.

7. The method of claim 6, wherein the sensitive information includes PAN.

8. The method of claim 1, wherein the user's communication device further provides the location or address of the access device to the application provider's computer.

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

10. A resource provider system, comprising: An access device, the access device including a first processor and a first non-transitory computer-readable medium, the first non-transitory computer-readable medium including code executable by the first processor to cause the access device to perform operations, the operations including... The system provides the user's communication device with code including transaction data for the transaction. This code then provides the transaction data to the application provider's computer, which in turn provides the transaction data and a transaction identifier to a token server. The access device transmits the transaction data and the transaction identifier to the resource provider computer in the resource provider system; as well as The resource provider computer, the resource provider computer including a second processor, and a second non-transitory computer-readable medium, the second non-transitory computer-readable medium including code executable by the second processor to cause the resource provider computer to perform operations including... The resource provider's computer retrieves the token from the token server using the transaction identifier. The resource provider's computer constructs an authorization request message including the transaction data and the token, and The resource provider computer transmits the authorization request message, which includes the transaction data and the token, to the transaction processing computer, retrieves sensitive information associated with the token from the token server, and obtains authorization for the transaction.

11. The resource provider system according to claim 10, wherein the access device is a POS terminal.

12. The resource provider system of claim 10, wherein the sensitive information includes PAN.

13. The resource provider system of claim 10, wherein the token is in the same format as the sensitive information.

14. The resource provider system according to claim 10, wherein, The code is a QR code.

15. The resource provider system of claim 14, wherein the location of the access device is embedded in the QR code.

16. A method comprising: The token server receives a message from the application provider's computer, the message including a transaction identifier; The token server receives a request for the token from the resource provider's computer, and the request for the token includes the transaction identifier; The token is determined by the token server based on the transaction identifier; as well as The token server provides the token to the resource provider computer, which then constructs an authorization request message including the token and transaction data to submit to the transaction processing computer.

17. The method of claim 16, wherein the transaction data includes transaction volume.

18. The method of claim 16, wherein the message includes sensitive information associated with the communication device.

19. The method of claim 18, wherein the length of the token is sixteen digits.

20. The method of claim 18, further comprising: The token server receives a request, including the token, from the transaction processing computer to obtain sensitive information; as well as The token server provides the sensitive information to the transaction processing computer.

Images