Multi-device authentication method and system using cryptographic techniques

Abstract

In a system for verifying transactions, when a user with a portable communication device approaches a resource provider location, the portable communication device provides an indication of its proximity to the location to a transaction processing system. Subsequently, the portable communication device provides a universally unique identifier (UUID) of a base station of the resource provider to the transaction processing system, which generates a hash using the UUID and a primary account number (PAN) of a portable transaction device associated with the portable communication device. When the user transacts with the portable transaction device at the provider, the provider generates a separate hash from the UUID and the PAN and sends the hash to the transaction processing system. A match between the hashes is considered a positive indication that the transaction is not fraudulent and that the resource provider is in compliance with the system.

Description

[0001] This application is a continuation-in-part of International Application No. PCT / US2016 / 044832, International Filing Date, July 29, 2016, entitled "Multi-Device Authentication Method and System Using Cryptographic Techniques," which entered the National Stage in the United States as U.S. Patent Application No. 15 / 882, 102, filed on January 31, 2018, which claims priority to U.S. Provisional Patent Application No. 62 / 421, 1 12, filed on November 14, 2016. BACKGROUND

[0002] Electronic access transactions are vulnerable to fraud. For example, a credit card can be stolen or counterfeited and used in a fraudulent card transaction at a merchant, even if the true owner of the card is not at the merchant. In another example, an individual's access badge can be stolen, and an unauthorized person can attempt to enter a location that they are otherwise not authorized to enter.

[0003] With respect to fraudulent payment transactions, merchants are reportedly losing over $190 billion per year to credit card fraud. Additionally, the ability of an unauthorized user to access locations or data that they are not authorized to access can present insurance and security risks.

[0004] Security can be improved by simply implementing more and more authentication processes. However, this is undesirable because implementing too many authentication processes can prevent legitimate users from making legitimate transactions. For example, requiring a user to remember multiple passwords to make a single transaction can be frustrating to the user, such that the user can simply not want to transact again.

[0005] Despite the existence of systems that employ two-factor authentication to prevent fraud, these systems can require participating merchants to perform a registration process that can involve transmitting or creating an identifier that is unique to the merchant for each participating merchant. In situations involving a large number of merchants, creating and maintaining an infrastructure (e.g., a database and a registration staff) to manage merchant-specific identifiers can be burdensome. Additionally, the registration requirements can discourage other merchants from participating in the system.

[0006] Furthermore, while many existing anti-fraud systems can be dedicated to preventing fraudulent transactions caused by consumers and / or other non-merchant actors, these same systems can trust merchant actors to correctly perform certain operations of the anti-fraud system without actually verifying that these operations are in fact performed correctly. Thus, such systems can be unable to detect malicious merchants or non-compliant merchants that are participating in fraudulent behavior.

[0007] Embodiments of the present invention address this and other problems, individually and collectively. SUMMARY

[0008] Embodiments of the invention relate to systems and methods for ensuring that a transaction is conducted by an authorized user and ensuring that a resource provider is not acting in an unsecure or fraudulent manner, wherein the systems and methods obviate the need for resource provider registration.

[0009] One embodiment of the invention relates to a method. The method includes receiving, by a server computer, device information from a user's portable communication device, a base station identifier uniquely identifying a resource provider location, and a first cryptogram formed by hashing at least a credential or token; hashing, by the server computer, at least the first cryptogram and the base station identifier to form a second cryptogram; receiving, by the server computer, an authorization request message including at least a portion of the second cryptogram from an access device in a transaction; and analyzing, by the server computer, the authorization request message to determine that the user of the portable communication device is also conducting the transaction at the access device.

[0010] Other embodiments of the invention relate to one or more server computers, each server computer including: a processor; and a computer readable medium including code executable by the processor to implement the above-described method.

[0011] These and other embodiments of the invention are described in further detail below. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 FIGURES illustrate systems and process flows in accordance with embodiments of the invention.

[0013] Figure 2 A block diagram illustrating a system in accordance with some embodiments of the invention is described.

[0014] Figure 3 A block diagram illustrating a portable communication device in accordance with embodiments of the invention is described.

[0015] Figure 4 A block diagram illustrating an exemplary transaction processing system in accordance with embodiments of the invention is described.

[0016] Figure 5 A flow diagram illustrating a hash matching process in accordance with embodiments of the invention is described. DETAILED DESCRIPTION

[0017] Embodiments of the invention provide techniques for verifying transactions based on the presence of a user's portable communication device at a location, such as a resource provider location. By way of illustration, in embodiments of the invention, when a user enters a merchant store with a portable communication device, the portable communication device provides an indication to a transaction processing system that the portable communication device is currently at the merchant location. Later, when the user conducts a transaction through a portable transaction device (which can be separate and distinct from the portable communication device), the fact that the user's portable communication device was detected at the merchant store not long ago is considered as a positive indication that the transaction is not fraudulent. In addition, during the transaction, the merchant store generates a cryptogram and transmits the cryptogram to the transaction processing system, which is used to verify that the merchant complied with the transaction verification process. Embodiments of the invention can verify that, for a given transaction, both the portable communication device and the portable transaction device were present at the merchant before the transaction can be authorized, and that the merchant was able to correctly generate a cryptogram associated with the transaction, thereby reducing the risk of fraudulent transactions by the user and the merchant.

[0018] According to some embodiments, a process for verifying a transaction can include the following steps. When a user with a portable communication device approaches a beacon associated with a merchant store, the portable communication device transmits its device information to a transaction processing system in response to being awakened from receiving a transmission from the beacon. The transaction processing system retrieves a primary account number (PAN) and a PAN expiration date of a portable transaction device associated with the portable communication device, and generates a first cryptogram using this information and one or more random numbers. The transaction processing system then transmits the first cryptogram and the one or more random numbers to the portable communication device. The portable communication device then connects to a base station also associated with the merchant store, and receives a universally unique identifier (UUID) built into the base station from the base station.

[0019] The portable communication device generates a second cryptogram from the first cryptogram and the UUID, and transmits the second cryptogram and the one or more random numbers to the base station. The portable communication device also transmits the UUID to the transaction processing system. In response to receiving the UUID, the transaction processing system locally generates its own second cryptogram using the first cryptogram and the UUID.

[0020] Later, when the user conducts a transaction through a portable transaction device (which can be separate and distinct from the portable communication device) at a payment terminal of a merchant store, the payment terminal can obtain the PAN and the expiration date from the portable transaction device. The payment terminal or a device external to the payment terminal can then generate its own first cryptogram from the PAN and the expiration date, generate its own second cryptogram from the first cryptogram and the UUID, and determine whether there is a match among the patterns received by the base station in the recent years. If a match is found, the payment terminal can forgo other cardholder verification methods (CVMs) (e.g., omit prompting the user to enter a PIN or sign) and transmit at least a portion of the second cryptogram to the transaction processing system through an authorization request message. The transaction processing system then determines whether any pattern that the transaction processing system recently generated for the PAN matches the received portion. If a match is found, it can be determined that the portable communication device was present when the transaction was conducted, the user of the portable transaction device is thereby authenticated and in fact authorized to use the portable transaction device, and the merchant is in compliance.

[0021] Although the various specific examples described below relate to payments, embodiments of the application can be applicable to other types of transactions, including physical location access transactions (e.g., a transaction in which a user can wish to enter a venue such as a train station) and data request access transactions (e.g., a transaction in which a user can wish to access information about their airplane flight at a self-service terminal at an airport).

[0022] Before discussing details of some embodiments of the application, a description of some terminology can be helpful in understanding the various embodiments.

[0023] A "portable communication device" can be a portable device that can be transported and operated by a user, and can include one or more electronic components (e.g., integrated chips, etc.). A portable communication device according to embodiments of the application can take any suitable form, including but not limited to, a mobile phone (e.g., a smart phone, a cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant device (PDA), a wearable communication device (e.g., a watch, a bracelet, glasses, etc.), an e-reader device, a laptop computer, a netbook, an ultrabook, etc. A portable communication device can also take the form of a vehicle (e.g., an automobile) equipped with communication capabilities.

[0024] A portable communication device according to embodiments of the application can be configured to communicate with external entities, e.g., a remote communication gateway, through remote communication technologies and protocols. The portable communication device can also be configured to communicate with external entities, e.g., an access device, using any suitable short-range or mid-range communication technologies, including Bluetooth (classic and BLE - Bluetooth Low Energy), NFC (Near Field Communication), IR (Infrared), Wi-Fi, etc.

[0025] A "portable transaction device" can be a portable device that can be used to conduct transactions. The portable transaction device can include storage technology (e.g., electronic memory, magnetic stripe, etc.) for storing credentials or tokens associated with a user account. The portable transaction device can take any of the forms described above with respect to the portable communication device, or the form of a card (e.g., an integrated chip card, a magnetic stripe card), or a fob, etc. In some embodiments, the portable transaction device and the portable communication device can be the same device, and need not be separate devices. Particular examples of portable transaction devices can include wearable devices, payment cards (e.g., credit cards, debit cards, and prepaid cards), vehicles with remote communication capabilities, etc.

[0026] A "server computer" can include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers acting as a unit. In one example, the server computer can be a database server coupled to a Web server. The server computer can comprise one or more computational apparatuses and can use any of a number of computer operating structures, arrangements, and compilations to serve requests from one or more client computers.

[0027] An "access device" can be any suitable device for providing access to an external computer system. The access device can take any suitable form. Some examples of access devices include a point-of-sale (POS) device, a cellular phone, a PDA, a personal computer (PC), a tablet, a hand-held specialized reader, a set-top box, an electronic cash register (ECR), an automated teller machine (ATM), a virtual cash register (VCR), a kiosk, a security system, an access system, a website, etc. The access device can use any suitable contact or contactless mode of operation to send or receive data from or associated with the portable communication device. In some embodiments where the access device can comprise a POS terminal, any suitable POS terminal can be used and any suitable POS terminal can include a reader, a processor, and a computer- readable medium. The reader can include any suitable contact or contactless mode of operation. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader for interacting with the portable communication device.

[0028] An "authorization request message" can be an electronic message sent to request authorization for a transaction. An authorization request message can be sent to a payment processing network and / or an issuer of a payment card. An authorization request message according to some embodiments can comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users using payment devices or payment accounts. An authorization request message can contain information that can be used to identify an account. An authorization request message can also include additional data elements, such as one or more of a service code, an expiration date, and the like. An authorization request message can also include transaction information, such as any information associated with a current transaction, such as a transaction amount, a merchant identifier, a merchant location, and the like, as well as any other information that can be used to determine whether to identify and / or authorize a transaction. An authorization request message can also contain other information, such as information identifying an access device that generated the authorization request message, information about a location of the access device, and the like.

[0029] An "authorization response message" can be an electronic message reply to an authorization request message. An authorization response message can be generated by an issuing financial institution or a payment processing network. By way of example only, an authorization response message can contain one or more of the following status indicators: approved - the transaction was approved; declined - the transaction was not approved; or call center - more information is pending a response, the merchant must call a toll-free authorization phone number. An authorization response message can also contain an authorization code, which can be a code returned to a merchant computer by a credit card issuing bank in response to an authorization request message in an electronic message (either directly or through a payment processing network) indicating that a transaction was approved. The code can be used as evidence of authorization.

[0030] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authorization. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identity cards, notarized documents, access cards, passwords and other login information, and the like.

[0031] A "value credential" can be information associated with a value. Examples of value credentials include payment credentials, coupon identifiers, information needed to obtain promotional offers, and the like.

[0032] A "payment credential" can contain any suitable credential that can be used to make a payment transaction. This information can be directly related to an account, or can be derived from information related to an account. Examples of account information can include a PAN (primary account number or "account number"), a user name, an expiration date, a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, and the like

[0033] An "application" can be computer code or other data stored on a computer- readable medium (e.g., a memory element or a secure element) that can be executable by a processor to accomplish a task.

[0034] A "token" can be a substitute value for 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, and the like.

[0035] A "payment token" can include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and / or an expiration date. For example, a token can include a string of alphanumeric characters that can be used as a substitute for an original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the PAN "4147 0900 0000 1234." In some embodiments, a token can be "reserved format" and can have a numeric format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, a token can be used in place of a PAN to initiate, authorize, process, or settle a payment transaction, or to represent an original credential in other systems that would normally provide the original credential. In some embodiments, a token value can be generated such that a recovery of the original PAN or other account identifier from the token value cannot be derived computationally. Further, in some embodiments, the token format can be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0036] "Tokenization" is the process of substituting data with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) can be tokenized by substituting a substitute number (e.g., a token) that can be associated with the payment account identifier in place of the primary account identifier.

[0037] A "token provider" or "token service system" can include a system that serves payment tokens. In some embodiments, a token service system can facilitate requesting, determining (e.g., generating), and / or issuing tokens, as well as maintaining established mappings of tokens to primary account numbers (PANs) in a repository (e.g., a token vault). In some embodiments, a token service system computer can establish a token assurance level for a given token to indicate a confidence in the token's binding to a PAN. A token service system can include or be in communication with a token vault that stores generated tokens. A token service system can support token processing for payment transactions submitted using tokens by having tokens detokenized to obtain the actual PAN. In some embodiments, a token service system can include a separate tokenization computer, or include a tokenization computer in combination with other computers, such as transaction processing network computers. Various entities of the tokenization ecosystem can assume the role of a token service provider. For example, a payment network and an issuer or its agent can become a token service provider by implementing token services in accordance with embodiments of the application.

[0038] A "token domain" can indicate an area and / or environment in which a token can be used. Examples of token domains can include, but are not limited to, a payment channel (e.g., e-commerce, physical point-of-sale, etc.), a POS entry mode (e.g., contactless, magnetic stripe, etc.), and a merchant identifier, thereby uniquely identifying where the token can be used. A set of parameters (i.e., token domain restriction controls) can be established by a token service provider as part of token issuance that can allow for enforcement of proper use of a token in a payment transaction. For example, a token domain restriction control can restrict use of a token in a particular presentation mode (e.g., a contactless or e-commerce presentation mode). In some embodiments, a token domain restriction control can restrict use of a token at a particular merchant that can be uniquely identified. Some example token domain restriction controls can require verification of the presence of a token cryptogram that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.

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

[0040] A "token request message" can be an electronic message used to request a token. The token request message can contain information that can be used to identify a payment account or digital wallet and / or information used to generate a payment token. For example, the token request message can contain payment credentials, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information contained in the token request message can be encrypted (e.g., using issuer-specific keys).

[0041] A "token response message" can be a message that responds to a token request. The token response message can contain an indication that the token request was approved or declined. The token response message can also contain a payment token, mobile device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information contained in the token response message can be encrypted (e.g., using issuer-specific keys).

[0042] A "resource provider" can be an entity that can provide a resource, such as a good, a service, information, and / or access. Examples of resource providers include merchants (e.g., a supermarket), data providers such as a government agency, a transportation agency (e.g., a train station), and the like. A "merchant" can generally be an entity that engages in a transaction and can sell or offer access to goods or services.

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

[0044] An "authorization entity" can be an entity that authorizes a request. Examples of authorization entities can be an issuer, a government agency, a document repository, an access administrator, and the like. An authorization entity can operate an authorization computer. An "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 that are stored on a user device, such as a cellular phone, a smart card, a tablet computer, or a laptop computer.

[0045] An "account identifier" can include an identifier of an account. An account identifier can include an original account identifier associated with a payment account. For example, a real account identifier can be a primary account number (PAN) issued by an issuer for a card account (e.g., a credit card, a debit card, etc.). For example, in some embodiments, a real account identifier can include a sixteen-digit numeric value, such as "4147 0900 0000 1234." The first six digits of a real account identifier (e.g., "414709") can represent a real issuer identifier (BIN) that can identify an issuer associated with the real account identifier.

[0046] A "key" can refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into a substitute representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of encryption algorithms can include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), etc.

[0047] A "cryptogram" can include a piece of data that is cryptographically secure. Examples of cryptograms can include a cryptographic hash, encrypted data, etc.

[0048] Figure 1 A system 100 according to embodiments of the application is described. The system 100 can be used to authenticate a user attempting to use a portable transaction device to conduct a transaction at a resource provider location.

[0049] The system 100 includes a portable communication device 102 (e.g., a mobile phone), a beacon 101 (e.g., an in-venue BLE beacon), a base station 104 (e.g., an in-venue BLE base station or controller), an access device 106 (e.g., an in-venue POS terminal), a portable transaction device 108 (e.g., a card), and a transaction processing system 110.

[0050] The beacon 101 can perform a periodic broadcast that is received by the portable communication device 102 within range. The transaction processing system 110 can communicate with the portable communication device 102 and the access device 106. The base station 104 can communicate with the portable communication device 102 and the access device 106.

[0051] A user (not shown) can operate the portable communication device 102 and the portable transaction device 108. The portable communication device 102 can be a mobile phone, and the portable transaction device 108 can be a credit card or a debit card. If the user is authentic, then the beacon 101, the portable communication device 102, the portable transaction device 108, the access device 106, and the base station 104 will all be at the same location (e.g., the same resource provider, the same venue entrance, etc.).

[0052] The communication between the portable communication device 102 and the transaction processing system 110 can be performed using a secure communication protocol, such as a Transport Layer Security protocol, a Secure Sockets Layer protocol, or other suitable secure communication protocol.

[0053] The access device 106 and the base station 104 can be coupled together in any suitable manner. For example, the access device 106 and the base station 104 can be connected by physical wires, or can be connected by a short-range wireless connection (e.g., as described below with respect to the base station 104).

[0054] The beacon 101 and the base station 104 can be separate or coupled together. In some embodiments, the beacon 101 and the base station 104 can be implemented by the same device.

[0055] In some embodiments, BLE (Bluetooth Low Energy) technology is used as the short-range communication protocol or technology. Bluetooth Low Energy is a personal area network technology used to transfer data over short distances. Bluetooth Low Energy is designed for low power consumption and low cost, while maintaining a communication range similar to classic Bluetooth. BLE communication is primarily composed of "advertisements" or small packets of data that are broadcasted by a beacon (which can be present in a base station or can be a base station) or other BLE-enabled device at regular intervals via radio waves.

[0056] BLE advertising is a one-way communication method. Beacons (e.g., the beacon 101) that want to be "discovered" can broadcast or "advertise" independent packets of data at set intervals. These packets are intended to be collected by devices like smartphones, where they can be used for various smartphone applications to trigger things like push messages, application actions, and alerts. The optimal advertising interval can be 100 ms. Advertising more frequently uses more battery life, but allows smartphones and other listening devices to discover faster. Standard BLE has a broadcast range of up to 100 meters.

[0057] In embodiments of the present invention, a BLE station can also be present in a base station (e.g., the base station 104). The BLE station can allow for two-way communication with a mobile communication device. The base station (e.g., the base station 104) can have a UUID built into it, which can be transmitted to a recipient. The recipient can use the UUID to identify the base station or an entity (e.g., a resource provider) associated with the base station.

[0058] A universally unique identifier (UUID) can correspond to an identification scheme used to uniquely identify a particular entity from a set of entities without a significant central coordination. For example, each base station can be assigned a particular 128-bit value to use as its UUID. Subsequently, the base station can use its UUID to uniquely identify itself from all other base stations within a particular environment. In some cases, each base station can be assigned a UUID at its manufacture. In other cases, a base station can be given its UUID through configuration of its software or firmware.

[0059] The transaction processing system 110, which can be implemented as a cloud-based system or a server computer system, can be remotely located with respect to the portable communication device 102, the portable transaction device 108, the access device 106, and the base station 104.

[0060] Figure 1 The entities in the other figures can communicate using any suitable communication network. Suitable communication networks can be any one and / or combination of: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a

[0061] Prior to conducting a transaction, a user can enroll the portable communication device 102 with the transaction service by downloading a transaction application (e.g., a payment application, a mobile wallet application, etc.) onto the portable communication device 102. The user then links the portable communication device 102 to one or more portable transaction devices (e.g., the portable transaction device 108). Information about the portable communication device 102 and the user can be stored in the transaction processing system 110.

[0062] Additionally, a resource provider can obtain an identifier of the transaction processing system 110 from the processing system (e.g., through a website associated with the transaction processing system) 110 and configure the beacon 101 to periodically broadcast the identifier. It should be noted that multiple resource providers or all resource providers can configure associated beacons to broadcast the same identifier.

[0063] After the user is enrolled, the user enters a resource provider premises with both the portable transaction device 108 and the portable communication device 102 having the transaction application installed. The resource provider premises can also include the access device 106 and the base station 104. The resource provider can be a merchant, a transportation terminal, a building, etc.

[0064] At step S101, when the portable communication device 102 enters the range of the periodic wireless broadcast (e.g., beacon) of the beacon 101, the portable communication device 102 receives one of the beacons containing the UUID of the transaction processing system. The broadcast can optionally contain date / time information, e.g., the current date and / or time (e.g., a timestamp). In response to receiving this particular UUID, the transaction application wakes up within the portable communication device 102.

[0065] At step S102, the portable communication device 102 (using the transaction application) can send a cryptogram mode request to the transaction processing system 110 to request a cryptogram mode from the transaction processing system 110. The cryptogram mode request can contain device information, e.g., a device ID that identifies the portable communication device 102 and / or a device fingerprint of the portable communication device 102, and any or all of the data obtained from the beacon transmission and time information (e.g., date and / or time). Examples of device identifiers can include an IMEI number, an MSISDN number, a UDID (Universal Device ID) number, a SIM card number, etc. Examples of device fingerprints can include a unique serial number assigned to unique hardware, a web browser fingerprint, etc. The device information can also contain an account identifier or other information specific to the portable communication device 102. In this example, the device information does not contain a real actual user credential, e.g., a real PAN. However, in other embodiments, instead of sending a device ID and / or a device fingerprint, a real credential (or payment token) can be sent by the portable communication device 102 to the transaction processing system 110.

[0066] At step S103, when the transaction processing system 110 receives the cryptogram mode request, the transaction processing system 110 verifies the device ID and device fingerprint against the previous information provided from the portable communication device 102 during registration. This is done to ensure that the portable communication device 102 is the registered device, and that the portable communication device 102 is not hacked (e.g., jailbroken) or otherwise compromised with malware or viruses. The transaction processing system 110 then uses the device ID and / or device fingerprint (assuming a PAN is not transmitted by the portable communication device 102) to look up the account identifier (e.g., PAN) and expiration date (or tokenized version of the PAN and expiration date) associated with the portable communication device 102. This can be done by electronically searching for the credential or token in a database.

[0067] After obtaining the account identifier and the validity period, the transaction processing system 110 generates a first cryptogram (e.g., a PAN cryptogram). The first cryptogram can be based on the account identifier, the validity period of the account identifier, and optionally the current date. In some embodiments, a random number can be added to the first cryptogram to prevent replay attacks. In some embodiments, the first cryptogram can be the result of hashing these data elements and taking a predetermined number of bytes of the hashed data elements. The predetermined number of bytes can be the most significant four bytes of the hash result. In some embodiments, the transaction processing system 110 can sign the first cryptogram using the private key of a public / private key pair. The transaction processing system 110 can also record the time of the cryptogram request.

[0068] At step S104, the transaction processing system 110 responds to the cryptogram request by sending the first cryptogram, and any corresponding random number, to the portable communication device 102. It should be noted that the portable communication device 102 can be associated with more than one PAN. In such a case, the transaction processing system 110 can use the device ID and device fingerprint to retrieve multiple PANs, and use each PAN to generate a cryptogram. Subsequently, the cryptograms can be returned to the portable communication device 102

[0069] At step S105, after the portable communication device 102 receives the cryptogram, and any corresponding random number, the portable communication device 102 begins scanning for proximate base stations. After the portable communication device discovers a base station 104, the portable communication device 102 initiates a connection with the base station 104 and receives the UUID of the base station 104.

[0070] At step S106, the portable communication device 102 generates a second cryptogram. The second cryptogram can be based on the first cryptogram and the UUID. In some embodiments, a random number can be added to the second cryptogram to prevent replay attacks. In some embodiments, the second cryptogram can be the result of hashing these data elements and taking a predetermined number of bytes of the hashed data elements. The predetermined number of bytes can be the most significant four bytes of the hash result. The transaction processing system 110 can also record the time of the cryptogram request.

[0071] At step 107, the portable communication device 102 transmits the second cryptogram and any corresponding nonce to the base station 104. In response, the base station 104 stores the second cryptogram (e.g., in a table) for later retrieval by the access device 106. In some embodiments, the base station 104 transmits both the cryptogram and its UUID, and optionally the nonce, to the access device 106. These elements are stored at the access device 106 for later use. In embodiments where the cryptogram is signed by the transaction processing system 110, the base station 104 or the access device 106 can have the corresponding public key in a private / public key pair to verify the signature.

[0072] At step 108, the portable communication device 102 transmits the UUID of the base station 104 to the transaction processing system 110. In some embodiments, the portable communication device 102 can also transmit the first cryptogram, the device ID, and / or the device fingerprint to the transaction processing system 110 to inform the transaction processing system 110 which cryptogram is associated with the transmitted UUID. In addition, to prevent replay attacks, the portable communication device 102 can also generate a nonce and the UUID and transmit the nonce and the UUID to the transaction processing system 110.

[0073] At step 109, the transaction processing system 110 locally generates its own second cryptogram. The second cryptogram can be based on the first cryptogram and the UUID. In some embodiments, the second cryptogram can be the result of hashing these data elements and taking a predetermined number of bytes of the hashed data elements. The predetermined number of bytes can be the most significant four bytes of the hash result. The transaction processing system 110 can also record the time of generation of the second cryptogram.

[0074] At step S110, the user conducts a transaction by interacting the portable transaction device 108 with the access device 106. The portable transaction device 108 can interact with the access device 106 using any suitable contact-based method (e.g., using a magnetic stripe or electrical contacts) or non-contact based method (e.g., using NFC, Bluetooth, Wi-Fi, etc.).

[0075] At step S111, the access device 106 reads the account credentials (e.g., account identifier, such as a PAN, expiration date, etc.) stored on the portable transaction device 108 and locally computes its own second cryptogram. For example, the access device 106 can first compute a first cryptogram by hashing the account identifier and expiration date read from the portable transaction device 108, and optionally a current date and / or a received nonce, and taking the most significant four bytes of the hash result. The access device 106 can then compute a second cryptogram by hashing the first cryptogram and the UUID supplied to the access device 106 from the base station 104.

[0076] At step S112, the access device 106 compares the locally generated second cryptogram pattern with the list of cryptogram patterns stored in the base station 104 and makes a local decision on the processing choice for this transaction. A matching cryptogram pattern can be used as an indication to the issuer (or other authorized entity) that the cardholder (e.g., user) of the portable communication device 102 is present. For example, if the locally generated second cryptogram pattern matches a previously received cryptogram pattern (e.g., the second cryptogram pattern originally generated by the portable communication device 102), the access device 106 can omit prompting the user for a PIN or signature to improve the user experience, as the matching cryptogram pattern verifies that the portable communication device 102 is present. Moreover, since the presence of the portable communication device 102 is confirmed to be present, no additional user verification method (e.g., a request for a PIN or signature) need be performed.

[0077] After the access device 106 confirms the presence of the trusted user, the access device 106 can then generate an authorization request message. The authorization request message can contain any suitable information, including a portion of the locally generated second cryptogram pattern (i.e., the pattern portion). In some embodiments, the pattern portion can include the entire locally generated second cryptogram pattern.

[0078] In some embodiments, the authorization request message can omit the pattern portion. For example, if the access device 106 determines that the second cryptogram pattern generated by the access device 106 matches a previously stored second cryptogram pattern, the access device 106 can only form an indicator that indicates the match was successful and can embed the match into the authorization request message. This would serve as evidence of authentication to downstream entities, such as an acquirer, a payment processing network, or an issuer. The authorization request message can also contain any other elements, including a transaction amount, a payment token or credential, etc.

[0079] At step S113, the access device 106 sends the authorization request message containing one or more of the account credentials, the transaction cryptogram, and the pattern portion to the transaction processing system 110.

[0080] At step S114, the transaction processing system 110 (or a server computer contained within the system) can analyze the authorization request message to determine that the user of the portable communication device 102 is still conducting a transaction at the access device 206. In some embodiments, this can be done by determining whether a pattern portion is present in the authorization request message, and determining whether the pattern portion corresponds to (e.g., matches) one of the stored cryptogram patterns generated locally at the transaction processing system 110 for the account associated with the authorization request (i.e., the PAN of the portable transaction device 108). For example, the transaction processing system 110 can find a match between the pattern portion and its own second cryptogram pattern that it generated and stored in step S109. Generally, a match between the pattern portion and the second cryptogram pattern is found when the bytes of the pattern portion are the same as those of the corresponding portion of the second cryptogram pattern. In embodiments where the pattern portion contains the entire cryptogram pattern, a match is found only if all of the bytes of the pattern portion are the same as those of the second cryptogram pattern.

[0081] In embodiments where the authorization request message contains an indicator instead of a pattern portion, the transaction processing system 110 can determine that the cryptogram pattern match conducted at the access device 106 was successful by analyzing the indicator.

[0082] In particular, the transaction processing system 110 can attempt to match the pattern portion to a stored cryptogram pattern that was generated by the transaction processing system 110 within a tolerance time window prior to receiving the authorization request message. The tolerance time window can depend on the circumstances of the particular location. For example, if the transaction is a transportation transaction, the tolerance time period can be the normal arrival and waiting time for a particular vehicle to travel from a particular origin to a particular destination. If the transaction is at a department store, the time window can be a few hours or less. If the transaction is at a fast food restaurant, the transaction time can be 30 minutes or less.

[0083] The transaction processing system 110 can also determine whether the transaction is authorized based on other factors, including whether there are sufficient funds or credit in the account used to conduct the transaction. In other embodiments, the transaction processing system 110 can forward the authorization request to a downstream authorization computer (not shown), and the authorization computer can determine whether the transaction is authorized. If the authorization computer makes an authorization decision, the authorization computer will transmit an authorization response message back to the transaction processing system 110 with the authorization result.

[0084] At step S115, the transaction processing system 110 sends an authorization response message to the access device 106 indicating whether the transaction was approved or declined.

[0085] The clearing and settlement process can be conducted at the end of the day or at some other time period.

[0086] It should be noted that the incorporation of the UUID of the base station (e.g., base station 104) into the second cryptogram prevents an unauthorized individual from being able to capture the second cryptogram and use it in a fraudulent manner at a second location. For example, by eavesdropping on the communications between the entities in Figure 1

[0087] During operation, several measures can be taken to avoid theft in a store where, after a thief steals a portable transaction device from a victim, the thief then waits inside the store while the victim leaves the store unaware that their portable transaction device 108 was stolen. For example, at the time of the transaction, the base station 104 can again cause the portable communication device 102 to emit a sound. In this case, mid-range wireless communication such as BLE is well suited to estimate the distance to the portable communication device 102 so that the base station 104 can detect how far away the portable communication device 102 is from the access device 106. If so, a timeout of the cryptogram can also be implemented to force an update or refresh. Different time windows can be implemented depending on the type of store (e.g., fast food versus furniture).

[0088] It should be noted that although the access device 106 has been illustrated as a POS terminal, the system can also be used for access devices such as ATMs of an issuer to obtain the legitimacy of a cash withdrawal. Although the size of the ATM differs from that of the POS terminal, the flow would be similar to the flow described above.

[0089] It should also be noted that although the portable communication device has been illustrated as a mobile phone and the portable transaction device has been illustrated as a card, in some embodiments, other device pairs can be used. For example, the portable communication device can be a wearable device such as a watch and the watch can be used with a mobile phone or a card that acts as a portable transaction device to perform the transaction flow described herein. As another example, the portable communication device can be a user hands-free equipped vehicle with communication capabilities and the vehicle can be used with a mobile phone, a wearable device, or a card that acts as a portable transaction device to perform the transaction flow described herein.

[0090] ​Furthermore, although the base station is described as using the Bluetooth Low Energy (BLE) protocol to communicate with portable communication devices, other types of short / mid-range wireless communication protocols, such as Bluetooth or WiFi, can be used. BLE may be more suitable than other protocols because of its low power consumption, ability to estimate the range of portable communication devices, and ability to automatically connect to BLE-enabled portable communication devices.

[0091] Figure 2 A block diagram of a system 200 according to an embodiment of the present invention is shown. The system includes a portable transaction device 208, one or more terminals (e.g., one or more access devices 206), a base station 204, a portable communication device 202, an acquirer server 220, an issuer server 222, and a transaction processing system 210.

[0092] Access device 206 may include authentication processing to query MLC (Mobility Confirmation) authentication module 204C to determine the user's physical presence in the venue. Specifically, access device may attempt to match a second password pattern generated locally at access device with another second password pattern stored in the MLC-IS authentication module in recent years.

[0093] The transaction processing system 210 includes a mobile gateway 210A, a network interface 210B, and an MLC platform 210C that communicate with each other. The MLC platform may also include a store check-in service 210C-1, a registration service 210C-2, a location update service 210C-3, an MLC database 210C-4, an MLC backend server 210C-5, and one or more data processors 210C-6.

[0094] In some embodiments, transaction processing system 210 may include a data processing subsystem, a network, and operations for supporting and delivering authorization services, exception handling services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing system may include VisaNet. TM For example, VisaNet TM The transaction processing network can handle credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet... TM It may include a VIP system (Visa Integrated Payment System) for processing authorization requests and a BaseII system for performing clearing and settlement services.

[0095] In some embodiments, in response to receiving a password pattern request containing the device ID of a portable communication device, the store check-in service 210C-1 searches for the primary account (PAN) and PAN expiration date associated with the device ID. If a PAN and PAN expiration date are found, the store check-in service 210C-1 may perform the following for each pair of PAN and PAN expiration date:

[0096] • Format the PAN and PAN Expiry into compressed digits. Compressed digit data elements consist of two numeric digits per byte (with values in the range of hexadecimal '0' to '9'). These data elements can be left-justified and padded with a trailing hexadecimal 'F'.

[0097] • Generate a new random number and save the value for later use.

[0098] • Concatenate the PAN, PAN Expiry, and generated random number from left to right

[0099] • Hash the concatenated result using the SHA-256 hashing algorithm, or obtain a 32-byte hash result.

[0100] • Convert the binary string of the hash value into a Base64 string using Base64 data encoding.

[0101] As shown above, the concatenated result is used as input to the SHA-256 hashing algorithm to obtain a 32-byte hash result. It should be noted that the SHA-256 hashing algorithm can correspond to a particular hash function and / or encryption algorithm known in the art. Other hash functions can be used without departing from the spirit of the present application. Some examples of other hash functions are MD5, SHA-1, HMAC, linear hash, rolling hash, etc.

[0102] The store check-in service 210C-1 can return the encoding (e.g., Base64) of the string of hash values and the random number generated for each pair of PAN and PAN Expiry found, and can also return a status code and corresponding message as an API response. If no PAN and PAN Expiry are found, the store check-in service 210C-1 can return a status code and corresponding message as an API response.

[0103] The enrollment service 210C-2 can facilitate a process of enrolling a user of a portable transaction device into the MLC platform 210C, which for a given user includes the following steps: associating within the MLC database 210C-4 device information of a portable communication device of the user with the PAN(s) of one or more portable transaction devices of the user.

[0104] The portable communication device 202 can include a mobile location agent 202A. The mobile location agent 202A can be programmed to provide beacon detection capability, which is needed to wake up or notify the mobile location agent 202A once the cardholder / mobile device owner enters a beacon-monitored resource provider site. BLE connection management can also be provided, which the mobile location agent 202A can use to set up and manage a BLE connection with a base station to transmit store check-in information to a store controller BLE.

[0105] The base station 204 can take any suitable form (e.g., a single device with a single housing, multiple devices with multiple housings, any suitable combination of software and / or hardware, etc.), including a BLE beacon 204A, a BLE station 204B, and an MLC verification module 204C. Although the BLE beacon 204A is illustrated in the base station 204, in other embodiments or the present application, the BLE beacon can be present in other devices (e.g., a separate device). The BLE beacon 204A is a device that constantly broadcasts a predefined BLE packet containing an identifier of a transaction processing system. The BLE beacon can be used to notify a user's portable communication device when the user enters a resource provider premises (e.g., a merchant store). The BLE station 204A can be a device that exchanges information with the portable communication device 202 over a BLE channel. The BLE station is used to receive a cryptogram pattern from the portable communication device 202. The verification module 204C can be used to store the cryptogram pattern, receive a hash match request from an access device, perform a hash match, and return a hash match result to the access device. Although the verification module 204C is illustrated in the base station 204, in other embodiments of the present application, the verification module can be present in other devices (e.g., an access device).

[0106] Figure 3 A block diagram of a portable communication device 301 according to some embodiments is illustrated. The portable communication device 301 can include device hardware 304 coupled to a memory 302. The device hardware 304 can include a processor 305, a communication subsystem 308, a user interface 306, and a display 307 (which can be part of the user interface 306). The processor 305 can be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is for controlling the operation of the portable communication device 301. The processor 305 can execute a variety of programs in response to program code or computer-readable code stored in the memory 302 and can maintain multiple simultaneously executing programs or processes. The communication subsystem 309 can include one or more RF transceivers and / or connectors that can be used by the portable communication device 301 to communicate with other devices and / or to connect with external networks. The user interface 306 can include any combination of input and output elements to allow a user to interact with the portable communication device 301 and invoke functionality of the portable communication device 301. In some embodiments, the display 307 can be part of the user interface 306.

[0107] The memory 302 can be implemented using any combination of volatile and nonvolatile memory (e.g., flash memory, RAM, SRAM, DRAM, etc.) or any other non-transitory storage medium, or a combination of media. The memory 302 can store a mobile OS 314 and a mobile application environment 310 in which one or more mobile applications reside 312 (e.g., a payment application, such as a mobile wallet application, a merchant application, a mobile location application, etc.) for execution by the processor 305.

[0108] Figure 4 A diagram of a transaction processing system 400 that can incorporate any of the previously described systems is shown. The transaction processing system 400 includes a user device 401 operated by a user 402. The user device can interact with an access device 404 and can be the previously described portable transaction device. The access device 404 communicates with an authorization computer 412 through a resource provider computer 406, a transport computer 408, and a processing network 410. A token service system 414 can communicate with (or can be incorporated into) the processing network 410. The processing network 410 can include the previously described transaction processing system.

[0109] In a transaction conducted using the system 400, the user can interact with the access device 404 using the user device 401. The access device can then generate an authorization request message and transmit the authorization request message to the processing network 410 through the resource provider computer 406 and the transport computer 408. If the authorization request message contains a token, such as a payment token, the processing network 410 can retrieve the real credential associated with the token from the token service system 414 and can replace the token with the real credential in the authorization request message. The authorization request message can then be forwarded to the authorization computer 412 for an authorization decision.

[0110] After the authorization computer 412 makes an authorization decision, the authorization computer returns an authorization response to the access device 404 through the processing network 410, the transport computer 408, and the resource provider computer 406. If necessary, the processing network 410 can replace the real credential in the authorization response message with the previously provided token. As described above, clearing and settlement processes can then be performed.

[0111] Figure 5 A flowchart of a hash matching process according to an embodiment of the application is shown. As described above in Figure 1 and 2 the hash matching process can be performed by a base station, an access device, and / or a transaction processing system.

[0112] At step S502, the hash matching process can begin.

[0113] At step S504, a decision is made by the device as to whether any data elements are missing and / or whether the format is supported. In step S514, if there are missing data elements and / or if the format is not supported, an invalid request indicator is generated by the device.

[0114] At step S506, a decision is made by the device as to whether any password pattern is in the device that is in use.

[0115] At step S508, if there is a password pattern in the device, the received password pattern is processed by the device.

[0116] At step S510, a determination is made by the device as to whether the generated password pattern matches the stored password pattern.

[0117] At step S516, if there is a match, a success indicator can be generated by the device.

[0118] At step S512, if there is no match, the device determines whether there are more password patterns in the module. In step S518, if there are no more password patterns to test, a failure indicator can be generated.

[0119] At step S520, the password pattern matching process ends.

[0120] Some of the entities or components described herein can be associated with or operate one or more computer devices to facilitate the functionality described herein. Some of the entities or components described herein, including any servers or databases, can use any suitable number of subsystems to facilitate the functionality.

[0121] The subsystems or components can be interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory comprising computer readable media), monitor, which is coupled to display adapter, and others are shown. Peripherals and input / output (I / O) devices, which can include mice and scanners for instance, can be connected to a user interface adapter coupled to the processor. Other input device adapters that can be connected to the processor could include a serial port, and a parallel port that could be used to connect the computer device to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems. The system memory and / or the fixed disk can embody a computer readable medium.

[0122] Embodiments of the present invention provide a number of advantages. For example, by using a venue base station, embodiments of the present invention can accurately determine whether a trusted user is actually conducting a transaction using a portable transaction device. A fraudster without the user's portable communication device will not be able to conduct a transaction using the user's portable transaction device. Thus, using embodiments of the present invention can prevent unauthorized location access, unauthorized payment transactions, and unauthorized data requests. Moreover, as can be appreciated from the foregoing, the verification of the user's reliability at the transaction location can be verified before the user reaches the point of beginning a transaction, and the verification process used in embodiments of the present invention is secure. Thus, no additional authentication processes (e.g., PIN or password requests or signatures) need be used in embodiments of the present invention. This reduces any friction that can arise between resource providers and users due to users not remembering their authentication data or due to the increased transaction time that would otherwise result from additional authentication processes.

[0123] Additionally, while previous transaction processing systems can not have provided a method of preventing a malicious resource provider from providing fraudulent authorization requests, the local generation of the cryptogram pattern at the portable communication device, resource provider, and transaction processing system, and the verification of the pattern match during a transaction can ensure that the resource provider is in compliance. Specifically, the completion of a match of the pattern portion received from the resource provider via the authorization request with the most recent cryptogram pattern generated locally at the transaction processing system ensures that the resource provider is correctly generating its own second cryptogram pattern.

[0124] Further, previous transaction processing systems can require resource providers to perform a registration process involving: (1) the resource provider submitting information identifying the resource provider to the transaction processing system 110; (2) the transaction processing system generating, storing (e.g., in a database), and transmitting to the resource provider an identifier that uniquely identifies the resource provider; and (3) the resource provider configuring its infrastructure (e.g., base stations or access devices) with the identifier. In contrast, some embodiments can use a UUID provided by (e.g., built into) the base station used by the resource provider to uniquely identify the resource provider. In doing so, some embodiments can remove the registration process, thereby reducing the barrier for resource providers to participate in the system. Additionally, some embodiments can free the transaction processing system from generating and storing an identifier for each participating resource provider.

[0125] Messages between the computers, networks, and devices described herein can use secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure HyperText Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and the like.

[0126] Other embodiments of the application are contemplated. Other embodiments of the application can include the following:

[0127] An additional embodiment relates to a method comprising: receiving, by an access station from a portable communication device, a second cryptographic pattern derived from a base station identifier and a credential or token; receiving, from the portable transaction device, a credential or token during a transaction conducted at an access device; generating another cryptographic pattern derived from at least the base station identifier and the received credential or token; comparing the second cryptographic pattern to the other cryptographic pattern, and if the patterns match, sending an authorization request message including at least a portion of the other cryptographic pattern to a server computer.

[0128] Another embodiment of the application can relate to an access device including code executable by a processor to perform the above-described method.

[0129] The above provides specific details regarding some of the aspects described above. Particular aspects of the specific details can be combined in any suitable manner without departing from the spirit and scope of embodiments of the application. For example, although the above-described embodiments relate to authentication processes, other types of processes can be performed using embodiments of the application. For example, because embodiments of the application can verify that a user is actually at a particular location, embodiments of the application can also be used to provide incentives or rewards to users.

[0130] It should be understood that the above-described application can be implemented in the form of control logic using computer software (stored in tangible, physical media) in a modular or integrated manner, based on the application and teachings provided herein. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods to implement the present application using hardware and a combination of hardware and software.

[0131] Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands or as a series of operations within one or more tangible, non-transitory computer-readable media such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium can reside on or within a single computational apparatus, and can be present on or within different computational apparatuses within a system or network.

[0132] The above description is illustrative and is not restrictive. Many variations of the application will become apparent to those skilled in the art upon review of the disclosure. The scope of the application should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0133] One or more features of any embodiment can be combined with one or more features of any other embodiment without departing from the scope of the application.

[0134] The recitation "one", "an" or "the" is intended to mean "one or more" unless specifically indicated to the contrary.

[0135] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

1. A method for authenticating transactions, comprising: During a transaction conducted at the access device, the access device reads the credentials or tokens on the portable transaction device; The second cryptographic pattern is computed locally by hashing at least the base station identifier and a first cryptographic pattern formed based on the received credentials or tokens. The second cryptographic pattern is compared with a list of cryptographic patterns stored in the base station associated with the base station identifier; as well as If the second cipher pattern matches a previously received cipher pattern in the cipher pattern list, a local decision is made regarding the processing of the transaction.

2. The method according to claim 1, wherein the portable transaction device is a payment card.

3. The method according to claim 1, wherein the base station identifier is a UUID.

4. The method of claim 1, wherein the access device includes a point-of-sale device.

5. The method of claim 1, wherein the access device receives the first cipher pattern from the portable communication device via the base station associated with the base station identifier.

6. The method of claim 1, wherein the server computer derives the first cryptographic pattern from the base station identifier and the credential or the token.

7. The method of claim 1, wherein the second cryptographic pattern is derived from the token.

8. The method of claim 5, wherein the portable communication device and the access device communicate via Bluetooth Low Energy (BLE).

9. An access device, comprising: processor; as well as A computer-readable medium coupled to the processor and including code executable by the processor to perform operations including: During a transaction at the access device, read the credentials or tokens on the portable transaction device; The second cryptographic pattern is computed locally by hashing at least the base station identifier and a first cryptographic pattern formed based on the received credentials or tokens. The second cryptographic pattern is compared with a list of cryptographic patterns stored in the base station associated with the base station identifier; as well as If the second cipher pattern matches a previously received cipher pattern in the cipher pattern list, a local decision is made regarding the processing of the transaction.

10. The access device according to claim 9, wherein the base station identifier is a UUID.

11. The access device according to claim 9, wherein the access device is a point-of-sale terminal.

12. The access device of claim 9, wherein the access device receives the first cipher mode from a portable communication device via the base station associated with the base station identifier, wherein the portable communication device and the access device communicate via Bluetooth Low Energy (BLE).

13. The access device of claim 9, wherein the second password pattern is derived from the token.

14. The access device of claim 9, wherein the access device receives the first cipher pattern from the portable communication device via the base station associated with the base station identifier.

15. The access device of claim 9, wherein the second password pattern is derived from the credential.

Images