Systems and methods for using dynamic tag content

Abstract

A method is disclosed. The method includes a user device storing a message data template including a plurality of data fields. In response to an interaction between the user device and an access device, a multi-record message can be generated using the message data template. To generate the multi-record message, the user device can increment a counter stored on the user device to produce a counter value and generate a dynamic cryptogram. The user device can additionally retrieve a credential. The counter value, the dynamic cryptogram, and the credential can then be incorporated into the plurality of data fields of the message data template to form the multi-record message. The multi-record message can be transmitted to the access device, where the access device forwards the multi-record message to an authorization computer to authorize or deny the interaction.

Description

[0001] Cross-references to related applications

[0002] This patent application claims the benefit of U.S. Provisional Application No. 62 / 902,679, filed September 19, 2019, which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] Systems and methods for handling contactless interactions between user devices and access devices to gain access to resources such as goods and services, secure locations, or secure data are known. However, some systems and methods require user devices and access devices to have dedicated software and hardware to interact with each other. This can limit their ability to interact. For example, a user of a specifically programmed device (such as a specifically programmed access badge or payment card) may wish to interact with an access device that does not have the specific programming or hardware typically required to interact with the user device. For instance, the user device could be an access badge specifically programmed with a type of access badge reader, which is programmed with complementary software and hardware. It would be desirable if the user device could be used with access devices other than those specifically programmed for use with that user device.

[0004] The implementation schemes disclosed herein address these and other issues individually and collectively. Summary of the Invention

[0005] Embodiments of the present invention include generating a message comprising one or more dynamic elements and transmitting it to an access device that may not be able to receive and / or process the message in accordance with certain existing security protocols.

[0006] One embodiment of the present invention may include a method comprising: storing a message data template, including a counter value, a password, and a credential, on a user device, the message data template being used to form a multi-record message; initiating an interaction with an access device in a transaction by the user device; incrementing a counter stored on the user device to generate a counter value and generating a password by the user device; incorporating the counter value, password, and credential into the data fields of the message data template by the user device to form the multi-record message; and transmitting the multi-record message to the access device by the user device.

[0007] Another embodiment of the invention can include a method comprising: initiating, by an access device, a communication with a user device; receiving, by the access device, a multi-record message from the user device, wherein the multi-record message includes at least a counter value, a cryptogram, and a credential; extracting, by the access device, the counter value, the cryptogram, and the credential from the multi-record message; generating, by the access device, an authorization request message, wherein the authorization request message includes at least the extracted counter value, the cryptogram, and the credential; transmitting, by the access device, the authorization request message to an authorization computer; and receiving, by the access device, an authorization response message from the authorization computer.

[0008] Another embodiment of the invention can include a method comprising: initiating, by an access device, a communication with a user device; receiving, by the access device, a multi-record message from the user device, wherein the multi-record message includes at least a counter value, a cryptogram, and a credential; extracting, by the access device, the counter value, the cryptogram, and the credential from the multi-record message; generating, by the access device, an authorization request message, wherein the authorization request message includes at least the extracted counter value, the cryptogram, and the credential; transmitting, by the access device, the authorization request message to an authorization computer; and receiving, by the access device, an authorization response message from the authorization computer.

[0009] Another embodiment of the invention can include a method comprising: initiating, by an access device, a communication with a user device; receiving, by the access device, a multi-record message from the user device, wherein the multi-record message includes at least a counter value, a cryptogram, and a credential; extracting, by the access device, the counter value, the cryptogram, and the credential from the multi-record message; generating, by the access device, an authorization request message, wherein the authorization request message includes at least the extracted counter value, the cryptogram, and the credential; transmitting, by the access device, the authorization request message to an authorization computer; and receiving, by the access device, an authorization response message from the authorization computer.

[0010] These and other embodiments are described in further detail below. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 A block diagram depicting a user device enabled with multi-record generation applets and its interaction with a compatible access device is shown.

[0012] Figure 2 A flow diagram showing a process of issuing an NFC tag element at a user device for generating a multi-record message is shown.

[0013] Figure 3 A block diagram depicting a system for processing a payment transaction between a first access device and an NDEF application and a second access device and a secure access application such as an EMV application is shown.

[0014] Figure 4 A block diagram depicting a user device in accordance with embodiments of the application is shown.

[0015] Figure 5 A block diagram depicting an exemplary multi-record message including at least one or more dynamic elements in accordance with embodiments of the application is shown.

[0016] Figure 6 A block diagram depicting an access device in accordance with embodiments of the application is shown. DETAILED DESCRIPTION

[0017] Many mobile phones do not have the ability to process transaction and / or access request messages in accordance with a particular security protocol, such as the EMV protocol, but they are able to receive multi-record messages generated with near field communication (NFC) tags. However, such messages can not be dynamic in nature. They are not able to produce the necessary encrypted data used in standard transaction and / or access request messages. Thus, it can be risky to use these messages to carry sensitive credentials because the messages can be susceptible to copy and redirect attacks.

[0018] Embodiments of the application can include a method. The method includes a user device generating a dynamic multi-record message via an NFC tag element. The NFC tag element can have ISO 14443 A and B interface compatibility. The multi-record message can carry a credential, a cryptogram, and a counter value in a template. The multi-record message can be sent from the user device to a mobile device, such as a smartphone. The mobile device can act as an access device, which can grant access to a resource, such as secure data, a secure location, or goods and / or services.

[0019] In embodiments, a counter value can be generated by incrementing a counter stored on the user device each time the user activates the NFC tag element of the user device. The user device can generate a dynamic cryptogram by encrypting the counter value and other data using a stored cryptographic key and a cryptographic generation algorithm (e.g., an AES or 3DES algorithm). After receiving the dynamic cryptogram and other information from the user device, the mobile device can send this information to an authorization computer. The mobile device can convert the information into a secure format via a software application, or it can send it to the authorization computer in the original multi-record message format.

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

[0021] "Contactless" communication can be communication that exchanges data between two devices without the two devices being physically coupled. Without limiting the generality of the foregoing, "contactless" communication can include data transmission by near field communication (NFC) transceivers, lasers, radio frequencies, infrared communication, or other radio frequency or wireless communication protocols, such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc.

[0022] A "resource provider" can be an entity that provides a resource (e.g., a good, a service, access to secure data, access to a location, etc.) during a transaction. For example, a resource providing entity can be a merchant, a venue operator, a building owner, a government entity, etc. A "merchant" can generally be an entity that participates in a transaction and can sell or provide access to goods or services.

[0023] An "application" can be a computer program for a particular purpose. Examples of applications can include a transportation application, a secure data access application, a banking application, a digital wallet application, etc.

[0024] "Authentication data" can include any data suitable for authenticating an entity. Authentication data can be obtained from a user or a device operated by the user. Examples of authentication data obtained from a user can include a PIN (personal identification number), biometric data, a password, etc. Examples of authentication data that can be obtained from a device can include a device serial number, a hardware security element identifier, a device fingerprint, a phone number, an IMEI number, etc.

[0025] An "access device" can be any suitable device for providing access to something. Some examples of access devices include a point-of-sale (POS) device, a cellular phone, a PDA, a personal computer (PC), a tablet PC, 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. An access device can use any suitable contact or contactless mode of operation to send or receive data to or associated with a user device. In some embodiments where the access device can include a mobile device, the mobile device 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, a user device reader can include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with a user device.

[0026] A "user device" can be any suitable device that can be operated by a user. A user device can take any suitable form. Some examples of user devices include a cellular telephone, a PDA, a personal computer (PC), a tablet computer, a payment card such as a credit card, a debit card, and a stored value card, and the like. In some embodiments in which the user device is a mobile device, the mobile device can include a display, a memory, a processor, a computer-readable medium, and any other suitable components.

[0027] A "mobile device" (sometimes referred to as a mobile communication device) can include any electronic device that a user can transport or operate that can also provide remote communication capabilities with a network. A mobile communication device can communicate using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that can provide access to a network such as the Internet or a private network. Examples of mobile devices include a mobile phone (e.g., a cellular telephone), a PDA, a tablet computer, a netbook, a laptop computer, a wearable device (e.g., a watch), a vehicle (e.g., an automobile and a motorcycle), a personal music player, a hand-held specialized reader, and the like. A mobile device 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 can be considered a single mobile device when the devices are remotely accessing a network by tethering to another device (i.e., using the other device as a modem)).

[0028] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used as confirmation. Examples of credentials include value credentials, identification cards, authentication documents, access cards, passwords and other login information, and the like. Other examples of credentials include a PAN (primary account number), PII (personally identifiable information) such as a name, address, and phone number, and the like.

[0029] An "authorization entity" can be an entity that authorizes a request, typically using an authorization computer. An authorization entity can be an issuer, a government agency, a document repository, an access administrator, and the like. An "issuer" can typically include a business entity (e.g., a bank) that maintains a user account. An issuer can also issue payment credentials to a user that are stored on a user device such as a cellular telephone, a smart card, a tablet computer, or a laptop computer, and the like. In some cases, an authorization entity can additionally be a third-party entity associated with an issuer.

[0030] A“user” can include an individual or a computing device. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user can be a cardholder, account holder, or consumer.

[0031] 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.

[0032] 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). For example, a token can include a series 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“format preserving” 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 ordinarily provide the original credential. In some embodiments, a token value can be generated such that recovery of the original PAN or other account identifier from the token value is not possible in a computational sense. Further, in some embodiments, a 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.

[0033] A“key” can include a piece of information used in a cryptographic algorithm to transform 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 to the original data. Examples of cryptographic algorithms can include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), and the like. An“encryption key” can include any data value or other information suitable for use in encrypting data with a cryptographic algorithm. A“decryption key” can include any data value or other information suitable for use in decrypting encrypted data. In some cases, the same key used to encrypt data can be referred to as a symmetric encryption key.

[0034] An“access request” can include a request to access a resource. A resource can be a physical resource (e.g., a good), a digital resource (e.g., an electronic document, electronic data, and the like), or a service. In some cases, an access request can be submitted by sending an access request message that includes access request data. Typically, a device associated with a requestor can transmit the access request message to a device associated with a service provider.

[0035] “Access request data” can include any information about or related to an access request. Access request data can include access data. Access request data can include information that can be used to process and / or validate an access request. For example, access request data can include details associated with entities involved in processing an access request (e.g., resource service provider computers, processing server computers, authorization computers, etc.), such as entity identifiers (e.g., names, etc.), location information associated with the entities, and information indicating the type of entity (e.g., category codes). Example access request data can include information indicating the volume of access requests, the location of access requests, the resource received (e.g., product, document, etc.), information about the resource received (e.g., size, volume, type, etc.), service provider entity data (e.g., service provider data, document owner data, etc.), user data, the date and time of the access request, information for the method used to make the access request (e.g., contact, non-contact, etc.), and other relevant information.

[0036] A“password” can include a piece of encrypted text. In some embodiments, a password can be used to authenticate an entity, such as a device or a user. A password can include static data, dynamic data, or a combination of static data and dynamic data encrypted using an encryption key (e.g., a session key or a uniquely derived key).

[0037] An“authorization request message” can be an electronic message sent to a payment processing network and / or an issuer of a payment card to request authorization for a transaction. 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 include an issuer account identifier that can be associated with a payment device or payment account. An authorization request message can also include additional data elements corresponding to“identification information,” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. 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, etc., as well as any other information that can be used to determine whether to identify and / or authorize a transaction.

[0038] An "authorization response message" can be a message in response to an authorization request. In some cases, an authorization response message can be an electronic message reply generated by an issuing financial institution or a transaction processing computer to an authorization request message. By way of example only, an authorization response message can include one or more of the following status indicators: approved - the transaction is approved; declined - the transaction is not approved; or call center - the response awaits more information, the merchant must call a toll-free authorization phone number. An authorization response message can also include an authorization code, which can be a code returned by a credit card issuing bank to a merchant's access device (e.g., a PA device) in response to an authorization request message in an electronic message (directly or through a transaction processing computer) indicating that the transaction is approved. The code can be used as proof of authorization.

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

[0040] A "multi-record message" can be a message that contains one or more data elements that have been divided into one or more "records." Each record can contain at least one data element, and optionally contain one or more tags or identifiers for the type of data element contained in the record. The data elements can be dynamic or static. One example of a "multi-record message" can be an NDEF (NFC Data Exchange Format) message.

[0041] A "counter" can be any suitable device and / or software for maintaining a count. A counter can be in communication with one or more other devices, and receive updates to the maintained count from the one or more other devices, where the updates indicate an increment or a decrement of the count. The counter can additionally store a counter value that includes a numerical representation of the count.

[0042] A "counter value" can be a numerical value stored by a counter. The counter value can be dynamic, and can change in response to the counter being incremented or decremented as a result of one or more events, such as initiation of communication between two devices.

[0043] A "message data template" can be a pre-set template or format for a particular type of message, such that each message of the particular type follows the same template or format. The message data template can include a plurality of data fields that have been determined to be necessary for the particular type of message. Each data field of the plurality of data fields can additionally have a pre-defined format, such as a length or a data type.

[0044] An "NFC tag element" can be a sticker, a chip, and / or any other suitable tag element that has been configured with an RFID (Radio Frequency Identification) reader. An NFC tag element may be able to share data with another mobile device using short-range wireless communication.

[0045] Details of some embodiments of this disclosure will now be described in more detail.

[0046] Figure 1 An access device 102 interacting with user device 104 is illustrated. Access device 102 receives and processes multi-record messages from user device 104. In some embodiments, each multi-record message may include multiple records, wherein at least one of the multiple records contains dynamic and / or static elements. In some embodiments, at least one record includes dynamic elements. In some embodiments, each of the multiple records includes dynamic elements. In some embodiments, one or more records within the multi-record message are used to identify the user operating user device 104 and / or verify the validity of communication between user device 104 and access device 102. Exemplary multi-record messages may include (but are not limited to) a URL, a payload, and / or one or more other (static or dynamic) data elements.

[0047] According to an embodiment of the present invention, the user device 104 may include an NFC tag element 106, which is programmed with a dynamic message generation applet 108 to generate multiple record messages.

[0048] In some implementations, NFC tag element 106 may be an NFC 4 type tag element. In other implementations, user device 104 may include only a dynamic message generation app 108 that is not within NFC tag element 106. In such implementations, dynamic message generation app 108 may be stored directly on the secure element and / or memory element of user device 104.

[0049] exist Figure 1 In one implementation, the dynamic message generation app 108 may have a read counter 108A, a password key 108B, a password generation algorithm 108C, and a message generation module 108D. The read counter 108A may increment after the user device 104 interacts with the access device to generate a counter value. Such interaction may occur when a user operating the user device 104 wishes to gain access to resources and / or locations. In some implementations, the interaction may be a payment transaction.

[0050] The counter value generated by the read counter 108 can be encrypted with the cryptographic key 108B and a cryptographic generation algorithm 108C along with other data to form a dynamic cryptogram. In some embodiments, the cryptographic generation algorithm 108C can be a 3DES or AES algorithm. In some embodiments, the dynamic message generation applet 108 can incorporate the dynamic cryptogram into the multi-record message 112 transmitted to the access device 102. In other embodiments, the dynamic message generation applet 108 can include both the counter value (prior to encryption) and the dynamic cryptogram within the multi-record message 112.

[0051] In some embodiments, the interaction between the access device 102 and the user device 104 can include the access device 102 initiating communication with the NFC tag element 106. The communication can be initiated by the user when the user is carrying the user device 104 and taps and / or swipes the NFC tag element 106 of the user device 104 in proximity to the access device 102.

[0052] In response to the access device 102 interacting with the NFC tag element 106 or the user device 104, the NFC tag element 106 and / or the user device 104 can prompt the message generation module 108D in the dynamic message generation applet 108 to generate the multi-record message 112. The message generation module 108D can retrieve a template from memory in the user device 104 and can then populate the template with the data described herein. The multi-record message 112 can include at least the dynamic cryptogram (generated using the cryptographic key 108B and the cryptographic generation algorithm 108C), the counter value generated by the reader counter 108A, and the credential in the user device 104 stored within the template. The credential can be a primary account number (PAN), a payment token associated with the PAN, an access token, and / or any suitable user identifying information such as a user identifier (e.g., a username), a PIN, a password, and / or biometric identifying information associated with the user. In some embodiments, the credential can be provided to the user device 104 during a registration process of the user or the user device 104 and stored within a secure element (not shown) of the user device 104. In such embodiments, the dynamic message generation applet 108 can request the credential from the secure element of the user device 104 during generation of the multi-record message 112.

[0053] In some embodiments, the multi-record message 112 can be formatted as an alphanumeric string. The multiple records within the multi-record message 112 can include at least a first record, a second record, and a third record, where the first record is a dynamic password, the second record is a counter value, and the third record is a credential. However, it should be appreciated that additional records can also be included within the multi-record message 112. In some embodiments, the multi-record message can also include one or more strings of buffer data elements, such as alphanumeric strings, between each record. The multi-record message 112 can be further represented as an encoded string. In some embodiments, each record of the multiple records can be hashed and / or encrypted using a symmetric and / or asymmetric key. In other embodiments, the entire multi-record message 112 can be hashed and / or encrypted using a symmetric and / or asymmetric key.

[0054] An example of an unfilled template can be: 61094F07A00000000310106222570C$Credential_Insert$82020FBE9F2608$Cryptogram_Insert$9F3602$Counter_insert$, where the template includes at least three data fields for inserting a credential, a cryptogram, and a counter value. An example of a formed template can be: "61094F07A00000000310106222570C4761739001010176D201220182020FBE9F260805B848C479AF49D59F3602005D". In some embodiments, the applet 108 can then convert this hexadecimal value into a base64 string. For example, the example hexadecimal value would be converted into "YQlPB6AAAAADEBBiIlcMR2FzkAEBAXbSASIBggIPvp8mCAW4SMR5r0nVnzYCAF0=".

[0055] Upon generating the multi-record message 112, the user device 104 can transmit the generated multi-record message 112 to the access device 102. The access device 102 can receive the multi-record message 112 and can then decode the message 112 using at least the corresponding symmetric and / or asymmetric key.

[0056] The access device 102 can then read the contents of the message 112. In some embodiments, the access device 102 can further check that the message 112 follows the correct formatting protocol (e.g., does not have blank and / or empty records).

[0057] Upon receiving the multi-record message, the access device 102 can forward the multi-record message 112 to the authorization computer 106. Figure 1The authorization computer can determine whether to grant access to the resource and / or location requested by the user operating the user device 102 after receiving the multi-record message 112. The authorization computer can verify the information contained in the message. The authorization computer can perform the verification by tracking the read counter value contained in the message to another counter value maintained at the authorization computer and / or a third party computer. The authorization computer can additionally verify the cryptogram by decrypting the cryptogram with the shared cryptographic key to obtain the counter value and any other data encoded in the cryptogram. The obtained counter value can be compared to the counter value in the received message.

[0058] In response to successfully verifying the information contained in the message 112, the authorization computer can determine whether to grant the user device (or the user operating the user device) access to the desired resource and / or location.

[0059] In other embodiments, after receiving the multi-record message 112, the access device 102 can convert the multi-record message 112 in a first format to a second message in a second format. The second message can include one or more data elements of the multi-record message 112. The access device 102 can then transmit the second message to an authorization computer for authorization. In some embodiments, the second message can be an ISO 8583 message and the authorization computer can be an issuer computer that holds an account associated with the credential in the multi-record message 112.

[0060] Figure 2 A flowchart illustrating a registration process for an NFC tag element 106 having the ability to generate multi-record messages at a user device 104 is shown. In some embodiments, the process can be performed by an authorization computer operated by an authorizing entity (e.g., an issuer) that issued the user device 104. The process can further be performed during issuance of the user device 104 to a user.

[0061] At step 205, the authorization computer can receive a request to provide an RFID-enabled user device (e.g., a contactless card) with the ability to generate multi-record messages using an NFC tag element. In some embodiments, the request can include a device identifier associated with the user device, and / or a user identifier associated with a user of the user device.

[0062] At step 210, the authorization computer can generate a message data template that can be used to generate a multi-record message. For example, the authorization computer can create the following template within the applet 108 of the NFC tag element: 61094F07A00000000310106222570C$Credential_Insert$82020FBE9F2608$Cryptogram_Insert$9F3602$Counter_insert$. The spaces between the dollar signs are data fields in which a credential (such as a token or PAN), a cryptogram, and a counter value, respectively, can be located.

[0063] At step 215, the authorization computer can then initialize the counter value of the NFC tag element to zero. The authorization computer or a third party can additionally associate the counter value with a device identifier, and store a copy of the initialized counter value and the corresponding device identifier within a database. This can be done so that the authorization computer can subsequently verify the counter value when receiving a multi-record message from a user device. The counter value at the authorization computer can also be incremented when an interaction with a user device is detected.

[0064] At step 220, the authorization computer can further provision the NFC tag element with a shared cryptographic key and a credential. The credential can be retrieved using at least the user identifier included in the request of step 205. In some embodiments, the user identifier can be a login credential and / or any suitable data element that can identify a credential associated with a user operating a user device.

[0065] The authorization computer can then complete the registration process of the NFC tag element to a user of a user device (e.g., a card and / or a mobile phone).

[0066] Figure 3 An exemplary system 300 for processing a payment transaction with a multi-record message according to one embodiment of the application is shown. In this embodiment, the multi-record message can be an NDEF (NFC Data Exchange Format) message. A typical NDEF message includes only static elements stored within a plurality of records. However, embodiments of the application enable the generation of an NDEF message that includes one or more dynamic elements in order to ensure the security of an ongoing interaction.

[0067] Referring to Figure 3, system 300 can include a user device 302 enabled with both a secure access application 302A, such as a VSDC EMV (Europay MasterCard, Visa) application, and a dynamic NDEF message applet 302B. The VSDC EMV application can be a contactless payment application specifically designed to operate using EMV contactless terminals. Both the secure access application 302A and the dynamic NDEF message applet 302B can be configured to communicate with external access devices using the same or different RFID transmitters.

[0068] The secure access application 302A can include credentials 310, such as tokens and / or PANs, and a module to generate or store cryptographic keys 312. The dynamic NDEF message applet 302B can perform the functions of a multi-record message generation applet, where the generated multi-record message is an NDEF message. In embodiments, the secure access application 302A and the dynamic message applet 302B can communicate with each other using an API 314. In such embodiments, the dynamic NDEF message applet 302B is able to access the credentials 310 and / or cryptographic keys 312 from the secure access application 302A using the API 314. The credentials 310 can be retrieved by the dynamic NDEF message applet prior to generating the NDEF message.

[0069] The dynamic NDEF message applet 302B can also include a counter 315 that can generate a counter value. The dynamic NDEF message applet 302B can generate a cryptogram by retrieving the cryptographic keys 312 and credentials 310 via the API 314. The cryptographic keys 312 can be used to encrypt at least the counter value and the credentials using one or more data processors (not shown) on the user device 302 to form the cryptogram.

[0070] The system 300 can further illustrate the user device 302 being used with a first access device 304 of a first type and a second access device 306 of a second type. The second access device 306 can be a standard point-of-sale (POS) terminal and / or another suitable device capable of receiving and processing typical EMV transaction messages. The first access device 304 can be a mobile phone, such as an iPhone, Android phone, or similar device, that is not capable of receiving typical EMV transaction messages. Instead, the first access device 304 can be configured to receive dynamic NDEF messages from the user device 302 and extract the contents of the received NDEF messages for processing transactions. In embodiments, the first access device 304 can be operated by a first resource provider and the second access device 306 can be operated by a second resource provider.

[0071] Both the first access device 304 and the second access device 306 can be configured to generate an authorization request message using either the received NDEF message or the EMV transaction message. The authorization request message may include at least the transaction amount, the voucher 310, and one or more dynamic elements (e.g., a password) included within the corresponding NDEF message or EMV transaction message. The generated authorization request message can then be transmitted to the processor computer 330.

[0072] The processor computer 330 may be located between one of the first access device 304 or the second access device 306 and the authorizing computer 340. In some embodiments, the processor computer 330 may be a network switch that exchanges messages between different authorizing computers and a delivery computer (not shown) operated by an intermediary process such as an acquirer. In some embodiments, the processor computer 330 may include a data processing subsystem, a network, and operations for supporting and delivering authorizing services, exception document services, and clearing and settlement services. In some embodiments, the processor computer 330 may be located in a payment processing network. An exemplary payment processing network may include VisaNet. TM Such as VisaNet TM The payment processing network is capable of handling credit card transactions, debit card transactions, and other types of business transactions.

[0073] System 300 further includes an authorization computer 340 that receives authorization request messages for interaction and decides whether to authorize or deny them. In some embodiments, the authorization computer 340 may be an issuing computer. The authorization computer 340 may verify one or more dynamic elements (e.g., password) included in the authorization request message and may determine whether the account associated with the credentials (e.g., token or PAN) in the authorization request message is trustworthy or has sufficient value to authorize the interaction.

[0074] See also Figure 3 Two exemplary transactions can be described. The first transaction could be a regular payment transaction using a second access device 306 enabled with EMV. The second transaction could be a payment transaction using a first access device 104 that is not enabled to process EMV messages, but could achieve similar functionality using dynamic NDEF messages.

[0075] In a typical transaction, a user may wish to obtain resources (e.g., products) from a resource provider operating a second access device 306, which may be a contactless POS terminal, using user device 302. The user initiates the transaction by passing it to user device 203 via the second access device 306. The second access device 306 exchanges messages with user device 302 according to the EMV protocol.

[0076] In response to the user device 302 initiating a payment transaction, the second access device 306 can initiate an APDU protocol and send a get available application request to the user device 302 to request information about payment applications available on the user device 302 (e.g., a list of AIDs). The get available application request can include a payment environment identifier (e.g., a PPSE name) to identify a payment environment supported by the second access device 306 and the user device 302.

[0077] The user device 302 can process the received request by identifying the payment environment identifier (e.g., the PPSE name) included in the request. The user device 302 can then send a get available application response back to the second access device 306. The get available application response can include a list of available AIDs. In some embodiments, the get available application response can be in the form of a select PPSE response. The available AIDs can include the secure access application 302A.

[0078] The second access device 306 can receive the get available application response and can select an application from the list of available AIDs in the get available application response. In some embodiments, the selected application can be the highest priority application available on the user device 302 that is supported by the access device. The second access device 306 can then transmit an application selection message to the user device 302 that includes the selected application. The application selection message can be in the form of a select AID command. In this embodiment, the selected application is the secure access application 302A.

[0079] In some embodiments, the secure access application 302A can transmit a request for transaction details (in the form of a select AID response) to the second access device 306. The request includes a list of transaction data identifiers to request appropriate data from the access device 306. The list of transaction data identifiers can be in the form of a processing options data object list (PDOL).

[0080] The second access device 306 can then transmit the transaction details to the user device 302 in the form of a GPO (“get processing options”) command. The transaction details can include a transaction amount, a transaction date, an identifier of a desired product, a resource provider identifier, etc.

[0081] The user device 302 can then retrieve the credential 310 from the secure access application 302A and can generate a dynamic cryptogram using the cryptographic key 312. The user device 302 can format the credential 310, the dynamic cryptogram, and one or more of the received transaction details into a secure message, such as a secure EMV message. The user device 302 can then transmit the secure message to the second access device 306.

[0082] At step 2a, the second access device 306 can generate an authorization request message using the above data and can transmit the generated authorization request message to the processor computer 330.

[0083] At step 3, the processor computer 330 forwards the generated authorization request message to the authorization computer 340. The authorization computer 340 determines whether to authorize the transaction. The authorization computer 340 can then transmit an authorization response message to the second access device 306 via the payment processor 330 based on the determination. The second access device 306 can then indicate whether the transaction was authorized.

[0084] The user device 302 is also configured to process a transaction using at least the NDEF message that can be received by the first access device 304, which has a different type than the second access device 306.

[0085] Reference Figure 3 Referring to step lb of FIG. 3, the same user can use the user device 302 to access a resource of a resource provider that operates the first access device 304. In some embodiments, the user can initiate the transaction by tapping the user device 302 against the first access device 304.

[0086] In embodiments, at least the application selection message can be transmitted by the first access device 304 to the user device 302. In this embodiment, the selected application is instead the dynamic NDEF message applet 302B. The first access device 304 can also send a payment request to the user device 302 that includes transaction details. In other embodiments, the transaction details can also include a flag and / or indicator that the first access device 304 can only receive NDEF messages.

[0087] In response, the dynamic NDEF message applet 302B can extract one or more of the transaction details from the payment request and retrieve the credential 310 and cryptographic key 312 from the secure access application 302A using the API 314. The dynamic NDEF applet 302B can generate a dynamic cryptogram by encrypting at least the counter value from the counter 315 and the credential 310 with the cryptographic key 312.

[0088] The dynamic NDEF message applet 302B can then generate a hexadecimal string that includes a plurality of data elements, such as (but not limited to) some transaction details (e.g., transaction amount), the credential 310, the dynamic cryptogram, and the counter value. In some embodiments, the hexadecimal string can be generated using an NDEF message template stored on the dynamic NDEF applet 302B. The hexadecimal string can then be converted to a Base64 string that is sent to the first access device 304 as the NDEF message 318. In embodiments, each of the plurality of data elements can be stored in a separate record of the NDEF message 318. In some embodiments, the NDEF message can be encrypted by the user device 302 using symmetric and / or asymmetric keys.

[0089] The first access device 304 then decrypts and reads the NDEF message 318. In some embodiments, the first access device can also convert the NDEF message 318 to an authorization request message in an ISO 8583 message format.

[0090] At step 2b, the first access device 304 then transmits the message to the processor computer 330. In some embodiments, the processor computer 330 can read the message 318 and verify that the contents of the message 318 are in a proper authorization format.

[0091] At step 3, the processor computer 330 can transmit the message 318 to the authorization computer 340. The authorization computer 340 can then verify one or more data elements included within the message 318. The verification can include extracting at least the counter value and the dynamic cryptogram from the message. In some embodiments, the authorization computer 340 can have a database that stores counter values associated with user devices 302. The authorization computer 340 can verify that its counter value matches the counter value included in the message 318.

[0092] The authorization computer 340 can additionally verify the extracted dynamic cryptogram using the shared cryptographic key to decrypt the cryptogram. In some embodiments, the authorization computer 340 can obtain the counter value by decrypting the cryptogram and can verify that the obtained counter value matches the counter value extracted from the message. In other embodiments, the authorization computer 340 can generate a second cryptogram using the counter value extracted from the message 318 and its shared cryptographic key. The authorization computer 340 can then compare the second cryptogram to the cryptogram received in the message 318 to determine a match. If a match is determined, the cryptogram can be determined to be valid.

[0093] In response to verifying the one or more data elements included in the message 318, the authorization computer 340 can additionally extract the credential 310 from the message and can determine whether the account associated with the credential has sufficient value to authorize the transaction. The authorization computer 340 can then authorize the transaction and generate an authorization response message. The authorization response message can be forwarded to the first access device 304 via the processor computer 330. The first access device 304 can indicate whether the transaction is authorized or declined.

[0094] By using this process, any access device that is NDEF messaging compatible (corresponding to the first access device 304) can be used in a similar manner as a POS device (represented by the second access device 306). By tapping the user device 302 to the first access device 306, a transaction can be initiated. The transaction can include sending an NDEF message 318 to a device that can process it (e.g., convert it to another format) and can pass it to a payment processor 330 and / or authorization computer 340, which can authorize or decline the transaction request. The embodiments allow any NDEF compatible access device to be used as a contactless POS device operating under the EMV protocol. That is, the user device 302 can be used with two different types of access devices while using only one stored credential and one stored cryptographic key. This not only increases the utility of the user device relative to conventional user devices, but also provides greater security because the credential and key do not need to be duplicated for multiple applications on the user device 302.

[0095] Figure 4 A block diagram of an exemplary user device 400 that can be used in embodiments of the present invention is shown.

[0096] The user device 400 can include a computer readable medium 402, which can be in the form of (or can be included in) a memory element that stores data, and which can be in any suitable form (e.g., a microSD chip, a SIM card, or other type of memory element). The computer readable medium 402 can store one or more applications 402A for the device as well as an operating system 402B. The computer readable medium 402 can also include code that can be executed by the processor 406 to cause the user device 400 to perform processes including storing, by the user device, a message data template including data fields of a counter value, a cryptogram, and a credential, the message data template for forming a multi-record message; initiating, by the user device, an interaction with an access device; incrementing, by the user device, a counter stored on the user device to produce a counter value and generate a cryptogram; incorporating, by the user device, the counter value, the cryptogram, and the credential into the data fields of the message data template to form a multi-record message; and transmitting, by the user device, the multi-record message to the access device.

[0097] User device 400 can also include device hardware 404, which includes at least a processor 406, a user interface 408, an input element 410, and / or an output element 412. Device hardware 404 can also include a short-range antenna 414 and a long-range antenna 416 for communicating with wireless networks and / or other devices.

[0098] In embodiments, user device 400 can additionally include an NFC tag element 418. In Figure 1 Components in tag element 418 are described in relation to tag element 106.

[0099] Figure 5 A block diagram of an exemplary multi-record message 500 is shown, in accordance with embodiments of the present application.

[0100] Multi-record message 500 can include a plurality of records, including at least record 502, record 504, and record 506. Message 500 can also include additional records before record 502 and / or after record 506, which are not depicted in the figure. For example, message 500 can include record 508, record 510, record 512, etc. In most embodiments, message 500 includes at least 2 or more records.

[0101] Each record can also include a record header and a record payload. In some embodiments, each record can also include additional information, such as a message identifier that is unique for each generated multi-record message.

[0102] Referring to record 502, record header 502A can include one or more metadata elements of record 502. For example, the record header can include a data field for a payload type and a data field for a payload length. In some embodiments, record header 502A can additionally include a data field for an identifier of the payload and a data field for an identifier length. In some embodiments, record header 502A can also include one or more markers that indicate a position of the record in the message. For example, record header 502A can include one or more markers or data that indicate whether record header 502A is the first record of the message (e.g., a message start marker) and / or whether record header 502A is the last record of the message (e.g., a message end marker). The one or more markers or data can also indicate a format of one or more of the data fields in the data fields (e.g., a type name format marker and / or an ID length marker).

[0103] The record payload can include static data elements or dynamic data elements. Exemplary data elements can be a credential, a public key, a URL, a counter value, etc. In some embodiments, the record payload can be encrypted and / or encoded by a symmetric or asymmetric key. Still referring to record 502, record payload 502B can include a credential that can be used to obtain access to a resource and / or location. Record 504 and record 506 can additionally include record payloads that include a cryptogram and a counter value, respectively. In some embodiments, the record payload can be split into more than one record. For example, record payload 502B can include only a portion of a credential, while a corresponding record payload of another record 508 (not depicted in the figure) includes the remaining portion of the credential. Thus, a device (e.g., an access device) that receives the multi-record message 500 can extract data from both record payload 502B and the record payload of record 508 in order to obtain the entire credential.

[0104] Figure 6 A block diagram of an access device 600 according to embodiments of the application is shown. The access device can include a processor 602 and a network interface 606 for receiving messages (e.g., but not limited to, multi-record messages, authorization request messages, and / or authorization response messages) and transmitting the messages to one or more entities (e.g., user device 400 and / or an authorization computer). The access device 600 can also include a device reader 608 for reading data from a user device (e.g., via NFC).

[0105] The access device 600 can include a non-transitory computer readable medium 604 that includes a message processing module 604A and an authorization processing module 604B. The message processing module 604A can include code that is executable by the processor 602 to read the contents of a received multi-record message and determine whether the message is suitable for sending to an authorization computer (or a payment processor in communication with the authorization computer).

[0106] The authorization processing module 604B can be used in conjunction with the processor 602 to convert the multi-record message into a second message that includes at least one or more dynamic elements included in the multi-record message, and send the second message to the authorization computer (or payment processor). In some embodiments, the second message can be a standard authorization request message. In further embodiments, the authorization processing module 604B can receive an authorization response message from the authorization computer (or payment processor), and determine whether to grant access to a resource and / or location to a user based on the authorization response message.

[0107] The non-transitory computer-readable medium 604 can include code, executable by the processor 602, for implementing a method comprising: initiating communication with a user device; receiving a multi-record message from the user device, wherein the multi-record message includes at least a counter value, a cryptogram, and a credential; extracting the counter value, the cryptogram, and the credential from the multi-record message; generating an authorization request message, wherein the authorization request message includes at least the extracted counter value, the cryptogram, and the credential; transmitting, by the access device, the authorization request message to an authorization computer; receiving, by the access device, an authorization response message from the authorization computer.

[0108] Embodiments of the present invention have a number of technical advantages. Embodiments of the present invention include a user device that is able to interact with different types of access devices while maintaining security for all types of access devices. Embodiments of the present invention can also allow different applications for different access devices to share credentials and cryptogram keys via an API. This improves data security and reduces data storage requirements because credentials and cryptogram keys do not have to be stored as duplicates on the user device.

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

[0110] 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 present invention.

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

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

Claims

1. A method for performing an interaction, the method comprising: storing, by a user device, a message data template comprising a data field of a counter value, a cryptogram, and a payment credential, the user device comprising an NDEF applet for generating a multi-record message and comprising a counter, a secure access application storing the payment credential and a cryptogram key for identifying an account of a user of the user device, and an API allowing communication between the NDEF applet and the secure access application, the message data template for forming a multi-record message, and the user device being a mobile phone or a payment card, wherein the NDEF applet is configured to communicate with an access device of a first type capable of processing multi-record messages, and the secure access application is configured to communicate with an access device of a second type suitable for processing standard credit and debit card transactions; initiating, by the user device, the interaction with the access device of the first type; incrementing, by the user device, the counter in the NDEF applet on the user device to produce the counter value; generating, by the user device, the cryptogram, wherein the cryptogram comprises a dynamic cryptogram, and wherein the generating comprises encrypting the counter value using a cryptogram key and a cryptogram generation algorithm to form the dynamic cryptogram; incorporating, by the NDEF applet on the user device, i) the counter value, ii) the dynamic cryptogram, and iii) the payment credential into the data field of the message data template to form a multi-record message; and transmitting, by the user device, the multi-record message to the access device, wherein the access device is programmed to generate an authorization request message in ISO 8583 format and communicate the authorization request message to an authorization computer for authorization, the authorization request message comprising i) the counter value, ii) the dynamic cryptogram, iii) the payment credential, and a transaction amount.

2. The method of claim 1, wherein the multi-record message is an NDEF message.

3. The method of claim 2, wherein the multi-record message comprises a plurality of records, and the plurality of records comprises a first record for the payment credential, a second record for the cryptogram, and a third record for the counter.

4. The method of claim 1, wherein the payment credential is a payment token or a PAN.

5. The method of claim 1, wherein the access device is the mobile phone.

6. The method of claim 1, wherein the interaction is a payment transaction.

7. The method of claim 1, wherein the message data template is generated by the authorization computer.

8. The method of claim 1, wherein the message data template is generated by a third party associated with the authorization computer.

9. The method of claim 8, wherein the authorization computer is an issuer computer.

10. The method of claim 1, wherein the multi-record message is a base64 string.

11. A user device comprising: ​ a processor, and a computer readable medium comprising an NDEF applet for generating a multi-record message and comprising a counter, a secure access application storing a payment credential and a cryptographic key for identifying a user of the user device, and an API allowing communication between the NDEF applet and the secure access application, wherein the NDEF applet is configured to communicate with a first type of access device capable of processing multi-record messages, and the secure access application is configured to communicate with a second type of access device suitable for processing standard credit and debit card transactions, the computer readable medium comprising code executable by the processor for performing a method comprising: storing a message data template comprising a data field for a counter value, a cryptogram, and the payment credential, the message data template for forming a multi-record message, and the user device being a mobile phone or a payment card; initiating an interaction with an access device, wherein the access device is the first type of access device; incrementing the counter in the NDEF applet on the user device to produce the counter value; generating the cryptogram, wherein the cryptogram comprises a dynamic cryptogram, and wherein the generating comprises encrypting the counter value using a cryptographic key and a cryptographic generation algorithm to form the dynamic cryptogram; incorporating, by the NDEF applet, i) the counter value, ii) the dynamic cryptogram, and iii) the payment credential into the data field of the message data template to form a multi-record message; and transmitting the multi-record message to the access device, wherein the access device is programmed to generate an authorization request message in ISO 8583 format and communicate the authorization request message to an authorization computer for authorization, the authorization request message comprising i) the counter value, ii) the dynamic cryptogram, iii) the payment credential, and a transaction amount.

12. The user device of claim 11, wherein the message data template is stored on an NFC tag element.

13. The user device of claim 12, wherein the NFC tag element is an NFC type 4 tag.

14. The user device of claim 11, wherein the user device is the mobile phone.

15. The user device of claim 11, wherein the user device is the payment card.

16. The user device of claim 11, wherein the cryptographic key is a secret key.

17. The user device of claim 16, wherein the cryptographic generation algorithm is 3DES or AES.

18. The user device of claim 16, wherein the secret key is provided to the user device by the authorization computer.

19. The user device of claim 11, wherein the payment credential is retrievable from a secure element of the user device.

20. A method for performing an interaction, the method comprising: ​ initiating, by an access device, a communication with a user device according to any of claims 11-19, wherein the user device is a mobile phone or a payment card and the access device is the first type of access device; receiving, by the access device from the user device, the multi-record message, wherein the multi-record message includes at least the counter value, the cryptogram, and the payment credential, wherein the cryptogram includes the dynamic cryptogram, and wherein the cryptogram is generated by encrypting the counter value using the cryptogram key and the cryptogram generation algorithm to form the dynamic cryptogram; extracting, by the access device from the multi-record message, the counter value, the cryptogram, and the payment credential; generating, by the access device, an authorization request message in ISO 8583 format, wherein the authorization request message includes at least the extracted counter value, cryptogram, payment credential, and transaction amount; transmitting, by the access device, the authorization request message to an authorization computer for authorization; and receiving, by the access device from the authorization computer, an authorization response message.

Images