System and method for password authentication of a contactless card

Abstract

Example embodiments of systems and methods for data transmission between a transmitting device and a receiving device for use in tap-and-go stores are provided. In example embodiments, the transmitting device can generate a diversified key using a master key, protect a counter value, and encrypt data prior to transmitting the data to the receiving device, which can generate a diversified key based on the master key and can decrypt the data and verify the protected counter value using the diversified key. The disclosed systems allow a user to utilize the disclosed transmitting device to purchase an item.

Description

[0001] Cross Reference to Related Applications

[0002] This application is a continuation-in-part of U.S. Patent Application 16 / 205,119, filed November 29, 2018, and claims priority from U.S. Application 62 / 740,352, filed October 2, 2018, and U.S. Patent Application 16 / 590,051, filed October 1, 2019, the entire disclosures of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure relates to cryptography, and more particularly, to systems and methods for cryptographic authentication of contactless cards to improve logistics and security of retail and storage facilities. BACKGROUND

[0004] Data security and transaction integrity are of paramount importance to businesses and consumers. This need continues to grow as electronic transactions comprise an increasing share of commercial activity. In many retail environments, a customer walks into a store and selects items one at a time to purchase. The customer typically brings these items to a cashier, where they are scanned one at a time to determine the total cost of the items. Now, an increasing number of such transactions are electronic transactions.

[0005] In some locations, a customer can scan items themselves, rather than bringing the collected items to a cashier. In this case, the customer scans each item one at a time, and the total cost of the items is determined by an automated register. The customer typically pays for the selected items using a payment card or other form of electronic transaction.

[0006] Emails can be used as a tool to validate transactions, but emails are vulnerable to attack and are susceptible to hacking or other unauthorized access. Short Message Service (SMS) messages can also be used, but these are also vulnerable to compromise. Moreover, even data encryption algorithms, such as the Triple DES algorithm, have similar vulnerabilities.

[0007] These and other deficiencies exist. Accordingly, there is a need to provide a user with an appropriate solution to overcome these deficiencies to provide data security, validation, and authentication for contactless cards, while streamlining the retail purchase process, enhancing merchandise security, and improving the cost and efficiency of retail transactions. Moreover, there is a need for improved methods of recording items to be purchased, managing store inventory, and determining costs. SUMMARY

[0008] Aspects of the disclosed technology include systems and methods for cryptographic authentication of contactless cards. Various embodiments describe systems and methods for implementing and managing cryptographic authentication of contactless cards.

[0009] Embodiments of the present disclosure provide a data transmission system, comprising: a contactless card comprising a processor, a memory containing an applet and a product list, and a contactless communication interface; an authentication server in data communication with one or more inventory management devices, each inventory management device comprising: a processor, and a contactless communication interface configured to generate a contactless communication field, wherein, upon entry of the contactless card into the contactless communication field of an inventory management device, the inventory management device is configured to: request an identification token from the applet; authenticate the identification token by generating an identification message based on the identification token; send the identification message to the authentication server; receive an authentication message from the authentication server; and send a product message to the contactless card, wherein, upon receipt of the product message, the contactless card updates the product list based on the received product message; and a contactless point of sale device comprising a processor and a contactless communication interface, wherein, upon entry of the contactless card into the contactless communication field of the point of sale, the point of sale device is configured to: request the product list from the contactless card; receive a product list message from the contactless card; and perform an operation based on the product list message.

[0010] Embodiments of the present disclosure provide a method of transmitting a data product, the method comprising: providing a transmitting device comprising a processor, a memory containing an applet and a product list, and a contactless communication interface; moving the transmitting device into a communication field of a receiving device in data communication with an authorization server, the receiving device: requesting an identification token from the applet; authenticating the identification token by generating an identification message based on the identification token; and sending the identification message to the authentication server; and moving the transmitting device into a communication field of an inventory management device associated with a retail product, the inventory management device sending a product message to the transmitting device; the transmitting device modifying the product list based on the received product message; moving the transmitting device into a communication field of a point of sale comprising a processor and a contactless communication interface; the point of sale: requesting a product list message from the transmitting device; receiving the product list message from the transmitting device; and performing a financial transaction.

[0011] Embodiments of the present disclosure provide a checkout system comprising: a transmitting device comprising a processor, a memory containing an applet and a product list, and a contactless communication interface; a receiving device comprising a processor and a contactless communication interface configured to generate a near field communication field; a remote authentication server in data communication with the receiving device, wherein, when the transmitting device enters the near field communication field of the receiving device, the receiving device is configured to: request an identification token; upon receiving the identification token, generate an identification message based on the identification token; transmit the identification message to the remote authentication server; receive an authentication message from the authentication server; generate an authorization token based on the authentication message; and transmit the authorization token to the transmitting device; and an inventory management device comprising a processor and a contactless communication interface configured to generate a near field communication field, the inventory management device configured to: request the authorization token from the transmitting device, and upon receiving the authorization token from the transmitting device, transmit a product message to the transmitting device; and a point of sale device comprising a processor and a contactless communication interface configured to generate a near field communication field, the point of sale device in data communication with a weight sensor configured to: determine a weight of one or more retail products; and transmit a product weight message to the point of sale, the product weight message comprising a measured product weight; the point of sale configured to, when the transmitting device enters the near field communication field of the point of sale: request a product list message from the transmitting device; receive the product list message from the transmitting device; and request product weight information from the weight sensor; receive the product weight message from the weight sensor; determine an expected product weight based on the product list message received from the transmitting device; determine a difference between the expected product weight and the measured product weight; and perform an operation when the difference between the expected product weight and the measured product weight is less than a predetermined amount.

[0012] Other features of the disclosed designs and advantages provided by the same are explained in more detail in the following with reference to specific example embodiments shown in the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1A is a diagram of a data transmission system according to example embodiments.

[0014] Figure 1A is a diagram illustrating a sequence for providing authenticated access according to example embodiments.

[0015] Figure 2 is a diagram of a data transmission system according to example embodiments.

[0016] Figure 3 is a diagram of a system using a contactless card according to example embodiments.

[0017] Figure 4 is a flowchart illustrating a method of key diversification according to example embodiments.

[0018] Figure 5A is an illustration of a contactless card according to example embodiments.

[0019] Figure 5B is an illustration of a contact pad of a contactless card according to example embodiments.

[0020] Figure 6 is an illustration depicting messages communicated with a device according to example embodiments.

[0021] Figure 7 is an illustration depicting messages and message formats according to example embodiments.

[0022] Figure 8 is a flowchart showing key operations according to example embodiments.

[0023] Figure 9 is a diagram of a key system according to example embodiments.

[0024] Figure 10 is a flowchart of a method of generating a password according to example embodiments.

[0025] Figure 11 is a flowchart showing a process of key diversification according to example embodiments.

[0026] Figure 12 is a flowchart showing a method for card activation according to example embodiments.

[0027] Figure 13 is a diagram of a system according to example embodiments.

[0028] Figure 14 is a diagram of a system including an auxiliary device according to example embodiments.

[0029] Figure 15 is a diagram of a system including a weight sensor according to example embodiments.

[0030] Figure 16 is a flowchart of a method for use of the disclosed system according to example embodiments.

[0031] Figure 17 is a flowchart of a method for use of the disclosed system according to example embodiments. DETAILED DESCRIPTION

[0032] The following description of embodiments provides non-limiting examples of reference numerals to particularly describe features and teachings of different aspects of the present application. From the description of the embodiments, one skilled in the art will recognize that the described embodiments can be implemented in combination with other embodiments or independently of other embodiments. One skilled in the art will recognize from the description of the embodiments the appropriate implementation of the different described aspects of the application. The description of the embodiments should not be viewed as

[0033] It is an object of some embodiments of the present disclosure to build one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform authentication and many other functions that otherwise the user can need to carry a separate physical token in addition to the contactless card. By employing a contactless interface, the contactless card can be provided with a method of interacting and communicating between the user's device (e.g., a mobile phone) and the card itself. For example, the EMV protocol, which is the basis of many credit card transactions, includes an authentication process that meets the requirements of the operating system, but presents a challenge - it is more restrictive in its use of near field communication (NFC) because it can only be used in read-only mode. The example embodiments of the contactless card described herein take advantage of NFC technology.

[0034] Figure 1A A data transfer system according to example embodiments is shown. As discussed further below, the system 100 can include a contactless card 105, a client device 110, a network 115, and a server 120. Although Figure 1A A single instance of a component is shown, but the system 100 can include any number of components.

[0035] The system 100 can include one or more contactless cards 105, which will be further described below with reference to Figures 5A-5B In some embodiments, the contactless card 105 can utilize NFC to wirelessly communicate with the client device 110 in the example.

[0036] The system 100 can include a client device 110, which can be a network-enabled computer. As referred to herein, a network-enabled computer can include, but is not limited to, a computer device or a communication device, including, for example, a server, a network appliance device, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a thin client, a thick client, an Internet browser, or other device. The client device 110 can also be a mobile device. For example, a mobile device can include a mobile phone from​​ iPhone, iPod, iPad, or running Apple software Any other mobile device running Microsoft's operating system. Any device running the Mobile operating system, or Google... Any device with an operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0037] Client device 110 may include a processor and memory, and it should be understood that the processing circuitry may include additional components, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as required to perform the functions described herein. Client device 110 may also include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen, including: liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. Input devices may include any device for inputting information into the user device for use by and supported by the user device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices can be used to input information and interact with the software and other devices described herein.

[0038] In some examples, the client device 110 of system 100 may execute one or more applications, such as software applications, which enable, for example, to communicate over a network with one or more components of system 100 and to send and / or receive data.

[0039] Client device 110 can communicate with one or more servers 120 via one or more networks 115 and can operate as a corresponding front-end to back-end pairing with server 120. Client device 110 can send one or more requests to server 120, for example, from a mobile device application running on client device 110. The one or more requests can be associated with retrieving data from server 120. Server 120 can receive one or more requests from client device 110. Based on the one or more requests from client device 110, server 120 can be configured to retrieve the requested data from one or more databases (not shown). Based on the received requested data from one or more databases, server 120 can be configured to send the received data to client device 110, wherein the received data is in response to one or more requests.

[0040] The system 100 can include one or more networks 115. In some examples, the network 115 can be one or more of a wireless network, a wired network, or any combination thereof and can be configured to connect the client device 110 to the server 120. For example, the network 115 can include one or more of the following: a fiber optic network, a passive optical network, a cable network, the Internet network, a satellite network, a wireless local area network (LAN), a Global System for Mobile Communications, a Personal Communications Service, a Personal Area Network, a Wireless Application Protocol, a Multimedia Messaging Service, an Enhanced Messaging Service, a Short Message Service, a time division multiplexed based system, a code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, etc.

[0041] Additionally, the network 115 can include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. Additionally, the network 115 can support an Internet network, a wireless communication network, a cellular network, etc., or any combination thereof. The network 115 can further include one network, or any number of the example types of networks described above, operating as a stand-alone network or in cooperation with each other. The network 115 can utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 115 can translate to or from one or more protocols of the network devices. Although the network 115 is depicted as a single network, it should be understood that the network 115 can include a plurality of interconnected networks, such as the Internet, a network of service providers, a cable television network, a corporate network (such as a credit card association network), and a home network, in accordance with one or more examples.

[0042] The system 100 can include one or more servers 120. In some examples, the server 120 can include one or more processors coupled to a memory. The server 120 can be configured as a central system, server, or platform to control and invoke various data at different times to perform a plurality of workflow actions. The server 120 can be configured to connect to one or more databases. The server 120 can connect to at least one client device 110.

[0043] Figure 1B is a timing diagram illustrating an example sequence for providing authenticated access in accordance with one or more embodiments of the present disclosure. The system 100 can include a contactless card 105 and a client device 110, which can include an application 122 and a processor 124. Figure 1B Components in Figure 1A may refer to similar components as shown in

[0044] At step 102, the application 122 communicates with the contactless card 105 (e.g., after being brought into proximity with the contactless card 105). The communication between the application 122 and the contactless card 105 can include the contactless card 105 being brought close enough to a card reader (not shown) of the client device 110 to enable NFC data transfer between the application 122 and the contactless card 105.

[0045] At step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a message authentication code (MAC) cryptogram. In some examples, this can occur when the application 122 reads the contactless card 105. In particular, this can occur when reading (e.g., NFC reading) a near field data exchange (NDEF) tag, which can be created according to the NFC data exchange format. For example, a reader such as the application 122 can send a message such as an Applet Select message with an Applet ID that produces an NDEF Applet. After confirming the selection, a Select File message can be sent followed by a sequence of Read File messages. For example, the sequence can include “Select Function File,” “Read Function File,” and “Select NDEF File.” At this point, a counter value maintained by the contactless card 105 can be updated or incremented, which can be followed by “Read NDEF File.” At this point, a message that can include a header and a shared secret can be generated. A session key can then be generated. A MAC cryptogram can be created from a message that can include the header and the shared secret. The MAC cryptogram can then be concatenated with one or more blocks of random data, which can then be encrypted with the session key. Thereafter, the cryptogram and the header can be concatenated and encoded as ASCII hexadecimal and returned in an NDEF message format (in response to the “Read NDEF File” message).

[0046] In some examples, the MAC cryptogram can be sent as an NDEF tag, and in other examples, the MAC cryptogram can be included as a uniform resource indicator (e.g., as a formatted string).

[0047] In some examples, the application 122 can be configured to send a request to the contactless card 105 that includes instructions for generating the MAC cryptogram.

[0048] At step 106, the contactless card 105 sends the MAC cryptogram to the application 122. In some examples, the transmission of the MAC cryptogram occurs via NFC, although the present disclosure is not so limited. In other examples, the communication can occur via Bluetooth, Wi-Fi, or other means of wireless data communication.

[0049] In step 108, application 122 transmits the MAC password to processor 124.

[0050] In step 112, the processor 124 verifies the MAC password according to instructions from the application 122. For example, the MAC password can be verified as described below.

[0051] In some examples, the MAC password verification operation can be performed by a device other than client device 110 (such as server 120 that communicates with client device 110). Figure 1A (As shown). For example, processor 124 can output a MAC password to be transmitted to server 120, which can verify the MAC password.

[0052] In some examples, a MAC cipher can be used as a digital signature for verification purposes. Other digital signature algorithms, such as public-key asymmetric algorithms like the Digital Signature Algorithm and RSA, or zero-knowledge protocols, can be used to perform this verification.

[0053] Figure 2 A data transmission system according to an example embodiment is illustrated. System 200 may include, for example, a transmitting or sending device 205 communicating with one or more servers 220 via network 215, and a receiving or receiving device 210. The transmitting or sending device 205 may be related to the above-referenced... Figure 1A The client device 110 discussed is the same as or similar to the one mentioned above. The receiving or receiver device 210 can be the same as the one mentioned above. Figure 1A The client device 110 discussed is the same as or similar to the one mentioned above. Network 215 may be similar to the one mentioned above. Figure 1A The discussion focuses on network 115. Server 220 can be similar to the above references. Figure 1A The server being discussed is 120. Although... Figure 2 A single instance of the components of system 200 is shown, but system 200 may include any number of the components shown.

[0054] When using symmetric cryptographic algorithms, such as encryption algorithms, hash-based message authentication codes (HMAC) and ciphertext-based message authentication codes (CMAC), it is important that the key remain secret between the party initially processing the data protected using the symmetric algorithm and key, and the party receiving and processing the data using the same cryptographic algorithm and key.

[0055] It is also important that the same key not be used too many times. If a key is used or reused too frequently, it can be compromised. Each time a key is used, an attacker is provided with an additional sample of data that has been processed by the cryptographic algorithm using the same key. The more data that an attacker has that has been processed using the same key, the greater the likelihood that the attacker can discover the key value. Frequently used keys can be included in a variety of different attacks.

[0056] Furthermore, each time a symmetric cryptographic algorithm is executed, it can reveal information about the key used during the symmetric cryptographic operation, such as side-channel data. Side-channel data can include minute power fluctuations that occur when an encryption algorithm is executed while using a key. Side-channel data can be measured enough to reveal enough information about the key to enable it to be recovered by an attacker. Exchanging data using the same key will repeatedly reveal data that has been processed by the same key.

[0057] However, by limiting the number of times a particular key will be used, the amount of side-channel data that an attacker is able to collect is limited, reducing exposure to this and other types of attacks. As further described herein, the parties involved in the exchange of cryptographic information (e.g., a sender and a recipient) can independently generate a key from an initially shared master symmetric key in combination with a counter value, whereby the shared symmetric key being used is periodically replaced in response to the need to synchronize the parties by any form of key exchange. By periodically changing the shared secret symmetric key used by the sender and the recipient, the above attacks become impossible.

[0058] Returning to Figure 2, system 200 can be configured to implement key diversification. For example, a sender and a recipient can wish to exchange data (e.g., raw sensitive data) via respective devices 205 and 210. As noted above, although a single instance of a sending device 205 and a receiving device 210 can be included, it should be understood that one or more sending devices 205 and one or more receiving devices 210 can be involved, so long as each party shares the same shared secret symmetric key. In some examples, the same master symmetric key can be provided to the sending device 205 and the receiving device 210. Further, it should be understood that any party or device that possesses the same secret symmetric key can perform the functions of the sending device 205, and similarly, any party that possesses the same secret symmetric key can perform the functions of the receiving device 210. In some examples, the symmetric key can include a shared secret symmetric key that is kept secret from all other parties except the sending device 205 and the receiving device 210 involved in the exchange of secure data. It should also be understood that both the sending device 205 and the receiving device 210 can be provided with the same master symmetric key, and further, that a portion of the data exchanged between the sending device 205 and the receiving device 210 includes at least a portion of data that can be referred to as a counter value. The counter value can include a number that changes each time data is exchanged between the sending device 205 and the receiving device 210.

[0059] System 200 can include one or more networks 215. In some examples, network 215 can be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and can be configured to connect one or more sending devices 205 and one or more receiving devices 210 to server 220. For example, network 215 can include one or more of a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communications, a Personal Communications Service, a Personal Area Network, a Wireless Application Protocol, a Multimedia Messaging Service, an Enhanced Messaging Service, a Short Message Service, a system based on time division multiple access, a system based on code division multiple access, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.1 lb, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, etc.

[0060] Additionally, network 215 can include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethemet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, network 215 can support Internet networks, wireless communication networks, cellular networks, and the like, or any combination thereof. Network 215 can further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network 215 can utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 215 can translate to or from other protocols of the network devices. Although network 215 is depicted as a single network, it should be understood that network 215 can include a plurality of interconnected networks, such as the Internet, networks of service providers, cable networks, corporate networks (such as credit card association networks), and home networks, according to one or more examples.

[0061] In some examples, one or more transmitting devices 205 and one or more receiving devices 210 can be configured to communicate data, transmit and receive data between each other without going through network 215. For example, communication between one or more transmitting devices 205 and one or more receiving devices 210 can occur via at least one of NFC, Bluetooth, RFID, Wi-Fi, and the like.

[0062] At block 225, the sender can update the counter when the transmitting device 205 is preparing to process sensitive data using a symmetric cryptographic operation. Additionally, the transmitting device 205 can select an appropriate symmetric cryptographic algorithm, which can include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm used to process the diversified value can include any symmetric cryptographic algorithm used to generate a diversified symmetric key of a desired length as needed. Non-limiting examples of symmetric algorithms can include symmetric encryption algorithms such as 3DES or AES 128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. It should be understood that if the output of the selected symmetric algorithm does not generate a key of sufficient length, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key can yield multiple outputs, which can be combined as needed to produce a key of sufficient length.

[0063] At block 230, the sending device 205 can employ the selected cryptographic algorithm and process the counter value using the master symmetric key. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated with each session between the sending device 205 and the receiving device 210. The sending device 205 can then encrypt the counter value using the selected symmetric encryption algorithm using the master symmetric key, creating a diversified symmetric key.

[0064] In certain examples, the counter value can not be encrypted. In these examples, the counter value can be transmitted between the sending device 205 and the receiving device 210 at block 230 without encryption.

[0065] At block 235, the sensitive data can be processed using the diversified symmetric key before the result is sent to the receiving device 210. For example, the sending device 205 can use the diversified symmetric key to encrypt the sensitive data using a symmetric encryption algorithm, where the output includes protected encrypted data. The sending device 205 can then send the protected encrypted data, along with the counter value, to the receiving device 210 for processing.

[0066] At block 240, the receiving device 210 can first obtain the counter value and then perform the same symmetric encryption using the counter value as input to the encryption and the master symmetric key as the key used for the encryption. The output of the encryption can be the same diversified symmetric key value created by the sender.

[0067] At block 245, the receiving device 210 can then obtain the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm and the diversified symmetric key.

[0068] At block 250, as a result of decrypting the protected encrypted data, the original sensitive data can be revealed.

[0069] The next time sensitive data needs to be sent from a sender to a recipient via a respective sending device 205 and receiving device 210, a different counter value can be selected to produce a different diversified symmetric key. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device 205 and the receiving device 210 can independently produce the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the sensitive data.

[0070] As described above, both the sending device 205 and the receiving device 210 initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Because the diversified symmetric key is independently created by both the sending device 205 and the receiving device 210, it is never transmitted between the two. Thus, an attacker cannot intercept the diversified symmetric key, and the attacker never sees any data that has been processed using the master symmetric key. The master symmetric key is used to process only the counter value, not the sensitive data. As a result, reduced side-channel data is revealed about the master symmetric key. Moreover, the operation of the sending device 205 and the receiving device 210 can be controlled by the symmetry requirements about how often a new diversified value, and thus a new diversified symmetric key, is created. In one embodiment, a new diversified value, and thus a new diversified symmetric key, can be created for each exchange between the sending device 205 and the receiving device 210.

[0071] In some examples, the key diversification value can include a counter value. Other non-limiting examples of key diversification values include a random nonce generated each time a new diversified key is needed, the random nonce being transmitted from the sending device 205 to the receiving device 210; a full value of a counter value transmitted from the sending device 205 and the receiving device 210; a portion of a counter value transmitted from the sending device 205 and the receiving device 210; a counter independently maintained by the sending device 205 and the receiving device 210 but not transmitted between the two devices; a one-time password exchanged between the sending device 205 and the receiving device 210; and a cryptographic hash of the sensitive data. In some examples, one or more portions of the key diversification value can be used by the parties to create multiple diversified keys. For example, a counter can be used as the key diversification value. In addition, a combination of one or more of the example key diversification values described above can be used.

[0072] In another example, a portion of a counter can be used as the key diversification value. If multiple master key values are shared between the parties, multiple diversified key values can be obtained through the systems and processes described herein. New diversified values, and thus new diversified symmetric keys, can be created as often as desired. In the most secure case, a new diversified value can be created for each exchange of sensitive data between the sending device 205 and the receiving device 210. In practice, this can create a one-time use key, such as a one-time session key.

[0073] Figure 3 A system 300 using a contactless card is shown. The system 300 can include a contactless card 305, one or more client devices 310, a network 315, servers 320, 325, one or more hardware security modules 330, and a database 335. Although Figure 3A single instance of the component is shown, but the system 300 can include any number of components.

[0074] The system 300 can include one or more contactless cards 305, described below with respect to Figures 5A-5B Further explanation. In some examples, the contactless card 305 can be in wireless communication with the client device 310, such as NFC communication. For example, the contactless card 305 can include one or more chips, such as a radio frequency identification chip, configured to communicate via NFC or other short-range protocol. In other embodiments, the contactless card 305 can communicate with the client device 310 by other means, including but not limited to: Bluetooth, satellite, Wi-Fi, wired communication, and / or any combination of wireless and wired connections. According to some embodiments, the contactless card 305 can be configured to communicate with the card reader 313 of the client device 310 via NFC when the contactless card 305 is within range of the card reader 313. In other examples, communication with the contactless card 305 can be achieved through a physical interface (e.g., a universal serial bus interface or a card swipe interface).

[0075] The system 300 can include a client device 310, which can be a network-enabled computer. As referred to herein, a network-enabled computer can include, but is not limited to, for example, a computer device, or a communication device, including, for example, a server, a network appliance device, a personal computer, a workstation, a mobile device, a telephone, a handheld PC, a personal digital assistant, a thin client, a thick client, an Internet browser, or other device. One or more client devices 310 can also be a mobile device. For example, a mobile device can include an iPhone, iPod, iPad, or any other mobile device running Apple's Darwin operating system, any device running Microsoft's Windows Mobile operating system, any device running Google's Android operating system, and / or any other smartphone or similar wearable mobile device. In some examples, the client device 310 can be the same as or similar to the client device 110 described with respect to Figure 1A or Figure 1B FIG. 1.

[0076] The client device 310 can communicate with one or more servers 320 and 325 via one or more networks 315. The client device 310 can send one or more requests, for example, from an application 311 executing on the client device 310 to the one or more servers 320 and 325. The one or more requests can be associated with retrieving data from the one or more servers 320 and 325. The servers 320 and 325 can receive the one or more requests from the client device 310. Based on the one or more requests from the client device 310, the one or more servers 320 and 325 can be configured to retrieve the requested data from one or more databases 335. Based on receiving the requested data from the one or more databases 335, the one or more servers 320 and 325 can be configured to send the received data to the client device 310, the received data being in response to the one or more requests.

[0077] The system 300 can include one or more hardware security modules (HSMs) 330. For example, the one or more HSMs 330 can be configured to perform one or more cryptographic operations, as disclosed herein. In some examples, the one or more HSMs 330 can be configured as a dedicated secure device configured to perform one or more cryptographic operations. The HSMs 330 can be configured such that keys are never leaked outside the HSMs 330, but are kept within the HSMs 330. For example, the one or more HSMs 330 can be configured to perform at least one of a key derivation, a decryption, and a MAC operation. The one or more HSMs 330 can be contained within the servers 320 and 325 or can be in data communication with the servers 320 and 325.

[0078] The system 300 can include one or more networks 315. In some examples, the network 315 can be one or more of a wireless network, a wired network, or any combination of wireless network and wired network, and can be configured to connect the client device 310 to the servers 320 and 325. For example, the network 315 can include one or more of the following: a fiber optic network, a passive optical network, a cable network, a cellular network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communications network, a Personal Communications Service, a Personal Area Network, a Wireless Application Protocol, a Multimedia Messaging Service, an Enhanced Messaging Service, a Short Message Service, a time division multiplexed based system, a code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, RFID, Wi-Fi, and / or any combination of the networks thereof. As non-limiting examples, communications from the contactless card 305 and the client device 310 can include: NFC communications, cellular network between the client device 310 and a carrier, and the Internet between the carrier and the backend.

[0079] Additionally, the network 315 can include, but is not limited to, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network, a wireless personal area network, a local area network, or a global network such as the Internet. Additionally, the network 315 can support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. The network 315 can further include one network, or any number of the example types of networks described above, operating as a stand-alone network or in cooperation with each other. The network 315 can utilize one or more protocols of one or more network elements to which they are communicatively coupled. The network 315 can translate to or from one or more protocols of the network devices. Although the network 315 is depicted as a single network, it should be understood that the network 315 can include a plurality of interconnected networks, such as the Internet, a network of service providers, a cable television network, a corporate network (such as a credit card association network), and a home network, in accordance with one or more examples.

[0080] In various examples in accordance with the present disclosure, the client device 310 of the system 300 can execute one or more applications 311 and include one or more processors 312 and one or more card readers 313. By way of example, the one or more applications 311 (e.g., software applications) can be configured to enable, for example, network communications with one or more components of the system 300 and to send and / or receive data. It should be understood that although the one or more applications 311 are depicted as being executed on the client device 310, the one or more applications 311 can be executed on one or more other devices, such as the server 320, in accordance with one or more examples. Figure 3Only a single instance of the components of client device 310 is shown, but any number of devices 310 can be used. Card reader 313 can be configured to read from and / or communicate with contactless card 305. In conjunction with one or more applications 311, card reader 313 can communicate with contactless card 305.

[0081] Applications 311 of any of the client devices 310 can communicate with contactless card 305 using short-range wireless communication (e.g., NFC). Applications 311 can be configured to interface with card reader 313 of client device 310, which is configured to communicate with contactless card 305. It should be noted that a distance of less than twenty centimeters is consistent with NFC range, as will be understood by those skilled in the art.

[0082] In some embodiments, applications 311 communicate with contactless card 305 through an associated reader (e.g., card reader 313).

[0083] In some embodiments, card activation can occur without user authentication. For example, contactless card 305 can communicate with applications 311 through card reader 313 of client device 310 via NFC. This communication (e.g., a tap of the card against card reader 313 of client device 310) allows applications 311 to read data associated with the card and perform activation. In some cases, the tap can activate or launch applications 311, which then initiate one or more actions or communications with account server 325 to activate the card for subsequent use. In some cases, if applications 311 are not installed on client device 310, a tap against card reader 313 can initiate the download of applications 311 (e.g., navigation to an application download page). After installation, the tap can activate or launch applications 311, which then initiate (e.g., via the application or other backend communication) activation of the card. After activation, the card can be used for various transactions, including commercial transactions.

[0084] According to some embodiments, contactless card 305 can include a virtual payment card. In those embodiments, applications 311 can retrieve information associated with contactless card 305 by accessing a digital wallet implemented on client device 310, where the digital wallet includes the virtual payment card. In some examples, virtual payment card data can include one or more static or dynamically generated virtual card numbers.

[0085] The server 320 can include a web server in communication with the database 335. The server 325 can include an account server. In some examples, the server 320 can be configured to verify one or more credentials from the contactless card 305 and / or the client device 310 by comparing the one or more credentials to one or more credentials in the database 335. The server 325 can be configured to authorize one or more requests, such as payments and transactions, from the contactless card 305 and / or the client device 310.

[0086] Figure 4 A method 400 of key diversification is shown in accordance with examples of the present disclosure. The method 400 can include a sending device and a receiving device similar to the sending device 205 and the receiving device 210 referred to in the background. Figure 2 The sending device and the receiving device can be similar to the sending device 205 and the receiving device 210 referred to in the background.

[0087] For example, a sender and a recipient can wish to exchange data (e.g., raw sensitive data) via a sending device and a receiving device. As noted above, although both parties can be included, it should be understood that one or more sending devices and one or more receiving devices can be involved, so long as each party shares the same shared secret symmetric key. In some examples, the sending device and the receiving device can be provided with the same master symmetric key. Further, it should be understood that any party or device holding the same secret symmetric key can perform the functions of the sending device, and similarly, any party holding the same secret symmetric key can perform the functions of the receiving device. In some examples, the symmetric key can include a shared secret symmetric key that is kept secret from all other parties except the sending device and the receiving device involved in the exchange of secure data. It should also be understood that the sending device and the receiving device can both be provided with the same master symmetric key, and further, that a portion of the data exchanged between the sending device and the receiving device includes at least a portion of the data that can be referred to as a counter value. The counter value can include a number that changes each time data is exchanged between the sending device and the receiving device.

[0088] At block 410, the same master key, e.g., the same master symmetric key, can be provided to the sending device and the receiving device. When the sending device is ready to process sensitive data using a symmetric cryptographic operation, the sender can update the counter. Additionally, the sending device can select an appropriate symmetric cryptographic algorithm, which can include at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm used to process the diversification value can include any symmetric cryptographic algorithm used to generate a desired length diversified symmetric key as needed. Non-limiting examples of symmetric algorithms can include symmetric encryption algorithms such as 3DES or AES 128; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. It will be appreciated that if the output of the selected symmetric algorithm does not generate a key of sufficient length, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key can yield multiple outputs, which can be combined as needed to produce a key of sufficient length.

[0089] The sending device can employ the selected cryptographic algorithm and use the master symmetric key to process the counter value. For example, the sender can select a symmetric encryption algorithm and use the counter that is updated with each session between the sending device and the receiving device.

[0090] At block 420, the sending device can then encrypt the counter value using the master symmetric key through the selected symmetric encryption algorithm, creating a diversified symmetric key. The diversified symmetric key can be used to process sensitive data prior to transmitting the results to the receiving device. For example, the sending device can encrypt sensitive data using a symmetric encryption algorithm that uses the diversified symmetric key, where the output includes protected encrypted data. The sending device can then transmit the protected encrypted data, along with the counter value, to the receiving device for processing. In some examples, cryptographic operations other than encryption can be performed, and multiple cryptographic operations can be performed using the diversified symmetric key prior to transmitting the protected data.

[0091] In certain examples, the counter value can not be encrypted. In these examples, the counter value can be transmitted between the sending device and the receiving device at block 420 without encryption.

[0092] At block 430, sensitive data can be protected using one or more cryptographic algorithms and diversified keys. The diversified session key (created by key diversification using the counter) can be used with one or more cryptographic algorithms to protect sensitive data. For example, data can be processed by a MAC using a first diversified session key, and the resulting output can be encrypted using a second diversified session key, producing protected data.

[0093] At block 440, the receiving device can perform the same symmetric encryption using the counter value as input to the encryption and using the master symmetric key as the key for the encryption. The output of the encryption can be the same symmetric key value that the sender created. For example, the receiving device can independently create its own copies of the first and second diversified session keys using the counter. The receiving device can then use the second diversified session key to decrypt the protected data to reveal the output of the MAC created by the sending device. The receiving device can then use the first diversified session key to process the resulting data through the MAC operation.

[0094] At block 450, the receiving device can use the diversified key with one or more cryptographic algorithms to verify the protected data.

[0095] At block 460, the original data can be verified. If the output of the MAC operation (via the receiving device using the first diversified session key) matches the MAC output revealed by the decryption, the data can be deemed valid.

[0096] The next time sensitive data needs to be sent from the sending device to the receiving device, a different counter value can be selected, which results in a different diversified symmetric key. By processing the counter value using the master symmetric key and the same symmetric cryptographic algorithm, both the sending device and the receiving device can independently produce the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the sensitive data.

[0097] As described above, both the sending device and the receiving device initially have a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Because the diversified symmetric key is created independently by the sending device and the receiving device, it is never transmitted between the two. Thus, an attacker cannot intercept the diversified symmetric key, and the attacker never sees any data that is processed using the master symmetric key. The master symmetric key is processed only with a small counter value, not the sensitive data. As a result, reduced side-channel data is revealed about the master symmetric key. Also, the sender and receiver can agree, for example through a prior arrangement or otherwise, how often to create a new diversified value, and thus a new diversified symmetric key. In one embodiment, a new diversified value, and thus a new diversified symmetric key, can be created for each exchange between the sending device and the receiving device.

[0098] In some examples, the key diversification value can comprise a counter value. Other non-limiting examples of key diversification values include: a random number generated each time a new diversified key is needed, the random number being sent from the sending device to the receiving device; a full value of a counter value sent from the sending device and the receiving device; a portion of a counter value sent from the sending device and the receiving device; a counter independently maintained by the sending device and the receiving device but not sent between the two; a one-time password exchanged between the sending device and the receiving device; a cryptographic hash of sensitive data. In some examples, one or more portions of the key diversification value can be used by the parties to create multiple diversified keys. For example, a counter can be used as the key diversification value.

[0099] In another example, a portion of a counter can be used as the key diversification value. If multiple master key values are shared between the parties, multiple diversified key values can be obtained through the systems and processes described herein. New diversified values, and thus new diversified symmetric keys, can be created as often as desired. In the most secure case, a new diversified value can be created for each exchange of sensitive data between the sending device and the receiving device. In practice, this can create a one-time use key, such as a single session key.

[0100] In other examples, such as to limit the number of uses of a master symmetric key, the sender of the sending device and the recipient of the receiving device can agree that new diversified values, and thus new diversified symmetric keys, will only occur periodically. In one example, this can be after a predetermined number of uses, such as after every ten transmissions between the sending device and the receiving device. In another example, this can be after a certain period of time, after a certain period of time after a transmission, or periodically (e.g., every day at a specified time; every week at a specified time on a specified day). In another example, this can be each time the receiving device signals to the sending device that it wishes to change the key in the next communication. This can be controlled strategically and can change due to, for example, a current level of risk perceived by the recipient of the receiving device.

[0101] Figure 5AOne or more contactless cards 500 are shown, which may include payment cards, such as credit cards, debit cards, or gift cards, issued by a service provider 505 displayed on the front or back of the card 500. In some examples, the contactless card 500 is not a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless card 500 may include a substrate 510, which may include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary substrate materials include: polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 500 according to this disclosure may have different characteristics, and this disclosure does not require the implementation of a contactless card in a payment card.

[0102] The contactless card 500 may also include identification information 515 displayed on the front and / or back of the card, and a contact pad 520. The contact pad 520 may be configured to establish a connection with another communication device, such as a user equipment, smartphone, laptop computer, desktop computer, or tablet computer. The contactless card 500 may also include processing circuitry, an antenna, and other components. Figure 5A Components not shown. These components may be located behind the contact piece 520 or at other locations on the substrate 510. The contactless card 500 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card. Figure 5A (Not shown in the image).

[0103] like Figure 5B As shown, Figure 5A The contact 520 may include processing circuitry 525 for storing and processing information, including a microprocessor 530 and a memory 535. It should be understood that the processing circuitry 525 may include additional components, including a processor, memory, error and parity / CRC checkers, a data encoder, anti-collision algorithms, a controller, a command decoder, security primitives, and tamper-proof hardware, to perform the functions described herein as required.

[0104] The memory 535 can be read only memory, write-many memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 500 can include one or more of these memories. Read only memory can be factory programmable to be read only or one-time programmable. The one-time programming function provides the opportunity to write once and then read many times. The write-many / read-often memory can be programmed at some point in time after the memory chip leaves the factory. Once the memory is programmed, it can not be rewritten, but it can be read many times. The read / write memory can be programmed and reprogrammed many times after it leaves the factory. It can also be read many times.

[0105] The memory 535 can be configured to store one or more applets 540, one or more counters 545, and a customer identifier 550. The one or more applets 540 can include one or more software applications configured to execute on one or more contactless cards, such as Java Card applets. However, it should be understood that the applets 540 are not limited to Java Card applets, but can be any software application operable on a contactless card or other device with limited memory. The one or more counters 545 can include a numeric counter sufficient to store an integer. The customer identifier 550 can include a unique alphanumeric identifier assigned to a user of the contactless card 500, and the identifier can distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 550 can identify a customer and an account assigned to the customer, and can further identify the contactless card associated with the customer’s account.

[0106] The processor and storage elements of the foregoing example embodiments are described with reference to the contact sheet, but the present disclosure is not so limited. It should be understood that these elements can be implemented external to the sheet 520 or completely separate from the sheet 520, or as other elements located outside of the processor 530 and memory 535 within the contact sheet 520.

[0107] In some examples, the contactless card 500 can include one or more antennas 555. The one or more antennas 555 can be placed within the contactless card 500 and around the processing circuitry 525 of the contact sheet 520. For example, the one or more antennas 555 can be integrally formed with the processing circuitry 525, and the one or more antennas 555 can be used with an external boost coil. As another example, the one or more antennas 555 can be external to the contact sheet 520 and the processing circuitry 525.

[0108] In one embodiment, the coil of the contactless card 500 can be used as the secondary of an air-core transformer. The terminal can communicate with the contactless card 500 by cutting the power or amplitude modulation. The contactless card 500 can use the gap in the power connection of the contactless card to infer data sent from the terminal, which can be functionally held by one or more capacitors. The contactless card 500 can backhaul by switching the load on the coil of the contactless card or load modulation. The load modulation can be detected in the coil of the terminal by interference.

[0109] As described above, the contactless card 500 can be built on a software platform that can operate on a smart card or other device with limited memory, such as a JavaCard, and can securely execute one or more applications or applets. In various mobile application-based use cases, an applet can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA). The applet can be configured to respond to one or more requests (e.g., a near field data exchange request) from a reader (e.g., a mobile NFC reader) and generate an NDEF message that includes an encrypted secure OTP encoded as an NDEF text tag.

[0110] Figure 6 An NDEF short record layout (SR = 1) 600 is shown in accordance with example embodiments. One or more applets can be configured to encode an OTP as an NDEF type 4, which is a well-known type of text tag. In some examples, the NDEF message can include one or more records. The applet can be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: well-known type, text, encoding English (en); Applet ID: D2760000850101; functionality: read-only access; encoding: authentication message can be encoded as ASCII hexadecimal; type-length-value (TLV) data can be provided as personalization parameters that can be used to generate the NDEF message. In one embodiment, the authentication template can include a first record with a well-known index for providing the actual dynamic authentication data.

[0111] Figure 7Messages 710 and message format 720 are shown, according to example embodiments. In one example, if additional tags are to be added, the first byte can be changed to indicate the start of the message instead of the end, and a subsequent record can be added. Because the ID length is zero, the ID length field and ID are omitted from the record. The message example can include: UDK AUT key; derived AUT session key (using 0x00000050); version 1.0; pATC = 0x00000050; RND = 4838FB7DC171B89E; MAC = <eight computed bytes>.

[0112] In some examples, data can be stored in the contactless card at personalization time by implementing the STORE DATA command under Secure Channel Protocol 2. One or more values can be read by the personalization bureau from the EMBOSS file (in the section specified by the Applet ID), and one or more STORE DATA commands can be sent to the contactless card after authentication and secure channel establishment.

[0113] The pUID can contain a 16-bit BCD encoded number. In some examples, the pUID can include 14 digits.

[0114]

[0115] In some examples, one or more applets can be configured to maintain their personalization state to allow personalization only after being unlocked and authenticated. Other states can include pre-personalization of the standard state. Upon entering the termination state, one or more applets can be configured to remove personalization data. In the termination state, one or more applets can be configured to stop responding to all application protocol data unit (APDU) requests.

[0116] One or more applets can be configured to maintain an applet version (2 bytes), which can be used in the authentication message. In some examples, this can be interpreted as the most significant byte major version, and the least significant byte minor version. Rules for each version are configured to interpret the authentication message: for example, regarding the major version, this can include: each major version includes a specific authentication message layout and a specific algorithm. For the minor version, this can include: no changes to the authentication message or cryptographic algorithm, and changes to static tag content other than bug fixes, security enhancements, etc.

[0117] In some examples, one or more applets can be configured to emulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, different cryptographic data is presented, which can indicate authenticity of the contactless card. Based on the one or more applications, an NFC read of the tag can be processed, a token can be sent to a server, such as a backend server, and the token can be validated on the server.

[0118] In some examples, the contactless card and the server can include certain data such that the card can be properly identified. The contactless card can include one or more unique identifiers. A counter can be configured to update each time a read operation occurs. In some examples, each time the card is read, it is sent to the server for validation and to determine if the counter is equal (as part of the validation).

[0119] One or more counters can be configured to prevent replay attacks. For example, if a cryptogram has been acquired and replayed, the cryptogram will be immediately rejected if the counter has been read or used or otherwise evaded. If the counter has not been used, it can be replayed. In certain examples, the counter updated on the card is different than the counter updated for a transaction. In some examples, the contactless card can include a first applet and a second applet, the first applet can be a transaction applet. Each applet can include a counter.

[0120] In some examples, the counter can be out of sync between the contactless card and one or more servers. For example, the contactless card can be activated to cause the counter to be updated and the contactless card to generate a new communication, but the communication can not be sent for processing at the one or more servers. This can result in the counter of the contactless card being out of sync with the counter maintained on the one or more servers. This can occur unintentionally, including, for example, when the card is stored proximate to a device (e.g., in a pocket with the device), and the contactless card is read at an angle, which can include the card being misaligned or not positioned such that the contactless card is powered under the NFC field, but the communication is not read. If the contactless card is placed proximate to the device, the NFC field of the device can turn on to power the contactless card, resulting in the counter therein being updated, but no application on the device receives the communication.

[0121] To keep the counters synchronized, an application, such as a background app, can be executed. This app is configured to detect when the mobile device wakes up and synchronize with one or more servers that indicate a read has occurred due to detection, then advances the counter. Since the contactless card's counter and one or more servers may be out of sync, one or more servers can be configured to allow the contactless card's counter to be updated by a threshold or a predetermined number of times before it is read by one or more servers and is still considered valid. For example, if the counter is configured to increment (or decrement) by one for each occurrence indicating contactless card activation, one or more servers can allow any counter value they read from the contactless card to be valid, or any counter value within a threshold range (e.g., from 1 to 10). Furthermore, one or more servers can be configured to request a gesture associated with the contactless card, such as a user's tap, if it reads a counter value that is greater than 10 but less than another threshold range (e.g., 1000). Authentication is successful upon the user's tap if the counter value is within the expected or acceptable range.

[0122] Figure 8 This is a flowchart illustrating key operation 800 according to an example embodiment. For example... Figure 8 As shown in box 810, two bank identifier number (BIN) level master keys can be combined with the account identifier and card serial number to generate two unique derived keys (UDKs) for each card. In some examples, the bank identifier number may include a number or a combination of one or more numbers, such as an account number provided by one or more servers or an unpredictable number, which can be used for session key generation and / or diversification. The UDKs (AUTKEY and ENCKEY) can be stored on the card during the personalization process.

[0123] At box 820, the counter can be used as diversification data because it changes with each use and provides a different session key each time, as opposed to master key derivation—where a unique set of keys is generated for each card. In some examples, it is best to use the 4-byte method for both operations. Therefore, at box 820, two session keys can be created for each transaction from ETDK: one session key from AEGTKEU and one session key from ENCKEY. In the card, for the MAC key (i.e., the session key created from AGTEKEU), the lower two bytes of the OTP counter can be used for diversification. For the ENC key (i.e., the session key created from ENCKEY), the full length of the OTP counter can be used for the ENC key.

[0124] At block 830, the MAC key can be used to prepare the MAC cryptogram, and the ENC key can be used to encrypt the cryptogram. For example, the MAC session key can be used to prepare the cryptogram, and it can be encrypted with the ENC key before the result is sent to the one or more servers.

[0125] At block 840, the verification and processing of the MAC is simplified because the 2-byte diversification is directly supported in the MAC authentication function of the payment HSM. The decryption of the cryptogram is performed prior to the verification of the MAC. The session keys are independently derived on the one or more servers, resulting in a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) can be used to decrypt the data, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

[0126] For contactless cards, a different unique identifier is derived that can be related to the primary account number (PAN) and PAN sequence number encoded in the card. The key diversification can be configured to receive the identifier as input with the master key, such that one or more keys can be created for each contactless card. In some examples, these diversified keys can include a first key and a second key. The first key can include an authentication master key (Card-Key-Auth), and it can be further diversified to create a MAC session key used in generating and verifying a MAC cryptogram. The second key can include an encryption master key (Card-Key-DEK), and it can be further diversified to create an ENC session key used in encrypting and decrypting encrypted data. In some examples, the issuer master key can be diversified by combining the issuer master key with the PAN sequence number (PSN) of the payment applet and the unique ID number (pUID) of the card to create the first and second keys. The pUID can include a 16-digit numeric value. As noted above, the pUID can include a 16-digit BCD-encoded number. In some examples, the pUID can include a 14-digit numeric value.

[0127] In certain examples, because the EMV session key derivation method can wrap at 2A6 uses, a counter (e.g., a full 32-bit counter) can be added to the initialization array of the diversification method.

[0128] In other examples, such as in credit cards, one or more server-provided numbers (e.g., an account number or a non-predictable number) can be used for the generation and / or diversification of the session key.

[0129] Figure 9A diagram of a system 900 configured to implement one or more embodiments of the present disclosure is shown. As described below, during a contactless card creation process, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys can include symmetric keys that can be used in the encryption and decryption of data. EMV can use a triple DES (3DES) algorithm, and the algorithm is implemented by hardware in the contactless card. By using a key diversification process, one or more keys can be derived from a master key based on unique identifiable information of each entity that requires the key.

[0130] With respect to master key management, two issuer master keys 905, 910 can be required for each portion of the layout that issues one or more applets. For example, a first master key 905 can include an issuer cryptogram generation / authentication key (Iss-Key-Auth), while a second master key 910 can include an issuer data encryption key (Iss-Key-DEK). As explained further herein, the two issuer master keys 905, 910 are diversified into card master keys 925, 930, which are unique to each card. In some examples, a network profile record ID (pNPR) 915 and a derived key index (pDKI) 920, which are background data, can be used to identify which issuer master key 905, 910 to use for authentication during encryption. The system performing the authentication can be configured to retrieve the values of the pNPR 915 and pDKI 920 of the contactless card at the time of authentication.

[0131] In some examples, to improve the security of the solution, a session key (e.g., a key unique to each session) can be derived, but not using the master key, but rather the key derived from the unique card and the counter can be used as diversification data, as described above. For example, each time the card is used in an operation, a different key can be used to create a message authentication code (MAC) and perform encryption. With respect to session key generation, the key used to generate the cryptogram and encrypt the data in one or more applets can include a session key based on the card unique key (Card-Key-Auth 925 and Card-Key-DEK 930). The session key (Aut-Session-Key 935 and DEK-Session-Key 940) can be generated by one or more applets and can be derived using the application transaction counter (pATC) 945 by one or more algorithms. To fit the data to one or more algorithms, only the 2 lower bytes of the 4 byte pATC 945 are used. In some examples, the four byte session key derivation method can include: Fl := PATC (lower 2 bytes) || 'F0' || 00' || PATC (four bytes) F2 := PATC (lower 2 bytes) || '0F' || 00' || PATC (four bytes) SK := {(ALG(MK)[Fl]) || ALG(MK)[F2]}, where ALG can include 3DES ECB and MK can include the card uniquely derived master key.

[0132] As described herein, the lower two bytes of the pATC 945 counter can be used to derive one or more MAC session keys. The pATC 945 is configured to be updated at each tap of the contactless card, and the card master keys Card-Key-Auth 925 and Card-Key-DEK 930 are further diversified into session keys Aut-Session-Key 935 and DEK-Session-Key 940. The pATC 945 can be initialized to zero at the time of personalization or applet initialization time. In some examples, the pATC counter 945 can be initialized at the time of personalization or before personalization, and can be configured to increase by 1 at each NDEF read.

[0133] Further, the update for each card can be unique and can be assigned through personalization, or can be assigned algorithmically through the pETID or other identifying information. For example, odd numbered cards can increase or decrease by 2, while even numbered cards can increase or decrease by 5. In some examples, the update can also vary in sequential reads, such that one card can increment by 1, 3, 5, 2, 2... in a repeating sequence. The particular sequence or algorithmic sequence can be defined at the time of personalization, or based on one or more processes derived from the unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

[0134] The authentication message can be delivered as the content of a text NDEF recorded in hexadecimal ASCII format. In some examples, only the authentication data and an 8 byte nonce following the MAC of the authentication data can be included. In some examples, the nonce can precede the cryptogram A and can be one block long. In other examples, there can be no limit to the length of the nonce. In further examples, the total data (i.e., the nonce plus the cryptogram) can be a multiple of the block size. In these examples, an additional 8 byte block can be added to match the block produced by the MAC algorithm. As another example, if the algorithm employed uses a 16 byte block, even multiples of that block size can be used, or the output can be automatically or manually padded to a multiple of that block size.

[0135] The MAC can be performed by the function key (AUT-Session-Key) 935. The data specified in the cryptogram can be processed with the javacard.signature method: ALG_DES_MAC8_IS09797_1_M2_ALG3, in relation to the EMV ARQC verification method. As described above, the key used for this calculation can include the session key AUT-Session-Key 935. As described above, the lower two bytes of the counter can be used to diversify the one or more MAC session keys. As described below, the AUT-Session-Key 935 can be used for the MAC data 950, and the resulting data or cryptogram A 955 and the nonce RND can be encrypted using the DEK-Session-Key 940 to create the cryptogram B or output of the message 960.

[0136] In some examples, one or more HSM commands can be processed for decryption, such that the last 16 (binary, 32 hexadecimal) bytes can include 3DES symmetric encryption using CBC mode with a zero IV, followed by MAC authentication data. The key used for this encryption can include a session key DEK-Session-Key 940 derived from Card-Key-DEK 930. In this case, the ATC value used for session key derivation is the least significant byte of the counter pATC 945.

[0137] The following format represents a binary version example embodiment. Further, in some examples, the first byte can be set to ASCII 'A'.

[0138]

[0139]

[0140] Another example format is shown below. In this example, the tag can be encoded in hexadecimal format.

[0141]

[0142]

[0143] The UID field of the received message can be extracted to derive card master keys (Card-Key-Auth 925 and Card-Key-DEK 930) from the master keys Iss-Key-AUTH 905 and Iss-Key-DEK 910 for this particular card. Using the card master keys (Card-Key-Auth 925 and Card-Key-DEK 930), the counter (pATC) field of the received message can be used to derive session keys (Aut-Session-Key 935 and DEK-Session-Key 940) for this particular card. DEK-Session-KEY can be used to decrypt Cipher B 960, which results in Cipher A 955 and RND, and RND can be discarded. The UID field can be used to look up the shared secret of the contactless card, which along with the Ver, LTD, and pATC fields of the message, can be processed using the recreated Aut-Session-Key through a cryptographic MAC to create a MAC output, such as MAC'. If MAC' is the same as Cipher A 955, then it indicates that both message decryption and MAC check have passed. The pATC can then be read to determine if it is valid.

[0144] During the authentication session, one or more applications can generate one or more cryptograms. For example, one or more cryptograms can be generated as 3DES MACs using ISO 9797-1 algorithm 3 with method 2 padding via one or more session keys (e.g., Aut-Session-Key 935). The input data 950 can take the form: version (2), pETID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses can include lengths in bytes. In some examples, the shared secret can be generated by one or more random number generators that can be configured to ensure that the random number is unpredictable through one or more secure processes. In some examples, the shared secret can include a random 4-byte binary number that is injected into the card at a personalized time that is known by the authentication service. During the authentication session, the shared secret can not be provided to the mobile application from the one or more applets. Method 2 padding can include adding a mandatory 0x'80' byte at the end of the input data, and a 0x'00' byte can be added to the end of the result data up to an 8-byte boundary. The resulting cryptogram can include a length of 8 bytes.

[0145] In some examples, one benefit of using the MAC cryptogram to encrypt the unshared random number as the first block is that it acts as an initialization vector when using the CBC (block chaining) mode of the symmetric encryption algorithm. This allows for "scrambling" between blocks without having to pre-establish a fixed or dynamic IV.

[0146] By including the application transaction counter (pATC) as part of the data included in the MAC cryptogram, the authentication service can be configured to determine whether the value conveyed in the plaintext data has been tampered with. Further, by including the version in the one or more cryptograms, it is difficult for an attacker to purposefully tamper with the application version in a way that attempts to reduce the strength of the cryptogram solution. In some examples, the pATC can start at zero and be updated by 1 each time the one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC that is equal to or less than a previous value received by the authentication service, this can be interpreted as an attempt to replay an old message, and the authenticated message can be rejected. In certain examples, if the pATC is greater than a previously received value, it can be evaluated to determine whether it is within an acceptable range or threshold, and if it is outside of or beyond that range or threshold, the verification can be considered to have failed or be unreliable. In the MAC operation 936, the data 950 is processed by the MAC using the Aut-Session-Key 935 to produce an encrypted MAC output (cryptogram A) 955.

[0147] To provide additional protection against brute force attacks that expose the key on the card, it is desirable to encrypt the MAC cryptogram 955. In some examples, the data or cryptogram A 955 to be included in the ciphertext can include: random number (8), cryptogram (8). In some examples, the numbers in parentheses can include the length in bytes. In some examples, the random number can be generated by one or more random number generators that can be configured to ensure that the random number is unpredictable by one or more secure processes. The key used to encrypt the data can include a session key. For example, the session key can include DEK-Session-Key 940. In the encryption operation 941, the data or cryptogram A 955 and RND are processed using the DEK-Session-Key 940 to generate the encrypted data, cryptogram B 960. The data 955 can be encrypted using 3DES in cipher block chaining mode to ensure that an attacker must attack all of the ciphertext for any attack to be successful. As a non-limiting example, other algorithms can be used, such as the Advanced Encryption Standard (AES). In some examples, an initialization vector of 0x’0000000000000000’ can be used. Any attacker attempting to brute force attack the key used to encrypt this data will not be able to determine when the correct key was used because correctly decrypted data will be indistinguishable from incorrectly decrypted data due to its random appearance.

[0148] To enable the authentication service to verify the one or more cryptograms provided by the one or more applets, the following data must be delivered from the one or more applets to the mobile device in the clear during the authentication session: a version number, which is used to determine the encryption method and message format used to verify the cryptogram, which enables the method to be changed in the future; a pUID, which is used to retrieve the cryptogram asset and to derive the card key; and a pATC, which is used to derive the session key for the cryptogram.

[0149] Figure 10 A method 1000 for generating a cryptogram is shown. For example, at block 1010, a network profile record ID (pNPR) and a derived key index (pDKI) can be used to identify which issuer master key to use in the encryption process for authentication. In some examples, the method can include performing authentication to retrieve the values of the pNPR and pDKI for the contactless card at the time of authentication.

[0150] At block 1020, the issuer master key can be diversified by combining the issuer master key with a PAN serial number (PSN) of the one or more applets (e.g., a payment applet) and a unique ID number (pUID) of the card.

[0151] At block 1030, Card-Key-Auth and Card-Key-DEK (unique card keys) can be created by diversifying the issuer master keys to generate session keys that can be used to generate MAC passwords.

[0152] At block 1040, the keys used to generate passwords and encrypt data in one or more applets can include session keys based on the card unique keys (Card-Key-Auth and Card-Key-DEK) of block 1030. In some examples, these session keys can be generated by the one or more applets and derived through the use of pATC, resulting in session keys Aut-Session-Key and DEK-Session-Key.

[0153] Figure 11 An example process 1100 showing key diversification is depicted in accordance with one example. Initially, two different master keys can be provided for a sender and a recipient. For example, a first master key can include a data encryption master key and a second master key can include a data integrity master key. The sender has a counter value that can be updated at block 1110, as well as other data, such as data to be protected, which can be shared with the recipient.

[0154] At block 1120, the counter value can be encrypted by the sender using the data encryption master key to produce a data encryption derived session key, and the counter value can also be encrypted by the sender using the data integrity master key to produce a data integrity derived session key. In some examples, the entire counter value or a portion of the counter value can be used during the two encryptions.

[0155] In certain examples, the counter value can not be encrypted. In these instances, the counter can be sent between the sender and the recipient in plain text, i.e., without encryption.

[0156] At block 1130, the sender processes the data to be protected with a cryptographic MAC operation using the data integrity session key and a cryptographic MAC algorithm. The protected data (including plaintext and shared secret) can be used to generate a MAC using one of the session keys (AUT-Session-Key).

[0157] At block 1140, the data to be protected can be encrypted by the sender using the data encryption derived session key in conjunction with a symmetric encryption algorithm. In certain examples, the MAC is combined with an equal amount of random data (e.g., 8 bytes long each) and then encrypted using the second session key (DEK-Session-Key).

[0158] At block 1150, the encrypted MAC is sent from the sender to the receiver with enough information to identify additional secret information (e.g., shared secrets, master keys, etc.) to verify the cryptogram.

[0159] At block 1160, the receiver uses the received counter value to independently derive two derived session keys from the two master keys, as described above.

[0160] At block 1170, the data encryption derived session key is used in conjunction with a symmetric decryption operation to decrypt the protected data. Additional processing of the exchanged data will then occur. In some examples, after the MAC is extracted, it is expected to be reproduced and matched. For example, when verifying a cryptogram, it can be decrypted using the appropriately generated session key. The protected data can be reconstructed for verification. The MAC operation can be performed using the appropriately generated session key to determine whether it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt to recreate it from the source data.

[0161] At block 1180, the data integrity derived session key is used in conjunction with a cryptographic MAC operation to verify that the protected data has not been modified.

[0162] Some examples of the methods described herein can advantageously confirm when a successful authentication is determined when the following conditions are met. First, the ability to verify the MAC indicates that the derived session keys are correct. The MAC is only correct if the decryption is successful and produces the correct MAC value. Successful decryption can indicate that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session keys are created using master keys known only to the sender (e.g., a sending device) and the receiver (e.g., a receiving device), it can be trusted that the contactless card that originally created the MAC and encrypted the MAC is indeed trustworthy. Also, the counter value used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operations.

[0163] Thereafter, the two derived session keys can be discarded and the next iteration of the data exchange will update the counter value (returning to block 1110) and a new set of session keys can be created (at block 1120). In some examples, the combined random data can be discarded.

[0164] Example embodiments of the systems and methods described herein can be configured to provide secure factor authentication. Secure factor authentication can include a plurality of processes. As part of the secure factor authentication, a first process can include logging in and authenticating a user via one or more applications executing on a device. As a second process, in response to a successful login and authentication of the first process via the one or more applications, the user can engage in one or more behaviors associated with one or more contactless cards. In effect, the secure factor authentication can include securely proving the identity of the user and engaging in one or more types of behaviors associated with a contactless card, including but not limited to one or more tap gestures. In some examples, the one or more tap gestures can include the user tapping a contactless card against the device. In some examples, the device can include a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process a received tap gesture.

[0165] In some examples, a contactless card can be tapped against a device, such as one or more kiosks or terminals, to authenticate an identity to receive a transaction item in response to a purchase, such as a coffee. By using a contactless card, a secure method of proving an identity in a loyalty program can be established. A secure proof of identity to receive, for example, a reward, a coupon, an offer, etc., or a benefit, can be established in a different way than just scanning a bar-coded card. For example, an encrypted transaction can occur between the contactless card and the device, which can be configured to process one or more tap gestures. As described above, one or more applications can be configured to authenticate the identity of the user and then act on or respond to the user via, for example, one or more tap gestures. In some examples, data such as consumer points, loyalty points, reward points, healthcare information, etc. can be written back to the contactless card.

[0166] In some examples, a contactless card can be tapped against a device, such as a mobile device. As described above, the identity of the user can be authenticated by one or more applications, which can then grant the user a desired benefit based on the authentication of the identity.

[0167] In some examples, a contactless card can be activated by tapping the card against a device, such as a mobile device. For example, a contactless card can communicate with an application of a device via a card reader of the device through NFC communication. The communication of tapping the card against the card reader of the device can allow the application of the device to read data associated with the contactless card and activate the card. In some examples, the activation can authorize the card for performing other functions, such as purchases, access to accounts or restricted information, or other functions. In some examples, the tap can activate or launch the application of the device, and then initiate one or more actions or communications with one or more servers to activate the contactless card. If the application is not installed on the device, the tap of the contactless card against the card reader can initiate a download of the application, such as navigating to a download page of the application. After installation, tapping the contactless card can activate or launch the application, and then initiate activation of the contactless card, such as via the application or other backend communication. After activation, the contactless card can be used for various activities, including but not limited to commercial transactions.

[0168] In some embodiments, a dedicated application can be configured to execute on a client device to perform activation of a contactless card. In other embodiments, a web portal, web-based application, applet, or the like can perform the activation. The activation can be performed on the client device, or the client device can merely act as a conduit between the contactless card and an external device (e.g., an account server). According to some embodiments, the application can indicate to the account server the type of device (e.g., personal computer, smart phone, tablet, or point-of-sale (POS) device) that performed the activation when providing the activation. Further, depending on the type of device involved, the application can output different and / or additional data to the account server for transmission. For example, such data can include information associated with a merchant, such as a merchant type, merchant ID, and information associated with the type of device itself, such as POS data and POS ID.

[0169] In some embodiments, the example authentication communication protocol may mimic the offline dynamic data authentication protocol of the EMV standard, which is typically executed between the transaction card and the point-of-sale device, with some modifications. For example, since the example authentication protocol itself is not used to complete a payment transaction with the card issuer / payment processor, certain data values ​​are not required, and authentication can be performed without involving a real-time online connection to the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system submits a transaction, including a transaction value, to the card issuer. Whether the issuer approves or rejects the transaction can be based on whether the card issuer recognizes the transaction value. Meanwhile, in some embodiments of this disclosure, transactions originating from mobile devices lack a transaction value associated with the POS system. Therefore, in some embodiments, a virtual transaction value (i.e., a value that the card issuer can recognize and is sufficient to allow activation) may be passed as part of the example authentication communication protocol. POS-based transactions may also reject transactions based on the number of transaction attempts (e.g., a transaction counter). An attempt count exceeding a buffer value may result in a soft rejection; this soft rejection requires further verification before accepting the transaction. In some implementations, the buffer value of the transaction counter may be modified to avoid rejecting legitimate transactions.

[0170] In some examples, contactless cards can selectively transmit information based on the recipient's device. Upon tapping, the contactless card can identify the device to which the tap is directed, and based on this identification, the card can provide the appropriate data to that device. Advantageously, this allows the contactless card to send only the information necessary to complete an immediate action or transaction, such as payment or card authentication. By limiting data transmission and avoiding unnecessary data transfers, efficiency and data security can be improved. Information identification and selective communication can be applied to a variety of situations, including card activation, balance transfers, account access attempts, commercial transactions, and gradual fraud reduction.

[0171] If tapping the contactless card guides you to run Apple... For devices with operating systems such as iPhone, iPod, or iPad, contactless cards can be recognized. The operating system then sends appropriate data to communicate with the device. For example, a contactless card can provide the encrypted identity information required for authentication via, for example, NFC using an NDEF tag. Similarly, if a tap of a contactless card guides the user to... Operating system devices (e.g.) If it's a smartphone or tablet, then a contactless card can be recognized. The operating system then sends appropriate data to communicate with the device (e.g., encrypted identity information required for authentication via the methods described herein).

[0172] As another example, a tap of a contactless card can be directed to a POS device, including but not limited to a kiosk, a checkout counter, a payment station, or other terminal. Upon performing the tap, the contactless card can identify the POS device and transmit only the information required for the action or transaction. For example, upon identifying a POS device for completing a commercial transaction, the contactless card can transmit payment information required to complete the transaction under the EMV standard.

[0173] In some examples, the POS device participating in the transaction can require or specify additional information to be provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, upon receiving a data communication from the contactless card, the POS device can identify the contactless card and request additional information required to complete the action or transaction.

[0174] In some examples, the POS device can be affiliated with an authorized merchant or other entity that is familiar with certain contactless cards or accustomed to performing certain contactless card transactions. However, it should be appreciated that the described methods need not require such an affiliation to be performed.

[0175] In some examples, such as a grocery store, a convenience store, a drug store, and the like, a contactless card can be tapped to a mobile device without having to open an application to indicate a desire or intent to utilize one or more of reward points, loyalty points, coupons, discounts, and the like to cover one or more purchases. Thus, the intent behind the purchase is provided.

[0176] In some examples, one or more applications can be configured to determine that it is initiated by one or more tap gestures of a contactless card, such that the initiation occurs at 3:51 PM, the transaction is processed or occurs at 3:56 PM, to verify the identity of the user.

[0177] In some examples, one or more applications can be configured to control one or more actions in response to one or more tap gestures. For example, the one or more actions can include collecting rewards, collecting points, determining most important purchases, determining lowest cost purchases, and / or reconfiguring to another action in real time.

[0178] In some examples, data about the tap behavior can be collected as biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and not easily intercepted can be transmitted to one or more backend services. The unique identifier can be configured to look up secondary information about the individual. The secondary information can include personally identifiable information about the user. In some examples, the secondary information can be stored within the contactless card.

[0179] In some examples, the device can include an application that splits a bill or a payment check among a plurality of individuals. For example, each individual can have a contactless card and can be a customer of the same issuing financial institution, but this is not required. Each of the individuals can receive a push notification on their device through the application to split a purchase. Rather than accepting a tap of only one card to indicate payment, other contactless cards can be used. In some examples, individuals with different financial institutions can have contactless cards to provide information to initiate one or more payment requests from the individual that taps the card.

[0180] The following example use case describes an example of a particular implementation of the present disclosure. These are for illustrative purposes only and are not meant to be limiting. In one case, a first friend (a payor) owes a second friend (a payee) a sum of money. The payor wishes to use a contactless card to make the payment through the payee's smartphone (or other device) rather than going to an ATM or requesting a transfer through a peer-to-peer application. The payee logs into the appropriate application on their smartphone and then selects a payment request option. In response, the application requests authentication via the payee's contactless card. For example, the application outputs a display to request that the payee tap their contactless card. Once the payee taps their contactless card on the screen of their smartphone with the application enabled, the contactless card is read and verified. Next, the application displays a prompt for the payor to tap their contactless card to make the payment. After the payor taps their contactless card, the application will read the card information and send a payment request to the payor's card issuer through an associated processor. The card issuer processes the transaction and sends a status indicator of the transaction to the smartphone. The application then outputs to display the status indicator of the transaction.

[0181] In another example case, a credit card customer can receive a new credit card (or debit card, other payment card, or any other card that needs to be activated) in the mail. Rather than activating the card by calling a provided phone number associated with the card issuer or visiting a website, the customer can decide to activate the card through an application on his or her device (e.g., a mobile device such as a smartphone). The customer can select a card activation function from an application menu displayed on the screen of the device. The application can prompt the customer to tap their credit card on the screen. After tapping the credit card on the screen of the device, the application can be configured to communicate with a server, such as a card issuer server that activates the customer's card. The application can then display a message indicating that the card was successfully activated. The activation of the card will then be complete.

[0182] Figure 12 A method 1200 for card activation according to example embodiments is shown. For example, card activation can be accomplished through a system including a card, a device, and one or more servers. The contactless card, the device, and the one or more servers can refer to those described above with respect to Figure 1A ,Figure 1B 、 Figure 5A and Figure 5B The same or similar components previously explained, such as the contactless card 105, the client device 110, and the server 120.

[0183] In block 1210, the card can be configured to dynamically generate data. In some examples, the data can include information such as an account number, a card identifier, a card verification value, or a phone number that can be transmitted from the card to the device. In some examples, one or more portions of the data can be encrypted via the systems and methods disclosed herein.

[0184] In block 1220, one or more portions of the dynamically generated data can be communicated to an application of the device via NFC or other wireless communication. For example, a tap of the card proximate to the device can allow the application of the device to read one or more portions of data associated with the contactless card. In some examples, if the device does not include an application to assist in activation of the card, the tap of the card can direct the device or prompt the user to a software application store to download an associated application to activate the card. In some examples, the user can be prompted to gesture, place, or orient the card sufficiently toward a surface of the device, for example to place at an angle or flat on a surface of the device, to place in proximity thereto, or to place proximate thereto. In response to the sufficient gesture, placement, and / or orientation of the card, the device can proceed to transmit one or more encrypted portions of data received from the card to one or more servers.

[0185] In block 1230, one or more portions of the data can be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data can be transmitted from the device to the card issuer server to activate the card.

[0186] In block 1240, the one or more servers can decrypt one or more encrypted portions of the data via the systems and methods disclosed herein. For example, the one or more servers can receive the encrypted data from the device and can decrypt it in order to compare the received data to the recorded data accessible to the one or more servers. If the result of the comparison by the one or more servers of the one or more decrypted portions of the data results in a successful match, the card can be activated. If the result of the comparison by the one or more servers of the one or more decrypted portions of the data results in an unsuccessful match, one or more processes can occur. For example, in response to a determination of an unsuccessful match, the user can be prompted to tap the card, swipe the card, or wave the card again. In this case, there can be a predetermined threshold that includes a number of attempts allowed for the user to activate the card. Alternatively, the user can receive one notification, such as a message on his or her device indicating an unsuccessful attempt to validate the card and calling, emailing, or texting a relevant service to assist in activating the card; or another notification, such as a phone call on his or her device indicating an unsuccessful attempt to validate the card and calling, emailing, or texting a relevant service to assist in activating the card; or another notification, such as an email indicating an unsuccessful attempt to validate the card and calling, emailing, or texting a relevant service to assist in activating the card.

[0187] In block 1250, the one or more servers can send a return message based on the successful activation of the card. For example, the device can be configured to receive an output from the one or more servers indicating that the one or more servers successfully activated the card. The device can be configured to display a message indicating that the card was successfully activated. Once the card is activated, the card can be configured to discontinue the dynamic generation of data, thereby avoiding fraudulent use. In this way, the card can not be activated thereafter and the one or more servers can be notified that the card has been activated.

[0188] In another example case, a customer wants to access his financial account on his mobile phone. The customer launches an application (e.g., a bank application) on the mobile device and enters a username and password. At this stage, the customer can see first level account information (e.g., recently purchased goods) and is able to perform first level account options (e.g., pay credit card). However, if the user attempts to access second level account information (e.g., spending limit) or perform second level account options (e.g., transfer to external system), he must have second level authentication. Accordingly, the application requests the user to provide a transaction card (e.g., credit card) for account validation. The user then taps his credit card to the mobile device and the application will validate that the credit card corresponds to the user's account. Thereafter, the user can view second level account data and / or perform second level account functions.

[0189] In some example embodiments, a user desires to purchase one or more items from a store using a contactless card or other transmitting device having the communication and encryption capabilities described herein and a receiving device in communication with the transmitting device.

[0190] In some example embodiments, a user can tap, swipe, wave, or perform any gesture or combination thereof with the transmitting device or contactless card near a receiving device to authenticate the identity of the user upon entering a store. Once inside the store, the user can tap, swipe, wave, or perform any gesture or combination thereof with the transmitting device or contactless card near a receiving device configured as an inventory management device. The inventory management device can be associated with a particular item. When the user removes the particular item from a shelf, the user brings the contactless card into the communication field of the inventory management device. The inventory management device detects the presence of the contactless card and sends a message to the card to indicate which item the user has removed. In some embodiments, when the user removes the item from the shelf and brings the contactless card into the communication field of the inventory management device, the inventory management device can display a visual signal, such as an indicator light. The visual signal can be used to confirm that the inventory management device has detected the contactless card and sent a message to the card indicating that the item has been removed. The contactless card can be configured to maintain a product list in the memory of the contactless card and can update the product list based on the message received from the inventory management device. As the user selects various items to purchase, the user can use the contactless card to develop the product list. If the user wishes to return an item, they can perform a gesture, such as a double tap, to indicate that the user has returned the item to the shelf. Upon sensing the gesture, the inventory management device sends a message to the card to indicate that the user has returned the item and the item can be removed from the product list. When the user returns the item and performs the gesture indicating that the item has been returned, the inventory management device can display a visual signal, such as an indicator light. The visual signal can be used to confirm that the inventory management device has detected the contactless card and sent a message to the card indicating that the item has been returned. In some embodiments, the visual signal indicating that the item has been removed from the shelf will be different from the visual signal indicating that the item has been returned. At the time of checkout, the user can tap, swipe, wave, or perform any gesture or combination thereof near a receiving device configured as a point of sale device. The contactless card can transmit the product list or information associated with the product list to the point of sale device. The point of sale device is then able to determine the total cost of the merchandise and charge the user account for the user’s purchase price.

[0191] Some example embodiments allow customers to select and purchase items without having to wait in line, thereby improving the efficiency of the shopping experience. In some embodiments, customer wait times can be reduced or eliminated, thereby allowing businesses to serve a greater number of customers in a given time period. The use of the disclosed systems and methods allows users to maintain control over their contactless cards, thereby reducing or eliminating the risk of fraudulent transactions and / or identity theft. Some embodiments utilize encryption algorithms to prevent fraudulent use of transmitted data. In some embodiments, store locations can be normal business hours, extended business hours, or even 24 hours with little to no staff each day, thereby improving the customer experience and saving business costs. This allows users greater flexibility in deciding when to shop and what items to purchase. In some embodiments, users can be able to pick up pre-arranged items by using the disclosed contactless card to authenticate their identity. In some embodiments, stores can be redesigned to distribute point-of-sale devices, eliminating the need for customers to go to a centralized checkout point. Thus, the disclosed systems and methods allow for a faster, safer, more efficient, and more convenient shopping experience.

[0192] Figure 13 A system 1300 using a contactless card is shown in accordance with example embodiments. The system 1300 can include a contactless card 1310, inventory management devices 1320, an authentication server 1330, and a point-of-sale device 1340.

[0193] Embodiments of the system 1300 include a contactless card 1310 that includes a processor 1312, a memory 1314 containing an applet 1315 and a product list 1316, and a contactless communication interface 1318. Embodiments of the system 1300 include one or more inventory management devices 1320 that include a processor 1322 and a contactless communication interface 1324 configured to generate a contactless communication field (e.g., an NFC field).

[0194] Embodiments of the system 1300 include an authentication server 1330 that can be in data communication with one or more inventory management devices 1320. Embodiments of the system 1300 include a contactless point-of-sale device 1340 that includes a processor 1342 and a contactless communication interface 1344 configured to generate a contactless communication field.

[0195] In operation, a user can tap, swipe, wave, or perform any gesture or combination thereof with the contactless card 1310 in proximity to the inventory management device 1320 associated with a product the user wants to purchase. When the contactless card 1310 enters the contactless communication field of the inventory management device 1320, the inventory management device 1320 is configured to request an identification token from the applet 1315 stored in the memory 1314 of the contactless card 1310. The applet 1315 of the contactless card 1310 transmits the identification token to the inventory management device 1320 using the contactless communication interface 1318.

[0196] In response to the request for the identification token from the inventory management device 1320, the applet 1315 can transmit an identification token contained in the memory 1314 of the contactless card 1310, can generate an identification token, and / or can encrypt an identification token using one or more cryptographic algorithms. In some embodiments, the contactless card 1310 can use the communication and encryption capabilities described herein to transmit an identification token. In such embodiments, the inventory management device 1320 can be configured to decrypt an encrypted identification token or can be configured to utilize and / or transmit the information that forms an encrypted identification token.

[0197] The inventory management device 1320 can authenticate the identification token by generating an identification message based on the identification token and transmitting the identification message to the authentication server 1330. In some embodiments, the identification message can include the identification token or a portion of the identification token. In some embodiments, the identification message can be derived from the identification token but does not contain any of the same information or data. In embodiments where the identification message is different from the identification token, the information contained within the identification token can be maintained locally rather than transmitted to a remote server.

[0198] The authentication server 1330 receives the identification message from the inventory management device 1320 and, after authenticating the identification token, transmits an authentication message to the inventory management device 1320. If the authentication server 1330 is unable to authenticate the identification token based on the identification message, the authentication server 1330 can transmit a message indicating that the identification token and / or the user identity cannot be authenticated. In some embodiments, the message can include a fraud alert. Upon receiving the authentication message, the inventory management device 1320 can transmit a product message to the contactless card 1310.

[0199] The product message contains information about a product associated with the inventory management device. The product message can contain information identifying the product, including the product name, product manufacturer, lot number, batch number, expiration date, manufacture date, ship date, and / or bottle date, among others. In some embodiments, the product message can also contain information associated with the inventory management device, including, for example, the model number, serial number, unique identifier, location identifier, store identifier, and / or the date or time that the inventory management device sent the product message to the contactless card identifying the product. In some embodiments, each product in the store is associated with a separate inventory management device. It will be understood that in some embodiments of the disclosed system, a user can tap, swipe, wave, or perform any gesture or combination thereof with the contactless card in the vicinity of a large number of inventory management devices.

[0200] Upon receiving the product message from the inventory management device 1320, the contactless card 1310 can update the product list 1316 contained in the memory 1314 of the contactless card 1310 based on the received product message.

[0201] In some embodiments, as described herein, a customer can select several items to purchase and update the product list of their contactless card for each item. When the customer is finished selecting items, the customer can tap, swipe, wave, or perform any gesture or combination thereof with the contactless card 1310 in the vicinity of the contactless point-of-sale device 1340.

[0202] In some embodiments, upon the contactless card 1310 entering the contactless communication field of the point-of-sale device 1340, the point-of-sale device 1340 is configured to request the product list 1316 from the contactless card 1310. The contactless card 1310 can send the product list to the point-of-sale device 1340 or can generate a product list message.

[0203] In some embodiments, the product list message can include the product list or a portion of the product list. In some embodiments, the product list message can be derived from the product list, but does not contain any of the same information or data. In embodiments where the product list message is different from the product list, the information contained in the product list can be maintained locally rather than being sent. The point-of-sale device 1340 can receive the product list message from the contactless card 1310 and perform operations based on the product list message.

[0204] In some embodiments, the product list and / or product list message contains a list of items that the customer has selected and / or includes pricing information associated with the selected items. In some embodiments, the product list and / or product list message only identifies the products to be acquired. The point of sale device 1340 can be configured to communicate this information in the product list message to the pricing server 1350. The pricing server 1350 can be in data communication with the product database 1360 and can be configured to request product information from the product database 1360 and send the product information to the point of sale device 1340. In some embodiments, the product list 1316 and / or product list message maintained in the memory 1314 of the contactless card 1310 can only contain product identifiers, such as stock keeping unit numbers (SKUs) or other unique identifiers.

[0205] In some embodiments, the point of sale device 1340 can include a mobile device, such as a user's mobile device, that can be in contactless communication with the card 1310. In some embodiments, the customer can not need to move to a particular location in the store to check out. The user can be able to use their mobile device to check out from anywhere within the store.

[0206] In some embodiments, upon receiving the authentication message from the authentication server 1330, the inventory management device 1320 sends an authorization token to the contactless card 1310. In some embodiments, the authorization token can be sent from the contactless card 1310 to the inventory management device 1320, the point of sale device 1340, or any other receiving device to establish and / or authorize the identity of the contactless card and / or user.

[0207] In some embodiments, the user can remove an item from a shelf and use the contactless card 1310 and the inventory management device 1320 to add the item to the product list, as described herein. The inventory management device 1320 can send an authorization token to the contactless card 1310 and the contactless card 1310 can save the authorization token in the memory 1314 of the contactless card 1310. In some embodiments, when the user selects another item from the shelf and uses the contactless card 1310 and the inventory management device 1320 to add the item to the product list, the contactless card 1310 can instead send the authorization token when the inventory management device 1320 requests an identification token from the contactless card 1310. In some embodiments, the inventory management device can accept the authorization token as authorization and / or to establish the identity of the user, rather than through the authentication server 1330 to authorize the identity of the user. This can reduce the amount of bandwidth required by a retail store to utilize the embodiments disclosed herein by reducing the total amount of communication associated with a user selecting and purchasing multiple items from a store.

[0208] In some embodiments, the contactless card 1310 can be configured to selectively send an authentication token in response to a request for an identification token from an inventory management device, a point-of-sale device 1340, or any other receiving device. In some embodiments, the inventory management device 1320 can be configured to send a product message to the contactless card 1310 after receiving an authorization token from the contactless card 1310. In some embodiments, the authorization token can be valid for a predetermined period of time, or can expire after a predetermined period of time or be deleted from the memory 1314 of the contactless card. This allows for reuse of the authorization token when a user selects multiple items during a shopping trip, while avoiding or limiting potential fraudulent use of the authorization token.

[0209] In some embodiments, the inventory management device 1320 can be configured to detect a gesture of the contactless card 1310 within the contactless communication field of the inventory management device 1320, and send a product removal message to the contactless card upon detecting the gesture. In some embodiments, upon receiving the product removal message, the contactless card 1310 updates the product list 1316 based on the received product removal message. This allows a user to back away from a product after selecting it and adding it to the product list. By performing a removal gesture (e.g., a double tap of the card), the user can remove a product from the product list before leaving the store.

[0210] In some embodiments, the contactless card can be in data communication with an auxiliary device. The auxiliary device can be configured to request and receive information associated with the product list, and display that information on a user interface. In some embodiments, a user can be able to remove an item from the product list using the user interface displayed on the auxiliary device, rather than performing a removal gesture using the contactless card. In some embodiments, a user can be able to view product information in real-time using the auxiliary device.

[0211] Figure 14 A system 1400 using a contactless card is shown in accordance with example embodiments. The system 1400 can include a contactless card 1410, an inventory management device 1420, an authentication server 1430, a point-of-sale device 1440, and an auxiliary device 1450 displaying a user interface 1460.

[0212] Embodiments of the system 1400 include a contactless card 1410 including a processor 1412, a memory 1414 containing applets 1415 and a product list 1416, and a contactless communication interface 1418.

[0213] In some embodiments, the auxiliary device 1450 can be in data communication with the contactless card 1410. The auxiliary device 1450 can include a processor 1452 and a contactless communication interface 1454. The auxiliary device 1450 can be configured to receive information associated with the product list from the contactless card 1410 and display product information 1462 on a user interface 1460. The product information can include at least a portion of the received information associated with the product list 1416.

[0214] In some embodiments, the auxiliary device 1450 is configured to send a product revision message to the contactless card 1410 based on user input received by the user interface 1460. The contactless card 1410 can be configured to modify the product list 1416 in response to the received product revision message.

[0215] In some embodiments, the user interface 1460 can be configured to display promotional material 1464 in response to the received information associated with the product list received from the contactless card 1410.

[0216] The auxiliary device 1450 can include, for example, a mobile device, a self-service kiosk, and / or an information display. In some embodiments, the auxiliary device 1460 can be in data communication with the contactless card 1410, the inventory management device 1420, the authentication server 1430, the point-of-sale device 1440, the pricing server 1470, and / or the product information database 1480.

[0217] In some embodiments, when a user is ready to purchase items and / or check out at a store, the user can bring their items to a point-of-sale device. In some embodiments, the point-of-sale is near a weight sensor. The weight sensor can be installed on the floor to weigh a shopping cart with items or can be installed at an appropriate height for a user to place a basket or bag with items. The weight sensor can be configured to subtract the weight of the basket or cart to determine the total weight of the items the customer has taken to checkout.

[0218] Figure 15 A system 1500 using a contactless card is shown in accordance with example embodiments. The system 1500 can include a contactless card 1510, an inventory management device 1520, an authentication server 1530, a point-of-sale device 1540, and a weight sensor 1550.

[0219] Embodiments of system 1500 include a non-contact card 1510 that includes a processor 1512, a memory 1514 that contains an applet 1515 and a product list 1516, and a non-contact communication interface 1518. Embodiments of system 1500 include one or more inventory management devices 1520 that include a processor 1522 and a non-contact communication interface 1524 configured to generate a non-contact communication field (e.g., an NFC field). Embodiments of system 1500 include a non-contact point of sale device 1540 that includes a processor 1542 and a non-contact communication interface 1544 configured to generate a non-contact communication field.

[0220] In some embodiments, the point of sale 1540 can be in data communication with a weight sensor 1550. The weight sensor 1550 can be configured to weigh one or more retail products and send a product weight message to the point of sale. The weight sensor 1550 can be installed within or on top of the floor of a store such that a customer can roll a cart directly onto the weight sensor 1550. In some embodiments, the weight sensor 1550 can be installed to a counter or other platform such that a customer can place a basket onto the weight sensor 1550. The weight sensor 1550 can be configured to subtract the weight of the cart or basket from the total weight to determine the weight of the products. The weight sensor 1550 can send a product weight message to the point of sale. The product weight message can include the measured weight of the products that the customer has placed on the weight sensor 1550.

[0221] In some embodiments, the point of sale device can receive information associated with the weight of each product from a database in communication with the point of sale 1540 or the non-contact card 1510. The point of sale 1540 can be configured to determine an expected product weight based on the product list message received from the non-contact card 1510. In some embodiments, the point of sale 1540 is configured to compare the expected product weight determined based on the information in the product list message to the measured product weight determined by the weight sensor 1550.

[0222] In some embodiments, the point of sale 1540 is configured to determine a difference between the expected product weight and the measured product weight. This difference can indicate that the products in the customer’s shopping basket or cart do not match the items in the customer’s product list.

[0223] The weight of some individual products can vary slightly. In some embodiments, the expected product weight can include a range of product weights indicating an expected variation in the product weight. In some embodiments, the point of sale can pause before performing an operation if the difference between the expected product weight and the measured product weight exceeds a predetermined amount. For example, if the measured product weight is outside of the expected product weight range, the point of sale can pause before charging the card for the products listed in the product list. This difference indicates that the customer does not actually possess the products listed in the product list.

[0224] In some embodiments, the point of sale is configured to display the product list to the user, so any difference between the product list and the physical products possessed by the user can be reconciled before charging the customer for the products.

[0225] In some embodiments, the point of sale 1540 can be configured to send a notification containing a password to the mobile device 1555 associated with the contactless card when the user checks out of the store to prevent fraudulent purchases. The point of sale device 1540, upon receiving the product list message from the contactless card 1510, can send the password to the mobile device 1555 associated with the contactless card and / or the user of the contactless card. The point of sale device 1540 can also be configured to request the password from the user before performing an operation. This second factor authentication can reduce or prevent fraudulent purchases.

[0226] In some embodiments, the system 1500 includes an inventory server 1560. The inventory server 1560 can be in data communication with the inventory management device 1520 and / or the point of sale 1540. The inventory server 1560 can be configured to monitor the inventory of a retail store. When a product is added to the product list, the inventory management device 1520 can send an inventory message to the inventory server to indicate that the product has been selected by the customer. In some embodiments, when a product is purchased, the point of sale device 1540 can send an inventory message to the inventory server to indicate that the product has been purchased by the customer.

[0227] In some embodiments, the inventory server 1560 can generate a report associated with the overall inventory of the store. This report can be used to inform future ordering decisions. In some embodiments, the inventory server 1560 can be configured to automatically order replacement inventory when the inventory of a product reaches a predetermined level.

[0228] In some embodiments, the inventory server 1560 can be associated with a single retail store location, or can be in communication with multiple retail store locations in an entire enterprise.

[0229] Figure 16A flowchart of a method 1600 for utilizing a contactless card in accordance with example embodiments is shown. The method 1600 begins at step 1605, which includes providing a transmitting device, such as a contactless card. The transmitting device includes a processor, a memory containing an applet and a product list, and a contactless communication interface. Step 1610 includes moving the transmitting device into a communication field of a receiving device. The receiving device is in data communication with an authorization server. In some embodiments, the receiving device in communication with the authorization server can be located at an entrance of a store, such that a customer can conveniently scan a way into the store. In step 1615, the receiving device requests an identification token from the applet of the transmitting device. The transmitting device transmits the identification token to the receiving device, and in step 1620, the receiving device authenticates the identification token by generating an identification message based on the identification token. In step 1625, the receiving device transmits the identification message to an authentication server. It should be understood that the communication and authorization steps can be essentially invisible to a customer who can experience the above steps as scanning the transmitting device (e.g., contactless card) in the vicinity of the receiving device after entering the store. Once the user enters the store, the user can use their contactless card to select and purchase items.

[0230] In step 1630, the user moves the transmitting device into a communication field of an inventory management device. The inventory management device can be associated with a particular retail product. In step 1635, the inventory management device transmits a product message to the transmitting device. Upon receiving the product message, in step 1640, the transmitting device modifies the product list based on the received product message. The user can repeat these steps using other inventory management devices associated with other products the user wants to purchase. As the user moves throughout the store, the user can modify the product list contained in the memory of the transmitting device to reflect the various products the user wants to purchase.

[0231] In step 1645, the user moves the transmitting device into a communication field of a point of sale. The point of sale includes a processor and a contactless communication interface. The point of sale requests a product list message from the transmitting device in step 1650, and receives the product list message from the transmitting device in step 1655. Once the point of sale device receives the product list from the transmitting device, in step 1660, the point of sale device performs a financial transaction.

[0232] In some embodiments, the method 1600 includes the optional step of: step 1665, the receiving device receives an authentication message from the authentication server. Upon receiving the authentication message from the authentication server, the receiving device can generate an authorization token based on the information contained in the authorization message. At step 1670, the receiving device sends the authorization token to the transmitting device. In some embodiments, at step 1675, the inventory management device requests the authorization token prior to sending the product message to the transmitting device. The user of the authorization token can allow the user to use the transmitting device described herein to select products without requiring the user to authenticate their identity each time a product is selected.

[0233] In some embodiments, the method 1600 can include the following optional steps: at step 1680, the transmitting device encrypts the identification token, and at step 1685, the encrypted identification token is sent to the receiving device. By sending the encrypted identification token, the data comprising the identification token can be securely saved in the memory of the transmitting device. This can reduce or avoid the data of the identification token from being intercepted or otherwise fraudulently obtained during transmission, thereby increasing the security of the system.

[0234] In some embodiments, the method 1600 can further include the following optional steps: at step 1690, the point of sale device sends a password to a mobile device associated with the transmitting device. The point of sale device can send the password upon receiving the product list message from the transmitting device. Then, at step 1695, the point of sale device can request the password from the user prior to performing the financial transaction. This feature can serve as an additional security measure to ensure that the person using the transmitting device is the authorized user. By sending the password to a mobile device associated with the transmitting device and / or user, and requiring the user to input the password prior to completing the financial transaction, fraudulent transactions can be reduced.

[0235] Figure 17 A flowchart of a method 1700 for utilizing a contactless card is shown, in accordance with example embodiments. It will be understood that the method 1700 extends the method 1600, and in some embodiments can incorporate steps (not shown) of the method 1600.

[0236] The method 1700 begins after the receiving device sends the identification message to the authentication server. At step 1710, the authentication server sends an authentication message to a retail server in data communication with the receiving device. At step 1720, the retail server sends an approval message to the receiving device, either directly or through a relay of an authorization server. At step 1730, the receiving device, upon receiving the approval message, sends an authorization token to the transmitting device. In some embodiments, at step 1740, the receiving device, inventory management device, and / or point of sale device requests the authorization token from the transmitting device.

[0237] In some embodiments, the sending device can send the authorization token in response to a request to identify a token or certificate. In some embodiments, the requesting device can accept the authorization token as authorization for an operation or transaction without communicating with any other server or device. The system can be used to allow a customer to select and purchase goods without requiring extensive backend communication for each product selected by the user. In some embodiments, upon receiving the authorization token, the receiving device can send a product message, and / or perform a transaction.

[0238] Throughout the specification, reference is made to various accounts, such as bank accounts and credit card accounts and debit accounts. However, it should be understood that the present disclosure is not limited to particular bank accounts, and can include any financial account, as well as accounts related to entertainment, loyalty programs, utilities, and other services.

[0239] In some examples, the present disclosure relates to a tap of a contactless card. However, it should be understood that the present disclosure is not limited to a tap, and the present disclosure includes other gestures (e.g., a wave or other movement of the card).

[0240] Throughout the specification and claims, unless the context clearly indicates otherwise, the following terms have at least the meanings explicitly associated herein. The term “or” is intended to mean an inclusive “or”. Further, the terms “a”, “an”, and “the” are intended to mean one or more unless otherwise indicated or clearly contradicted by context.

[0241] In this description, numerous specific details have been set forth. It is to be understood, however, that implementations of the disclosed technology can be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. References to “some examples,” “other examples,” “one example,” “an example,” “exemplary,” “various examples,” “one embodiment,” “the embodiment,” “some embodiments,” “exemplary embodiment,” “various embodiments,” “one implementation,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” etc., mean that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the disclosure, but not necessarily in all implementations of the disclosure. Further, the phrases “in one example” or “in one embodiment” do not necessarily refer to the same example or embodiment, although they can.

[0242] As used herein, unless otherwise indicated, the use of the ordinal adjectives "first", "second", "third", etc., are used merely to distinguish different objects that have a common attribute, and do not imply a time, spatial, hierarchical, or other relationship of those objects.

[0243] While certain implementations of the disclosed technology have been described in connection with what is presently considered to be the most practical and various implementations, it is to be understood that the disclosed technology is not to be limited to the disclosed implementations, but on the contrary, is intended to cover various modifications and equivalent arrangements. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

[0244] This written description uses examples to disclose certain implementations of the disclosed technology, including the best mode, and also to enable any person skilled in the art to practice certain implementations of the disclosed technology, including making and using any devices or systems and performing any incorporated methods. The patentable scope of certain implementations of the disclosed technology is defined by the claims, and can include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.

Claims

1. A contactless card, comprising: a processor; and a memory, the memory containing an applet and a list, wherein the list comprises a plurality of product identifiers, wherein the applet is configured to: generate an identification token in response to a request for an identification token by an inventory management device, encrypt the identification token, transmit the identification token to the inventory management device via a communication field generated by the inventory management device after the first time the contactless card enters the communication field, receive a first message in response to the transmission of the identification token, the first message comprising at least one product identifier, and update the list based on the first message, wherein the applet is further configured to transmit a second message based on a request by a point of sale device, the second message comprising the at least one product identifier, to cause the point of sale device to perform an operation based on the second message. the first message further comprises information associated with the inventory management device.

2. The contactless card of claim 1, wherein, the information associated with the inventory management device comprises at least one selected from the group of: a model number, a serial number, a unique identifier, a location identifier, a store identifier, a date on which the inventory management device transmitted the first message, and a time at which the inventory management device transmitted a product message to the contactless card identifying a product.

3. The contactless card of claim 2, wherein, the applet is configured to transmit the second message after the contactless card enters a communication field generated by the point of sale device.

4. The contactless card of claim 1, wherein, 5. The contactless card of claim 4, wherein: the contactless card is associated with a user, and the point of sale device comprises a mobile device associated with the user.

6. The contactless card of claim 1, wherein the memory further contains a card key; the processor is further configured to generate a session key using the card key, and the applet is further configured to encrypt the identification token using the session key.

7. The contactless card of claim 6, wherein the memory further contains a counter, and the processor is further configured to generate the session key using the card key and the counter.

8. The contactless card of claim 1, wherein the plurality of product identifiers comprises a plurality of stock keeping unit numbers (SKUs). the contactless card comprises a processor and a memory, the memory containing an applet and a list of at least one product identifier, the method comprising:

9. A method performed by a contactless card, wherein, receiving, by the applet, a request for an identification token from an inventory management device; generating, by the applet, an identification token in response to the request; encrypting, by the applet, the identification token; transmitting the identification token after the contactless card enters a communication field generated by the inventory management device; receiving a first message in response to the transmission of the identification token, the first message comprising at least one product identifier; and updating, by the applet, the list based on the first message, transmitting, by the applet, a second message to a point of sale device based on a request by the point of sale device via a communication field generated by the point of sale device, the second message comprising at least one of the plurality of product identifiers. ​ 10. The method of claim 9, wherein, The second message is configured to initiate a determination of a price of a product identified by at least one of the plurality of product identifiers.

11. The method of claim 9, wherein, Updating the list based on the first message includes removing, by the applet, at least one product identified by the at least one product identifier from the list.

12. A system comprising: a contactless card including a processor and a memory, the memory including an applet and a list, the list including at least one product identifier, wherein the applet is configured to: generate an identification token in response to a request for the identification token by an inventory management device, encrypt the identification token, transmit the identification token to the inventory management device via a communication field generated by the inventory management device after a first entry of the contactless card into the communication field, receive a first message in response to the transmission of the identification token, the first message including at least one product identifier, and update the list based on the first message; and an inventory management device, wherein the inventory management device is configured to: generate the communication field, request the identification token from the contactless card and receive the identification token from the contactless card, generate an identification message based on the identification token, and transmit the identification message to an authentication server, wherein the applet is further configured to transmit a second message to a point of sale device after entry of the contactless card into a communication field generated by the point of sale device, the second message including the at least one product identifier.

13. The system of claim 12, wherein, the inventory management device is further configured to: receive an authentication message from the authentication server upon successful authentication of the identification message by the authentication server, and transmit a product message including a first product identifier to the applet.

14. The system of claim 13, wherein, the applet is further configured to: receive the product message, and update the list based on the first product identifier.

15. The system of claim 13, wherein, a frequency of a posture of the contactless card in the communication field indicates removal of a product identifier from the list.

16. The system of claim 13, wherein, the inventory management device is further configured to display a signal after entry of the contactless card into the communication field.

17. The system of claim 16, wherein, the signal includes at least one selected from the group of a visual signal associated with removal of an item and a visual signal associated with return of an item.

18. The system of claim 15, wherein the frequency of the posture includes a plurality of entries of the contactless card into the communication field.

19. The system of claim 15, wherein the product message further includes at least one selected from the group of a product name, a product manufacturer, a batch number, a lot number, an expiration date, a manufacture date, a ship date, and a bottle date.

20. The system of claim 15, wherein the product message further includes information associated with the inventory management device, the information including at least one selected from the group of a model number, a serial number, a unique identifier, a location identifier, a store identifier, a date the inventory management device transmitted the first message, and a time the inventory management device transmitted a product message identifying a product to the contactless card.

Images