System and method for encrypted authentication of contactless cards

Abstract

Exemplary embodiments of a system and method for transmitting data between a contactless card, a client device, and one or more servers are provided. The contactless card may include one or more processors and memory. The memory may include one or more applets. The client device may include one or more processors and memory. The client device may be in data communication with the contactless card. One or more servers may be in data communication with the client device. A first set of information may be sent from the contactless card to the client device. The first set of information may include one or more links for activating the contactless card. The client device may be configured to receive the first set of information from the contactless card. Upon verifying the first set of information, the contactless card may be activated.

Description

Technical Field

[0001] Cross - References to Related Applications This application claims priority to U.S. Patent Application No. 16 / 546,657, filed on August 21, 2019. This is a continuation - in - part of U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, which claims priority and claims priority from U.S. Provisional Patent Application No. 62 / 740,352, filed on October 2, 2018, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates to encryption, and more specifically, to systems and methods for encrypting authentication of contactless cards.

Background Art

[0003] The security of data and the integrity of transactions are of great importance to businesses and consumers. As electronic transactions constitute an increasingly large share of commercial activities, this need continues to grow.

[0004] Email can be used as a tool to verify transactions, but email is vulnerable to attacks and is susceptible to hacking and other unauthorized access. Short Message Service (SMS) messages can also be used, but they can also be compromised. Furthermore, data encryption algorithms such as the Triple DES algorithm also have similar vulnerabilities.

[0005] To activate many cards, including financial cards (e.g., credit cards and other payment cards), a time-consuming process is required where the card owner calls a phone number, accesses a website, or enters or provides card information. Further, as the use of chip-based financial cards increases, while they provide a more secure function than previous technologies (e.g., magnetic stripe cards) for in-person purchases, access to the account can depend on login credentials (e.g., username and password) to verify the card owner's identity. However, if the login credentials are compromised, another person can access the user's account.

[0006] These and other deficiencies exist. Therefore, it is necessary to provide users with an appropriate solution to overcome these deficiencies in order to provide data security, authentication, and verification for contactless cards. Further, both an improved method for activating the card and an improved authentication for account access are needed. SUMMARY OF THE INVENTION

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

[0008] Embodiments of the present disclosure are card activation systems, including a contactless card including one or more processors and a memory, the memory including one or more applets, the contactless card, a client application comprising instructions for execution on a client device including one or more processors and a memory, and one or more servers. The contactless card is configured such that when the contactless card enters the communication range, a first set of information is transmitted to the client application. The first set of information includes one or more links configured to activate the contactless card. The client application is configured to receive the first set of information from the contactless card and transmit it to one or more servers for verification. When the first set of information is verified, the contactless card is activated, providing a card activation system.

[0009] Embodiments of the present disclosure are methods for activating a contactless card. The method includes the steps of the contactless card entering the communication range, one or more applets included in the memory of the contactless card transmitting a first set of information to a client application comprising instructions for execution on a client device via the communication range, the first set of information including one or more links configured to activate the contactless card, the client application transmitting the first set of information to one or more servers, one or more servers performing one or more encryption operations to verify the first set of information, and activating the contactless card when the first set of information is verified, providing a method.

[0010] Embodiments of the present disclosure provide a contactless card comprising a processor and a memory, the memory including one or more applets and a first set of information, wherein when the contactless card enters a communication range, the one or more applets are configured to transmit the first set of information, the first set of information comprising one or more links configured to activate the contactless card, the one or more links including a first information element and a second information element, the first information element comprising a telephone number, and the second information element comprising an encrypted payload.

[0011] Further features of the disclosed design, and the advantages thereby provided, are explained in more detail below with reference to specific exemplary embodiments shown in the accompanying drawings.

Brief Description of the Drawings

[0012]

Figure 1A

Figure 1B

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Best Mode for Carrying Out the Invention

[0013] The following description of the embodiments provides non-limiting representative examples that refer to numbers to specifically illustrate the features and teachings of different aspects of the present invention. It should be recognized that the described embodiments can be implemented separately from or in combination with other embodiments from the description of the embodiments. Those skilled in the art considering the description of the embodiments should learn and understand the different described aspects of the present invention. The description of the embodiments should facilitate the understanding of the present invention to the extent that other embodiments, although not specifically covered, that are within the knowledge of those skilled in the art after reading the description of the embodiments are understood to be consistent with the application of the present invention.

[0014] An object of some embodiments of the present disclosure is to incorporate one or more keys into one or more contactless cards. In these embodiments, the contactless card can perform many other functions that may require the user to carry a separate physical token in addition to the contactless card for authentication and other methods. By adopting a contactless interface, the contactless card can be provided with a method for interacting and communicating between the user's device (such as a mobile phone) and the card itself. For example, the EMV protocol underlying many credit card transactions includes a sufficient authentication process for the Android (registered trademark) operating system, but there are issues with iOS (registered trademark), which is more restricted regarding the use of Near Field Communication (NFC) because it can only be used in a read-only manner. Exemplary embodiments of the contactless card described herein utilize NFC technology.

[0015] Figure 1A shows a data transmission system according to an exemplary embodiment. As will be further described below, system 100 may include a contactless card 105, a client device 110, a network 115, and a server 120. Although Figure 1A shows a single instance of the components, system 100 may include any number of components.

[0016] System 100 may include one or more contactless cards 105, which will be further described below with reference to Figures 5A through 5B. In some embodiments, the contactless card 105 can wirelessly communicate with the client device 110, for example, by utilizing NFC.

[0017] System 100 may include a client device 110 that 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 such as, for example, a server, a network appliance, a personal computer, a workstation, a telephone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other devices. The client device 110 can also be a mobile device. For example, mobile devices can include Apple's iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark), or other mobile devices running Apple's iOS (registered trademark) operating system, devices running Microsoft's Windows (registered trademark) Mobile operating system, devices running Google's Android (registered trademark) operating system, and / or other smartphones, tablets, or similar wearable mobile devices.

[0018] The client device 110 can include a processor and memory. The processing circuitry can include additional components such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and anti-tampering hardware, as necessary to perform the functions described herein. The client device 110 can further include a display and an input device. The display can 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. The input device can include any device for inputting information available and supported by the user's device into the user's device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, 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.

[0019] In some examples, the client device 110 of the system 100 can execute one or more applications, such as software applications, that enable network communication with one or more components of the system 100 and transmit and / or receive data.

[0020] The client device 110 can communicate with one or more servers 120 via one or more networks 115 and can operate as a pair from the front end to the back end with each of the servers 120. The client device 110 can send one or more requests to the server 120, for example, from a mobile device application executed on the client device 110. The one or more requests can be associated with the retrieval of data from the server 120. The server 120 can receive one or more requests from the client device 110. Based on the one or more requests from the client device 110, the server 120 can be configured to retrieve the requested data from one or more databases (not shown). Based on the receipt of the requested data from the one or more databases, the server 120 can be configured to send the received data to the client device 110, and the received data responds to the one or more requests.

[0021] System 100 may include one or more networks 115. In some examples, network 115 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect client device 110 to server 120. For example, network 115 may be an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing 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 (registered trademark), NFC, radio frequency identification (RFID), Wi-Fi, etc., and may include one or more of them.

[0022] Furthermore, network 115 includes, but is not limited to, a telephone line, fiber optic, IEEE Ethernet 902.3, wide area network, wireless personal area network, LAN, or a global network such as the Internet. Additionally, network 115 can support an Internet network, wireless communication network, cellular network, etc., or any combination thereof. Network 115 can further include one network, or any number of the exemplary types of networks described above, operating as a stand-alone network or cooperating with each other. Network 115 can utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 can convert one or more protocols of network devices to other protocols. Although network 115 is shown as a single network, according to one or more examples, network 115 can include, for example, multiple interconnected networks such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

[0023] System 100 can include one or more servers 120. In some examples, server 120 can include one or more processors coupled to a memory. Server 120 can be configured as a central system, server, or platform for controlling and invoking various data at different times to execute multiple workflow actions. Server 120 can be configured to connect to one or more databases. Server 120 can be connected to at least one client device 110.

[0024] Figure 1B is a timing diagram showing an exemplary sequence for providing authenticated access according to one or more embodiments of the present disclosure. System 100 may include a contactless card 105 and a client device 110, which may include an application 122 and a processor 124. Figure 1B may refer to components similar to those shown in Figure 1A.

[0025] In step 102, application 122 communicates with contactless card 105 (e.g., after being brought close to contactless card 105). The communication between application 122 and contactless card 105 may include a contactless card 105 that is close enough to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

[0026] In 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) ciphertext. In some examples, this can occur when the contactless card 105 is read by the application 122. In particular, this can occur upon reading, such as NFC reading of a Near Field Data Exchange (NDEF) tag that 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 selection message using the applet ID of the NDEF generation applet. When the selection is confirmed, a series of selection file messages followed by read file messages can be sent. For example, the sequence can include "selection of function file", "reading of function file", and "selection of NDEF file". At this point, the counter value maintained by the contactless card 105 can be updated or incremented, and then "reading of NDEF file" can follow. At this point, a message including a header and a shared secret can be generated. Next, a session key can be generated. The MAC ciphertext can be created from the message. The message can include a header and a shared secret. Next, the MAC ciphertext can be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) can be encrypted with the session key. Thereafter, the ciphertext and the header can be concatenated and encoded as ASCII hexadecimal and returned in the NDEF message format (in response to the "reading of NDEF file" message).

[0027] In some examples, the MAC ciphertext can be sent as an NDEF tag, and in other examples, the MAC ciphertext can be included with a Uniform Resource Indicator (e.g., as a formatted string).

[0028] In some examples, the application 122 can be configured to send a request to the contactless card 105, and the request comprises an instruction for generating the MAC ciphertext.

[0029] In step 106, the contactless card 105 transmits the MAC ciphertext to the application 122. In some examples, the transmission of the MAC ciphertext is performed via NFC, but the present disclosure is not limited thereto. In other examples, this communication can be performed via Bluetooth®, Wi-Fi, or other wireless data communication means.

[0030] In step 108, the application 122 communicates the MAC ciphertext to the processor 124.

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

[0032] In some examples, the verification of the MAC ciphertext can be performed by a device other than the client device 110, such as the server 120 that is in data communication with the client device 110 (as shown in FIG. 1A). For example, the processor 124 can output the MAC ciphertext to send it to the server 120 that can verify the MAC ciphertext.

[0033] In some examples, the MAC ciphertext can function as a digital signature for verification purposes. To perform this verification, a public key asymmetric algorithm, such as the digital signature algorithm and the RSA algorithm, or other digital signature algorithms such as the zero-knowledge protocol can be used.

[0034] FIG. 2 shows a data transmission system according to an exemplary embodiment. System 200 may include one or more servers 220 and a transmitting or transmitting device 205 and a receiving or receiving device 210 communicating, for example, via a network 215. The transmitting or transmitting device 205 may be the same as or similar to the client device 110 discussed above with reference to FIG. 1A. The receiving or receiving device 210 may be the same as or similar to the client device 110 discussed above with reference to FIG. 1A. The network 215 may be similar to the network 115 discussed above with reference to FIG. 1A. The server 220 may be similar to the server 120 discussed above with reference to FIG. 1A. FIG. 2 shows a single instance of the components of system 200, but system 200 may include any number of the illustrated components.

[0035] When using symmetric encryption algorithms such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cipher-based message authentication code (CMAC) algorithms, it is important to keep the key secret between the party that first processes the data protected using the symmetric algorithm and key and the party that receives and processes the data using the same encryption algorithm and the same key.

[0036] It is also important not to use the same key multiple times. If a key is used or reused frequently, the key can be jeopardized. Each time a key is used, additional samples of data processed by the encryption algorithm using the same key are provided to an attacker. The more data processed with the same key the attacker has, the higher the likelihood that the attacker will discover the key value. Frequently used keys can be involved in various attacks.

[0037] Furthermore, each time a symmetric encryption algorithm is executed, information such as side-channel data regarding the key used during the symmetric encryption operation may be revealed. Side-channel data may include slight power fluctuations that occur when the encryption algorithm is executed during key use. By sufficiently measuring the side-channel data, sufficient information regarding the key can be revealed to enable an attacker to recover the key. When data is exchanged using the same key, the data processed with the same key is repeatedly revealed.

[0038] However, by limiting the number of times a particular key is used, the amount of side-channel data that an attacker can collect is limited, thereby reducing exposure to this and other types of attacks. As further described herein, parties involved in the exchange of cryptographic information (e.g., senders and receivers) generate keys independently from an initial shared master symmetric key in combination with a counter value, thereby periodically replacing the shared symmetric key in use and relying on any form of key exchange to maintain synchronization between the parties. By periodically changing the shared secret symmetric key used by the sender and receiver, the above attack is made impossible.

[0039] Returning to FIG. 2, system 200 may be configured to perform key diversification. For example, a sender and a receiver may desire to exchange data (e.g., original confidential data) via their respective devices 205 and 210. As described above, a single instance of the sending device 205 and the receiving device 210 may be included, but it is understood that one or more sending devices 205 and one or more receiving devices 210 may be involved as long as each party shares the same shared secret symmetric key. In some examples, the sending device 205 and the receiving device 210 may be provisioned with the same master symmetric key. Further, it is understood that any party or device holding the same secret symmetric key can perform the function of the sending device 205, and similarly, any party holding the same secret symmetric key can perform the function of the receiving device 210. In some examples, the symmetric key may comprise a shared secret symmetric key that is kept secret from all parties other than the sending device 205 and the receiving device 210 involved in the secure data exchange. Further, the same master symmetric key can be provided to both the sending device 205 and the receiving device 210, and further, a portion of the data exchanged between the sending device 205 and the receiving device 210 may comprise at least a portion of data that may be referred to as a counter value. The counter value may comprise a number that changes each time data is exchanged between the sending device 205 and the receiving device 210.

[0040] System 200 may include one or more networks 215. In some examples, network 215 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect one or more transmission devices 205 and one or more reception devices 210 to server 220. For example, network 215 may include one or more of an optical fiber 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 communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing 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, etc.

[0041] Furthermore, network 215 can include, but is not limited to, global networks such as telephone lines, optical fibers, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or the Internet. Additionally, network 215 can support the Internet network, wireless communication networks, cellular networks, etc., or any combination thereof. Network 215 can further include one network, or any number of the exemplary types of networks described above, operating as a stand-alone network or cooperating 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 convert to one or more protocols of network devices between other protocols. Although network 215 is shown as a single network, according to one or more examples, network 215 can comprise, for example, multiple interconnected networks such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

[0042] In some examples, one or more transmitting devices 205 and one or more receiving devices 210 can be configured to communicate with each other and transmit and receive data without passing 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, etc.

[0043] In block 225, when the sending device 205 is preparing to process the confidential data in a symmetric encryption operation, the sender can update the counter. Further, the sending device 205 can select an appropriate symmetric encryption algorithm, which may 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 may comprise any symmetric encryption algorithm used as needed to generate a diversified symmetric key of a desired length. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. 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 generate multiple outputs that can be combined as needed to generate a key of sufficient length.

[0044] In block 230, the sending device 205 can adopt the selected encryption algorithm and use the master symmetric key to process the counter value. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated in all conversations between the sending device 205 and the receiving device 210. Next, the sending device 205 can use the master symmetric key to encrypt the counter value with the selected symmetric encryption algorithm to create a diversified symmetric key.

[0045] In some examples, the counter value may not be encrypted. In these examples, the counter value can be sent between the sending device 205 and the receiving device 210 in block 230 without encryption.

[0046] In block 235, diverse symmetric keys can be used to process confidential data before transmitting the results to the receiving device 210. For example, the transmitting device 205 can encrypt the confidential data using a symmetric encryption algorithm that uses diverse symmetric keys, and the output comprises protected encrypted data. Next, the transmitting device 205 can transmit the protected encrypted data, along with a counter value, to the receiving device 210 for processing.

[0047] In block 240, the receiving device 210 can first obtain the counter value, and then use the counter value as input to the encryption and execute the same symmetric encryption using the master symmetric key as the key for encryption. The output of the encryption can be the same diverse symmetric key value created by the sender.

[0048] Next, in block 245, the receiving device 210 can obtain the protected encrypted data and decrypt the protected encrypted data using a symmetric decryption algorithm along with the diverse symmetric key.

[0049] In block 250, the original confidential data can be revealed as a result of decrypting the protected encrypted data.

[0050] Next, when it is necessary to transmit the confidential data from the sender to the receiver via their respective transmitting device 205 and receiving device 210, different counter values can be selected to generate different diverse symmetric keys. By processing the counter values using the same symmetric cryptographic algorithm as the master symmetric key, both the transmitting device 205 and the receiving device 210 can independently generate the same diverse symmetric key. This diverse symmetric key, rather than the master symmetric key, is used to protect the confidential data.

[0051] As described above, both the transmitting device 205 and the receiving device 210 initially each own a shared master symmetric key. The shared master symmetric key is not used for encrypting the original confidential data. Since the diversified symmetric keys are independently created by both the transmitting device 205 and the receiving device 210, they are never transmitted between the two. Therefore, an attacker cannot intercept the diversified symmetric keys, and the attacker never sees the data processed with the master symmetric key. Only the counter value, rather than the confidential data, is processed with the master symmetric key. As a result, a reduction in side-channel data regarding the master symmetric key becomes apparent. Further, the operations of the transmitting device 205 and the receiving device 210 can be governed by symmetric requirements regarding the frequency of creating new diversification values, and thus new diversified symmetric keys. In one embodiment, new diversification values, and thus new diversified symmetric keys, can be created for all exchanges between the transmitting device 205 and the receiving device 210.

[0052] In some examples, the key diversification value can constitute a counter value. Other non-limiting examples of key diversification values include a random number generated each time a new diversified key is needed, a random number transmitted from the transmitting device 205 to the receiving device 210, the complete value of the counter values transmitted from the transmitting device 205 and the receiving device 210, a portion of the counter values transmitted from the transmitting device 205 and the receiving device 210, a counter maintained independently by the transmitting device 205 and the receiving device 210 but not transmitted between the two devices, a one-time passcode exchanged between the transmitting device 205 and the receiving device 210, and an encryption hash of the confidential 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. Further, one or more combinations of the above-exemplified key diversification values can be used.

[0053] In other examples, a portion of the counter can be used as the key diversification value. When multiple master key values are shared among parties, multiple diversified key values can be obtained by the systems and processes described herein. New diversification values, and thus new diversified symmetric keys, can be created as many times as needed. In the most secure case, a new diversification value can be created for each exchange of confidential data between the sending device 205 and the receiving device 210. In effect, this can create a one-time use key, such as a single use session key.

[0054] Figure 3 shows a system 300 that uses a contactless card. 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 3 shows a single instance of the components, the system 300 can include any number of components.

[0055] System 300 may include one or more contactless cards 305, which will be further described below with respect to FIGS. 5A-5B. In some examples, the contactless card 305 may be wireless communication with the client device 310, such as NFC communication. For example, the contactless card 305 may 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 via 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 may be configured to communicate with the card reader 313 of the client device 310 via NFC when the contactless card 305 is within the range of the card reader 313. In other examples, communication with the contactless card 305 may be achieved via a physical interface, such as a universal serial bus interface or a card swipe interface.

[0056] System 300 may include a client device 310, which can be a network-enabled computer. As referred to herein, a network-enabled computer can include, for example, a computer device, or, for example, a server, a network appliance, a personal computer, a workstation, a mobile device, a telephone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other communication devices including, but not limited to, these. One or more client devices 310 can also be mobile devices. For example, mobile devices can include Apple's iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark), or other mobile devices running Apple's iOS (registered trademark) operating system, devices running Microsoft's Windows (registered trademark) Mobile operating system, devices running Google's Android (registered trademark) operating system, and / or other smartphones or similar wearable mobile devices. In some examples, client device 310 can be the same as or similar to client device 110 as described with reference to FIGS. 1A or 1B.

[0057] 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 to one or more servers 320 and 325, for example, from an application 311 running on the client device 310. The one or more requests can be associated with the retrieval of data from one or more servers 320 and 325. The servers 320 and 325 can receive 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 the receipt of the requested data from 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, and the received data responds to the one or more requests.

[0058] 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 encryption operations as disclosed herein. In some examples, the one or more HSMs 330 can be configured as special-purpose security devices configured to perform one or more encryption operations. The HSM 330 can be configured such that the key is never revealed outside the HSM 330 and is instead maintained within the HSM 330. For example, the one or more HSMs 330 can be configured to perform at least one of key derivation, decryption, and MAC operations. The one or more HSMs 330 can be included within the servers 320 and 325 or can communicate with the servers 320 and 325.

[0059] System 300 may include one or more networks 315. In some examples, network 315 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect client devices 315 to servers 320 and 325. For example, network 315 may be an optical fiber 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, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-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 those networks. As a non-limiting example, communication from contactless card 305 and client device 310 may include NFC communication, a cellular network between client device 310 and a carrier, and the Internet between the carrier and the backend.

[0060] Furthermore, network 315 includes, but is not limited to, a global network such as a telephone line, an optical fiber, IEEE Ethernet 902.3, a wide area network, a wireless personal area network, a local area network, or the Internet. Further, network 315 can support an Internet network, a wireless communication network, a cellular network, etc., or any combination thereof. Network 315 can further include one network, or any number of the exemplary types of networks described above, operating as a stand-alone network or cooperating with each other. Network 315 can utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 315 can convert to one or more protocols of network devices between other protocols. Although network 315 is shown as a single network, according to one or more examples, network 315 can comprise, for example, a plurality of interconnected networks such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association network, and a home network.

[0061] In various examples according to the present disclosure, the client device 310 of the system 300 can execute one or more applications 311 and includes one or more processors 312 and one or more card readers 313. For example, one or more applications 311, such as software applications, can be configured to enable network communication with one or more components of the system 300 and to transmit and / or receive data. Although FIG. 3 shows only a single instance of the components of the client device 310, it is understood that any number of devices 310 can be used. The card reader 313 can be configured to read from and / or communicate with the contactless card 305. In conjunction with one or more applications 311, the card reader 313 can communicate with the contactless card 305.

[0062] Any application 311 of the client device 310 can communicate with the contactless card 305 using short-range wireless communication (e.g., NFC). The application 311 can be configured to interface with the card reader 313 of the client device 310, which is configured to communicate with the contactless card 305. It should be noted that those skilled in the art will understand that a distance of less than 20 centimeters corresponds to the NFC range.

[0063] In some embodiments, the application 311 communicates with the contactless card 305 via an associated reader (e.g., the card reader 313).

[0064] In some embodiments, card activation may occur without user authentication. For example, the contactless card 305 can communicate with the application 311 via the card reader 313 of the client device 310 via NFC. The communication (e.g., tapping the card in proximity to the card reader 313 of the client device 310) enables the application 311 to read data related to the card and perform activation. In some cases, the tap can activate or launch the application 311, and then start communication with one or more actions or the account server 325 to activate the card for subsequent use. In some cases, if the application 311 is not installed on the client device 310, tapping the card on the card reader 313 can initiate the download of the application 311 (e.g., navigation to an application download page). Following the installation, tapping the card activates or launches the application 311, and then (e.g., via the application or other backend communication) the activation of the card can be initiated. After activation, the card can be used in various transactions including commercial transactions.

[0065] According to some embodiments, the contactless card 305 may include a virtual payment card. In those embodiments, the application 311 can retrieve information related to the contactless card 305 by accessing a digital wallet implemented on the client device 310, and the digital wallet includes a virtual payment card. In some examples, the virtual payment card data may include one or more statically or dynamically generated virtual card numbers.

[0066] Server 320 may include a web server that communicates with database 335. Server 325 may include an account server. In some examples, server 320 may be configured to verify one or more pieces of credential information from contactless card 305 and / or client device 310 by comparing it with one or more pieces of credential information in database 335. Server 325 may be configured to permit one or more requests such as payments and transactions from contactless card 305 and / or client device 310.

[0067] FIG. 4 shows a key diversification method 400 according to an example of the present disclosure. Method 400 may include a transmitting device and a receiving device similar to transmitting device 205 and receiving device 210 referred to in FIG. 2.

[0068] For example, a sender and a receiver may desire to exchange data (e.g., original confidential data) via a transmitting device and a receiving device. As described above, these two parties may be involved, but it is understood that one or more transmitting devices and one or more receiving devices may be involved as long as each party shares the same shared secret symmetric key. In some examples, the transmitting device and the receiving device may be provisioned with the same master symmetric key. Further, it is understood that any party or device holding the same secret symmetric key can perform the function of the transmitting device, and similarly, any party holding the same secret symmetric key can perform the function of the receiving device. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties other than the transmitting device and the receiving device involved in the secure data exchange. Further, the same master symmetric key can be provided to both the transmitting device and the receiving device, and further, a part of the data exchanged between the transmitting device and the receiving device may include at least a part of the data that may be referred to as a counter value. The counter value may include a number that changes each time data is exchanged between the transmitting device and the receiving device.

[0069] At block 410, the sending device and the receiving device can be provisioned with the same master key, such as the same master symmetric key. When the sending device is preparing to process the confidential data in a symmetric encryption operation, the sender can update a counter. Further, the sending device can select an appropriate symmetric encryption algorithm, which may 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 comprise any symmetric encryption algorithm used as needed to generate a diversified symmetric key of a desired length. Non-limiting examples of symmetric algorithms can include symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. 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 the same master key and different input data can generate multiple outputs that can be combined as needed to generate a key of sufficient length.

[0070] The sending device can process the counter value using the selected encryption algorithm and the master symmetric key. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated for each conversation between the sending device and the receiving device.

[0071] Next, at block 420, the transmitting device can encrypt the counter value with a selected symmetric encryption algorithm using the master symmetric key to create a diversified symmetric key. The diversified symmetric key can be used to process the confidential data before transmitting the result to the receiving device. For example, the transmitting device can encrypt the confidential data using a symmetric encryption algorithm that uses the diversified symmetric key, and the output can comprise the protected encrypted data. Next, the transmitting device can transmit the protected encrypted data, along with the counter value, to the receiving device for processing. In some examples, encryption operations other than encryption can be performed, and multiple encryption operations can be performed using the diversified symmetric key before transmitting the protected data.

[0072] In some examples, the counter value may not be encrypted. In these examples, the counter value can be transmitted between the transmitting device and the receiving device at block 420 without encryption.

[0073] At block 430, the confidential data can be protected using one or more encryption algorithms and a diversified key. A diversified session key that may be created by key diversification using a counter can be used with one or more encryption algorithms to protect the confidential data. For example, the 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 that generates the protected data.

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

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

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

[0077] Next, if it is necessary to send confidential data from the sending device to the receiving device, a different counter value can be selected, which results in the generation of different diversified symmetric keys. By processing the counter value using the same symmetric encryption algorithm as the master symmetric key, both the sending device and the receiving device can independently generate the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the confidential data.

[0078] As described above, both the sending device and the receiving device initially own a shared master symmetric key respectively. The shared master symmetric key is not used for encrypting the original confidential data. Since the diversified symmetric keys are independently created by both the sending device and the receiving device, they are not transmitted between the two. Therefore, an attacker cannot intercept the diversified symmetric keys, and the attacker cannot view the data processed with the master symmetric key. Only a small counter value, rather than the confidential data, is processed with the master symmetric key. As a result, a reduction in side-channel data regarding the master symmetric key is revealed. Furthermore, the sender and the receiver can agree on, for example, the frequency of creating new diversification values, and thus new diversified symmetric keys, by prior agreement or other means. In one embodiment, new diversification values, and thus new diversified symmetric keys, can be created for all exchanges between the sending device and the receiving device.

[0079] In some examples, the key diversification value may constitute a counter value. Other non-limiting examples of key diversification values include a random nonce generated each time a new diversified key is required, a random nonce transmitted from the sending device to the receiving device, the complete value of the counter values transmitted from the sending device and the receiving device, a part of the counter values transmitted from the sending device and the receiving device, a counter independently maintained by the sending device and the receiving device but not transmitted between the two, a one-time passcode exchanged between the sending device and the receiving device, and an encryption hash of the confidential data. In some examples, one or more parts 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.

[0080] In other examples, some of the counters can be used as key diversification values. When multiple master key values are shared among parties, multiple diversified key values can be obtained by the systems and processes described herein. New diversification values, and thus new diversified symmetric keys, can be created as many times as needed. In the most secure cases, a new diversification value can be created each time confidential data is exchanged between the sending device and the receiving device. In effect, this can create a one-time use key such as a single session key.

[0081] In other examples, such as limiting the number of uses of the master symmetric key, the sender of the sending device and the receiver of the receiving device can agree that a new diversification value, and thus a new diversified symmetric key, will only occur periodically. In one example, this can be after a predetermined number of uses, such as every 10 transmissions between the sending device and the receiving device. In other examples, this can occur after a specific period of time, a specific period after transmission, or periodically (e.g., daily at a specified time; weekly at a specified time on a specified day). In other examples, this can be each time the receiving device signals the sending device that it wishes to change the key for the next communication. This can be controlled based on a policy and can vary, for example, depending on the current risk level recognized by the receiver of the receiving device.

[0082] Figure 5A shows one or more contactless cards 500, which may comprise a payment card such as a credit card, debit card, or gift card issued by a service provider 505 displayed on the front or back of the card 500. In some examples, the contactless card 500 may be unrelated to 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 that may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl 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 that conform to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it is understood that the contactless card 500 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a payment card.

[0083] The contactless card 500 may also include identification information 515 displayed on the front and / or back of the card, and contact pads 520. The contact pads 520 may be configured to establish contact with other communication devices such as user devices, smartphones, laptops, desktops, or tablet computers. The contactless card 500 may also include a processing circuit, an antenna, and other components not shown in Figure 5A. These components may be located behind the contact pads 520 or at other locations on the substrate 510. The contactless card 500 may also include a magnetic strip or tape that may be disposed on the back of the card (not shown in Figure 5A).

[0084] As shown in FIG. 5B, the contact pad 520 of FIG. 5A may include a processing circuit 525 for storing and processing information, including a microprocessor 530 and a memory 535. The processing circuit 525 may include additional components, such as a processor, a memory, an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, a security primitive, and anti-tampering hardware, as necessary to perform the functions described herein.

[0085] The memory 535 may be a read-only memory, a write-once / read-multiple memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 500 may include one or more of these memories. The read-only memory may be factory-read-only or programmable as a one-time programmable. The one-time programmability provides the opportunity to read multiple times after a single write. The write-once / read-multiple memory can be programmed at some point after the memory chip is shipped from the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after factory shipment. It can also be read multiple times.

[0086] Memory 535 may 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 may comprise one or more software applications configured to execute on one or more contactless cards, such as Java Card applets. However, it is understood that the applets 540 are not limited to Java Card applets and may instead be any software application operable on a contactless card or other device having limited memory. The one or more counters 545 may comprise numeric counters sufficient to store integers. The customer identifier 550 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 500, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 550 may identify both the customer and the account assigned to that customer, and may further identify the contactless card associated with the customer's account.

[0087] Although the processor and memory elements of the foregoing exemplary embodiments have been described with reference to the contact pads, the present disclosure is not so limited. It is understood that these elements may be implemented outside the pads 520, completely separated from the pads 520, or as additional elements in addition to the processor 530 and memory 535 elements disposed within the contact pads 520.

[0088] In some examples, the contactless card 500 may comprise one or more antennas 555. The one or more antennas 555 may be disposed within the contactless card 500 around the processing circuitry 525 of the contact pads 520. For example, the one or more antennas 555 may be integral with the processing circuitry 525 and the one or more antennas 555 may be used with an external booster coil. As another example, the one or more antennas 555 may be external to the contact pads 520 and the processing circuitry 525.

[0089] In one embodiment, the coil of the contactless card 500 can function as the secondary side of an air-core transformer. The terminal can communicate with the contactless card 500 by blocking power or amplitude modulation. The contactless card 500 can infer data transmitted from the terminal using the gap in the power connection of the contactless card, which can be functionally maintained via one or more capacitors. The contactless card 500 can return communication by switching the load of the coil of the contactless card or by load modulation. The load modulation can be detected by the coil of the terminal due to interference.

[0090] As described above, the contactless card 500 can be built on a software platform operable on other devices with limited memory such as smart cards or Java Cards, and one or more applications or applets can be securely executed. An applet can be added to the contactless card to provide one-time passwords (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet can be configured to respond to one or more requests such as proximity field data exchange requests from a reader such as a mobile NFC reader and generate an NDEF message with a cryptographically secure OTP encoded as an NDEF text tag.

[0091] Figure 6 shows an NDEF Short Record Layout (SR = 1) 600 according to an exemplary embodiment. One or more applets can be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, the NDEF message can comprise 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, English encoding (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message can be encoded as ASCII hexadecimal; type-length-value (TLV) data can be provided as personalization parameters for generating the NDEF message. In one embodiment, the authentication template can comprise a first record with a known index for providing actual dynamic authentication data.

[0092] Figure 7 shows a message 710 and a message format 720 according to an exemplary embodiment. In one example, when an additional tag is added, the first byte is changed to indicate the start of the message but does not indicate the end, and subsequent records can be added. Since the ID length is zero, the ID length field and the ID are omitted from the record. Examples of the message include UDK AUT key; derived AUT session key (using 0x00000050); version 1.0; pATC = 0x00000050; RND = 4838FB7DC171B89E; MAC = <calculated 8 bytes>.

[0093] In some examples, the data can be stored on the contactless card during personalization by performing STORE DATA (E2) under the secure channel protocol 2. The personalization bureau can read one or more values from the EMBOSS file (section specified by the applet ID) and send one or more store data commands to the contactless card after authentication and establishment of the secure channel.

[0094] The pUID is composed of a 16 - digit BCD - encoded number. In some examples, the pUID can be composed of 14 digits. [Table 1]

[0095] In some examples, one or more applets are configured to maintain their personalized state and can only allow personalization when unlocked and authenticated. Other states may have pre - personalization in the standard state. When entering the end state, one or more applets can be configured to delete the personalized data. In the end state, one or more applets can be configured to stop responding to all Application Protocol Data Unit (APDU) requests.

[0096] One or more applets can be configured to maintain the applet version (2 bytes) that can be used in the authentication message. In some examples, this can be interpreted as the major version in the most significant byte and the minor version in the least significant byte. The rules for each version are configured to interpret the authentication message. For example, for the major version, this can include that each major version has a specific authentication message layout and a specific algorithm. In the case of the minor version, this can include changes to the authentication message or encryption algorithm, as well as changes to static tag content, in addition to bug fixes and security enhancements.

[0097] In some examples, one or more applets may be configured to emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, each time the tag is read, various encrypted data that may indicate the reliability of the contactless card is presented. Based on one or more applications, the NFC reading of the tag can be processed, a token can be sent to a server such as a backend server, and the token can be verified at the server.

[0098] In some examples, the contactless card and the server may include specific data so that the card can be properly identified. The contactless card may include one or more unique identifiers. Each time a read operation is performed, it can be configured to update a counter. In some examples, each time the card is read, it is sent to the server for verification, and it is determined whether the counter is equal (as part of the verification).

[0099] One or more counters can be configured to prevent replay attacks. For example, if a ciphertext is obtained and reproduced, if the counter is read, used, or passed in some other way, the ciphertext will be immediately rejected. If no counter is used, it can be reproduced. In some examples, the counter updated on the card is different from the counter updated for transactions. In some examples, the contactless card may include a first applet that can be a transaction applet, and a second applet. Each applet may include a counter.

[0100] In some examples, the counter may become unsynchronized between the contactless card and one or more servers. For example, even if the contactless card is activated, the counter is updated, and new communication is generated by the contactless card, the communication may not be sent for processing by one or more servers. As a result, the counter maintained in the contactless card and the counter maintained in one or more servers may become unsynchronized. This can occur unintentionally, for example, when the card is stored adjacent to the device (e.g., carried in a pocket with the device), when the contactless card is read obliquely, when the card is out of position or not properly placed such that the power in the NFC range of the contactless card is on but it is not readable. When the contactless card is placed adjacent to the device, the NFC range of the device can be turned on to supply power to the contactless card and update the counter therein, but the application on the device does not receive the communication.

[0101] To maintain the synchronization of the counter, an application such as a background application can be executed that is configured to detect that the mobile device has woken up, synchronize with one or more servers, indicate that a reading has occurred due to the detection, and move the counter forward. Since the counters of the contactless card and one or more servers can become unsynchronized, one or more servers can be configured to allow the counter of the contactless card to be updated a threshold number of times or a predetermined number of times before the counter of the contactless card 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 each time an occurrence indicating the activation of the contactless card occurs, one or more servers can permit any counter value read from the contactless card as valid, or permit any counter value within a threshold range (e.g., from 1 to 10). Further, if one or more servers read a counter value that exceeds 10 but is below another threshold range value (such as 1000), the one or more servers can be configured to require a gesture associated with the contactless card, such as a user tap. If, from the user tap, the counter value is within the desired range or acceptable range, the authentication is successful.

[0102] Figure 8 is a flowchart showing a key operation 800 according to an exemplary embodiment. As shown in Figure 8, at block 810, two bank identifier number (BIN) level master keys can be used in combination with an account identifier and a card sequence number to generate two unique derived keys (UDKs) for each card. In some examples, the bank identifier number can comprise one number or a combination of one or more numbers, such as an account number or a random number provided by one or more servers, and can be used for the generation and / or diversification of a session key. The UDKs (AUTKEY and ENCKEY) can be stored on the card during the personalization process.

[0103] At block 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 the master key derivation where one unique set of keys is generated per card. In some examples, it is desirable to use a 4-byte format for both operations. Thus, at block 820, two session keys can be created for each transaction from the UDK. That is, one session key from AUTKEY and one session key from ENCKEY. In the card, for the MAC key (i.e., the session key created from AUTKEY), the lower 2 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.

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

[0105] At block 840, since 2-byte diversification is directly supported in the MAC authentication function of the payment HSM, the verification and processing of the MAC are simplified. The decryption of the ciphertext is performed before the verification of the MAC. Since the session keys are derived independently at one or more servers, a first session key (ENC session key) and a second session key (MAC session key) are generated. 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.

[0106] In the case of a contactless card, another unique identifier that may be related to the primary account number (PAN) of the application and the PAN sequence number encoded on the card is derived. Key diversification can be configured to receive the identifier as an input to the master key so that one or more keys can be created for each contactless card. In some examples, these diversified keys may comprise a first key and a second key. The first key may include an authentication master key (Card-Key-Auth for card ciphertext generation / authentication), and can be further diversified to create a MAC session key used during MAC ciphertext generation and verification. The second key may comprise an encryption master key (Card-Key-DEK for card data encryption), and can be further diversified to create an ENC session key used when encrypting and decrypting encrypted data. In some examples, the first and second keys can be created by diversifying the issuer master key by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of the payment applet. The pUID may comprise a 16-digit numerical value. As described above, the pUID may comprise a 16-digit BCD-encoded number. In some examples, the pUID may comprise a 14-digit numerical value.

[0107] In some examples, the EMV session key derivation method is 2 ∧ Since it can be wrapped with the use of 16, a counter such as a complete 32-bit counter can be added to the initialization array of the diversification method.

[0108] In other examples, such as credit cards, numbers such as account numbers, or unpredictable numbers provided by one or more servers can be used for session key generation and / or diversification.

[0109] FIG. 9 shows a diagram of a system 900 configured to implement one or more embodiments of the present disclosure. As described below, during the process of creating a contactless card, two encryption keys can be uniquely assigned for each card. The encryption key may include a symmetric key that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm can be used in EMV and is implemented by the hardware of the contactless card. By using a key diversification process, one or more keys can be derived from a master key based on uniquely identifiable information for each entity that requires a key.

[0110] Regarding master key management, two issuer master keys 905, 910 may be required for each part of a portfolio in which one or more applets are issued. For example, the first master key 905 may include an issuer ciphertext generation / authentication key (Iss-Key-Auth), and the second master key 910 may include an issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 905, 910 are diversified into card master keys 925, 930 that are unique for each card. In some examples, the network profile record ID (pNPR) 915 and the derived key index (pDKI) 920 as back-office data can be used to identify the issuer master keys 905, 910 used in the encryption process for authentication. A system that performs authentication can be configured to search for the values of the pNPR 915 and pDKI 920 of the contactless card during authentication.

[0111] In some examples, to enhance the security of the solution, a session key (such as a unique key per session) can be obtained. However, as described above, instead of using the master key, a unique key derived from the card and a counter can be used as diversified data. For example, each time the card is in operation, different keys can be used for creating a message authentication code (MAC) and performing encryption. Regarding the generation of the session key, the key used to generate the ciphertext and encrypt data within one or more applets can include a session key based on the unique keys of the card (Card-Key-Auth925 and Card-Key-Dek930). The session keys (Aut-Session-Key935 and DEK-Session-Key940) are generated by one or more applets and derived using the application transaction counter (pATC)945 with one or more algorithms. Only the lower 2 bytes of the 4-byte pATC945 are used to conform the data to one or more algorithms. In some examples, the 4-byte session key derivation method can include: F1 := PATC (lower 2 bytes) || 'F0' || '00' || PATC (4 bytes) F1 := PATC (lower 2 bytes) || '0F' || '00' || PATC (4 bytes) SK := {(ALG(MK)[F1]) || ALG(MK)[F2]}, where ALG can include 3DES ECB and MK can include the card unique derived master key.

[0112] As described herein, one or more MAC session keys can be derived using the lower two bytes of the pATC945 counter. Each time the contactless card is tapped, the pATC945 is configured to be updated, and the card master keys Card-Key-AUTH925 and Card-Key-DEK930 are further diversified into the session keys Aut-Session-Key935 and DEK-Session-Key940. The pATC945 can be initialized to zero during personalization or during applet initialization. In some examples, the pATC counter 945 can be initialized during or before personalization and can be configured to increment by one with each NDEF read.

[0113] Furthermore, each card update is unique and can be assigned by personalization or algorithmically assigned by the pUID or other identifying information. For example, odd-numbered cards can be incremented or decremented by two, and even-numbered cards can be incremented or decremented by five. In some examples, the updates can also differ for sequential reads, and a single card can be incremented in order in a repeating pattern of 1, 3, 5, 2, 2, …. A specific sequence or algorithm sequence can be defined during personalization or from one or more processes derived from a unique identifier. This can make it difficult for replay attackers to generalize from a small number of card instances.

[0114] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, the authentication data and only an 8-byte random number followed by the MAC of the authentication data may be included. In some examples, the random number is in front of the ciphertext A and can be of 1 block length. In other examples, the length of the random number may not be restricted. In further examples, the total data (i.e., the random number and the ciphertext) can be a multiple of the block size. In these examples, an additional 8-byte block can be added to match the block generated by the MAC algorithm. As another example, if the adopted algorithm uses 16-byte blocks, multiples of that block size can be used or the output can be automatically or manually padded to a multiple of that block size.

[0115] The MAC can be executed by the function key (AUT-Session-Key) 935. The data specified in the ciphertext can be processed by the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 and associated with the EMV ARQC verification method. The key used for this calculation can be equipped with the session key AUT-Session-Key 935 as described above. As described above, the lower 2 bytes of the counter can be used to diversify one or more MAC session keys. As will be described below, AUT-Session-Key 935 can be used for MAC data 950, and the resulting data or ciphertext A 955 and random number RND can be encrypted using DEK-Session-Key 940 to create ciphertext B or output 960 transmitted in the message.

[0116] In some examples, one or more HSM commands may be processed for decryption such that the last 16 (binary, 32 hex) bytes use 3DES symmetric encryption with a random zero IV followed by MAC authentication data. The key used for this encryption may comprise a session key DEK-Session-Key940 derived from Card-Key-DEK930. In this case, the ATC value for session key derivation is the least significant byte of counter pATC945.

[0117] The following format represents an exemplary embodiment of the binary version. Further, in some examples, the first byte may be set to the ASCII "A".

Table 2

[0118] Other exemplary formats are shown below. In this example, the tags can be encoded in hexadecimal format.

Table 3

[0119] Extract the UID field of the received message, and derive the card master keys (Card-Key-Auth925 and Card-Key-DEK930) of that specific card from the master keys Iss-Key-AUTH905 and Iss-Key-DEK910. Using the card master keys (Card-Key-Auth925 and Card-Key-DEK930), the session keys (Aut-Session-Key935 and DEK-Session-Key940) of that specific card can be derived using the counter (pATC) field of the received message. The ciphertext B960 can be decrypted using the DEK-Session-KEY. Thereby, the ciphertext A955 and RND are generated, and RND can be discarded. The UID field can be used to search for the shared secret of the contactless card. This is processed through the encrypted MAC using the recreated Aut-Session-Key together with the Ver, UID, and pATC fields of the message to create a MAC output such as MAC’. If MAC’ is the same as the ciphertext A955, this indicates that both the decryption of the message and the MAC check have passed. Next, read the pATC and determine whether it is valid.

[0120] During an authentication session, one or more ciphertexts can be generated by one or more applications. For example, one or more ciphertexts can be generated as 3DES MAC using padding of method 2 via one or more session keys such as ISO9797-1 algorithm 3 and Aut-Session-Key935. The input data 950 can take the following form: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses can be in bytes length. In some examples, the shared secret can be generated by one or more random number generators configured to guarantee that the random numbers cannot be predicted through one or more secure processes. In some examples, the shared secret can comprise a random 4-byte binary number injected into the card during personalization and known to the authentication service. During the authentication session, the shared secret cannot be provided from one or more applets to the mobile application. The padding of method 2 can include adding an obligatory 0x’80’ byte at the end of the input data and adding optional 0x’00’ bytes that can be added at the end of the resulting data up to an 8-byte boundary. The resulting ciphertext can be composed of 8 bytes in length.

[0121] In some examples, one of the advantages of using a MAC ciphertext to encrypt a non-shared random number as the first block is that it can function as an initialization vector while using the CBC (block chain) mode of a symmetric encryption algorithm. This allows "scrambling" between blocks without having to pre-establish a fixed or dynamic IV.

[0122] By including an application transaction counter (pATC) as part of the data contained in the MAC ciphertext, the authentication service can be configured to determine whether the value transmitted in clear data has been tampered with. Further, by including a version in one or more ciphertexts, it is difficult for an attacker to deliberately fake the version of the application in an attempt to reduce the strength of the encryption solution. In some examples, the pATC can start at zero and be incremented by one each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during an authentication session. In some examples, if the authentication data uses a pATC that is 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 one can be rejected. In some examples, if the pATC is greater than a previously received value, it is evaluated to determine whether it is within an acceptable range or threshold, and if it exceeds the range or threshold, the verification can be considered to have failed or be untrustworthy. In the MAC operation 936, the data 950 is processed through the MAC using the Aut-Session-Key 935 to generate an encrypted MAC output (ciphertext A) 955.

[0123] To provide additional protection against a brute force attack that discloses the key on the card, it is desirable that the MAC ciphertext A955 be encrypted. In some examples, the data or ciphertext A955 included in the encrypted text may comprise a random number (8), a ciphertext (8). In some examples, the numbers within the parentheses may comprise a length in bytes. In some examples, the random number may be generated by one or more random number generators configured to ensure that the random number is unpredictable through one or more secure processes. The key used to encrypt this data may comprise a session key. For example, the session key may comprise DEK-Session-Key940. In the encryption operation 941, the data or ciphertext A955 and RND are processed using DEK-Session-Key940 to generate an encrypted data, ciphertext B960. The data 955 is encrypted using 3DES in cipher block chaining mode, ensuring that an attacker has to perform an attack on all encrypted texts. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) can be used. In some examples, an initialization vector of 0x’0000000000000000’ can be used. Since the correctly decrypted data is displayed randomly and thus indistinguishable from incorrectly decrypted data, an attacker attempting to find the key used to encrypt this data by brute force is unable to determine when the correct key was used.

[0124] To verify one or more ciphertexts provided by an authentication service by one or more applets, the following data needs to be transmitted in plaintext from one or more applets to the mobile device during an authentication session: a version number to determine the encryption approach used and a message format for the verification of the encryption, thereby allowing the approach to be changed in the future; a pUID to search for cryptographic assets and derive the card key; a pATC to derive the session key used for the ciphertext.

[0125] Figure 10 shows a method 1000 for generating a ciphertext. For example, in block 1010, a network profile record ID (pNPR) and a derived key index (pDKI) can be used to identify an issuer master key for use in an encryption process for authentication. In some examples, this method may include performing authentication and retrieving the values of pNPR and pDKI of the contactless card at the time of authentication.

[0126] In block 1020, the issuer master keys can be diversified by combining them with the unique ID number of the card (pUID) and the PAN sequence number (PSN) of one or more applets, for example, a payment applet.

[0127] In 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 a MAC ciphertext.

[0128] In block 1040, the keys used to generate the ciphertext and encrypt the data within one or more applets may comprise the session keys of block 1030 based on the card-unique keys (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys are generated by one or more applets, derived using pATC, and become the session keys Aut-Session-Key and DEK-Session-Key.

[0129] Figure 11 shows an exemplary process 1100 for key diversification according to an example. First, two different master keys can be provisioned to the sender and the receiver. For example, the first master key may comprise a data encryption master key, and the second master key may comprise a data integrity master key. The sender has a counter value that can be updated in block 1110, and other data such as the data to be protected that can guarantee its sharing with the receiver.

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

[0131] In some examples, the counter value may not be encrypted. In these examples, the counter can be sent in plaintext, i.e., without encryption, between the sender and the receiver.

[0132] In block 1130, the data to be protected is processed by the sender's encrypted MAC operation using the data integrity session key and an encryption MAC algorithm. A MAC can be generated using the protected data including the plaintext and the shared secret and one of the session keys (AUT-Session-Key).

[0133] In block 1140, the data to be protected can be encrypted by the sender using the data encryption derived session key in combination with a symmetric encryption algorithm. In some examples, the MAC is combined with, for example, an equal amount of random data of each 8-byte length and encrypted using a second session key (DEK-Session-Key).

[0134] In block 1150, the encrypted MAC is sent from the sender to the receiver along with information sufficient to identify additional secret information (such as the shared secret, master key, etc.) for verification of the ciphertext.

[0135] In block 1160, the receiver independently derives two derived session keys from the two master keys using the received counter value as described above.

[0136] In block 1170, the data encryption derived session key is used in combination with a symmetric decryption operation to decrypt the protected data. Thereafter, additional processing is performed on the exchanged data. In some examples, after the MAC is extracted, it may be desirable to reproduce and match the MAC. For example, when verifying the ciphertext, it can be decrypted using a properly generated session key. The protected data can be reconstructed for verification. The MAC operation can be performed using a properly 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.

[0137] In block 1180, the data integrity derived session key is used in combination with an encrypted MAC operation to verify that the protected data has not been modified.

[0138] Some examples of the methods described herein can advantageously confirm when successful authentication is determined when the following conditions are met. First, the function of verifying the MAC indicates that the derived session key is appropriate. The MAC can only be correct if the decryption is successful and an appropriate MAC value is obtained. If the decryption is successful, it may indicate that the properly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the transmitting device) and the receiver (e.g., the receiving device), it can be trusted that the contactless card that first created the MAC and encrypted the MAC is genuine. Further, the counter values used to derive the first and second session keys can be shown to be valid and can be used to perform the authentication operation.

[0139] Thereafter, the two derived session keys can be discarded, and the next iteration of the data exchange can update the counter value (return 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.

[0140] Exemplary embodiments of the systems and methods described herein may be configured to provide security element authentication. The security element authentication may comprise a plurality of processes. As part of the security element authentication, a first process may comprise logging in and verifying the user via one or more applications running on the device. As a second process, in response to a successful login and verification of the first process via one or more applications, the user may engage in one or more actions associated with one or more contactless cards. In effect, the security element authentication may include both securely proving the identity of the user and engaging in one or more types of actions, including but not limited to one or more tap gestures associated with the contactless card. In some examples, the one or more tap gestures may comprise tapping the contactless card on the device by the user. In some examples, the device may comprise a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process received tap gestures.

[0141] In some examples, a contactless card can be tapped on a device such as one or more computer kiosks or terminals to perform an identity verification to receive a transaction item in response to a purchase such as coffee. By using a contactless card, a secure way to prove an ID in a loyalty program can be established. For example, securely proving an ID to obtain rewards, coupons, offers, etc., or to receive benefits is established in a different way than simply scanning a bar card. For example, an encrypted transaction can occur between the contactless card and the device. This can be configured to process one or more tap gestures. As described above, one or more applications can be configured to verify the user's ID and then cause the user to act or respond thereto, e.g., via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, healthcare information, etc., can be written back to the contactless card.

[0142] In some examples, the contactless card can be tapped on a device such as a mobile device. As described above, the user's ID can be verified by one or more applications and then it will provide the user with the desired benefits based on the verification of the ID.

[0143] In some examples, a contactless card can be activated by tapping a device such as a mobile device. For example, the contactless card can communicate with an application on the device via a card reader of the device through NFC communication. In a communication where the tap of the card is in proximity to the card reader of the device, the application on the device can read data associated with the contactless card and activate the card. In some examples, activation can permit the card to be used to perform other functions, such as making purchases, accessing accounts or restricted information, or performing other functions. In some examples, the tap can activate or launch an application on the device, which can then initiate one or more actions or communication with one or more servers to activate the contactless card. If the application is not installed on the device, tapping a contactless card near the card reader can initiate a download of the application, such as navigation to a download page for the application. Following installation, tapping the contactless card activates or launches the application, after which activation of the contactless card is initiated, for example, via the application or other backend communication. After activation, the contactless card can be used in various activities including, but not limited to, commercial transactions.

[0144] In some embodiments, a dedicated application can be configured to run on a client device to perform the activation of a contactless card. In other embodiments, a web portal, a web-based app, an applet, etc. can perform the activation. The activation may be performed on the client device or the client device may function as an intermediary between the contactless card and an external device (e.g., an account server). According to some embodiments, when providing the activation, the application may indicate to the account server the type of device (e.g., a personal computer, a smartphone, a tablet, or a point-of-sale (POS) device) on which the activation is being performed. Further, the application may output different and / or additional data to the account server for transmission depending on the type of device involved. For example, such data may include information related to the merchant, such as merchant type, merchant ID, and information related to the device type itself, such as POS data and POS ID.

[0145] In some embodiments, an exemplary authentication communication protocol can be modified to mimic the EMV standard's offline dynamic data authentication protocol commonly executed between a transaction card and a point-of-sale information management device. For example, since an example of the authentication protocol is not used to complete a payment transaction with the card issuer / payment processor itself, some data values are unnecessary and authentication can be performed without the need for a real-time online connection to the card issuer / payment processor. As is known in the art, a point-of-sale information management (POS) system submits a transaction, including the transaction amount, to the card issuer. Whether the issuer approves or rejects the transaction can be based on whether the card issuer recognizes the transaction amount. On the other hand, in certain embodiments of the present disclosure, a transaction originating from a mobile device lacks the transaction amount associated with the POS system. Thus, in some embodiments, a dummy transaction amount (i.e., a value recognizable by the card issuer and sufficient for activation to occur) can be passed as part of the exemplary authentication communication protocol. POS-based transactions may also reject a transaction based on the number of attempts of the transaction (e.g., a transaction counter). If attempts are made more than a buffer value, it can gradually decrease. The gradual decrease requires further verification before accepting the transaction. In some implementations, the buffer value of the transaction counter can be changed to avoid a decrease in legitimate transactions.

[0146] In some examples, the contactless card can selectively communicate information depending on the recipient's device. When the contactless card is tapped, it can recognize the device being tapped, and based on this recognition, the contactless card can provide appropriate data to that device. This is advantageous in that the contactless card transmits only the information necessary to complete an immediate action or transaction such as payment or card authentication. By restricting data transmission and avoiding the transmission of unnecessary data, both efficiency and data security can be improved. Recognition and selective communication of information can be applied to various scenarios such as card activation, balance transfer, account access attempts, commercial transactions, and reduction of step-up fraud.

[0147] When a contactless card tap is directed at a device running Apple's iOS® operating system, such as an iPhone®, iPod®, or iPad®, the contactless card can recognize the iOS® operating system and transmit appropriate data for communicating with this device. For example, the contactless card can provide encrypted ID information necessary to authenticate the card using an NDEF tag, for example, via NFC. Similarly, when a contactless card tap is directed at a device running the Android® operating system, such as an Android® smartphone or tablet, the contactless card can recognize the Android® operating system and transmit appropriate data for communicating with this device (such as encrypted ID information necessary for authentication according to the methods described herein).

[0148] As another example, a contactless card tap can be directed to a POS device including, but not limited to, kiosks, checkout registers, payment stations, or other terminals. When a tap is performed, the contactless card can recognize the POS device and send only the information necessary for the action or transaction. For example, upon recognizing a POS device used to complete a commercial transaction, the contactless card can transmit the payment information necessary to complete the transaction under the EMV standard.

[0149] In some examples, the POS device participating in the transaction can request or specify additional information provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, when the POS device receives data communication from the contactless card, the POS device can recognize the contactless card and request additional information necessary to complete the action or transaction.

[0150] In some examples, the POS device can partner with an authorized seller or other entity that is familiar with a particular contactless card or is accustomed to performing a particular contactless card transaction. However, it is understood that such partnerships are not required for the execution of the described method.

[0151] In some examples, such as in a shopping store, grocery store, convenience store, etc., the contactless card can be tapped on a mobile device without opening an application to indicate a desire or intent to utilize one or more reward points, loyalty points, coupons, offers, etc. to cover one or more purchases. Thus, the intent behind the purchase is provided.

[0152] In some examples, one or more applications may be configured to determine that one or more tap gestures of a contactless card have been initiated, such that, to verify the user's ID, it was initiated at 3:51 PM and the transaction was processed or executed at 3:56 PM.

[0153] In some examples, one or more applications may be configured to control one or more actions in response to one or more tap gestures. For example, the one or more actions may include reward collection, point collection, determination of the most important purchase, determination of the least expensive purchase, and / or reconfiguration to other actions in real time.

[0154] In some examples, data may be collected about the tap behavior as biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and difficult to eavesdrop on may be sent to one or more backend services. The unique identifier can be configured to search for secondary information about an individual. The secondary information may include information that can identify the individual regarding the user. In some examples, the secondary information may be stored within the contactless card.

[0155] In some examples, the device may include an application that splits bills or checks payments among multiple individuals. For example, each individual may own a contactless card and may or may not be a customer of the same issuing financial institution. Each of these individuals may receive a push notification on the device via the application to split a purchase. Instead of only accepting one card tap to indicate payment, other contactless cards may be used. In some examples, individuals with different financial institutions may own a contactless card for providing information to initiate one or more payment requests from the individual tapping the card.

[0156] The following usage examples illustrate specific examples of the present disclosure. These are for illustrative purposes only and not for purposes of limitation. In one case, a first friend (payer) has an obligation to pay an amount to a second friend (recipient). Instead of accessing an ATM or requesting an exchange via a peer-to-peer application, the payer makes the payment via the recipient's smartphone (or other device) using a contactless card. The recipient logs on to an appropriate application on the smartphone and selects a payment request option. In response, the application requests authentication via the recipient's contactless card. For example, the application outputs a display requesting that the recipient tap the contactless card. When the recipient taps the contactless card against the smartphone screen with the application enabled, the contactless card is read and verified. Next, the application displays a prompt asking the payer to tap the contactless card to send the payment. When the payer taps the contactless card, the application reads the card information and sends a payment request to the payer's card-issuing company via the associated processor. The card-issuing company processes the transaction and sends a transaction status indicator to the smartphone. Next, the application outputs to display the transaction status indicator.

[0157] In other examples, a credit card customer may receive a new credit card (or debit card, other payment card, or other card that requires activation) by mail. Instead of calling a provided phone number associated with the card issuer or accessing a website to activate the card, the customer can decide to activate the card via an application on their device (e.g., a mobile device such as a smartphone). The customer can select the card activation function from the application menu displayed on the device's display. The application may prompt the customer to tap the credit card against the screen. When the credit card is tapped against the device's screen, the application can be configured to communicate with a server such as a card-issuing server that activates the customer's card. Next, the application may display a message indicating that the card activation was successful. This completes the card activation.

[0158] FIG. 12 shows a method 1200 for card activation according to an exemplary embodiment. For example, card activation can be completed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers can refer to the same or similar components as those described above with reference to FIGS. 1A, 1B, 5A, and 5B, such as contactless card 105, client device 110, server 120.

[0159] In block 1210, the card can be configured to dynamically generate data. In some examples, this data can include information such as an account number, card identifier, card verification value, or phone number, which 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.

[0160] In block 1220, one or more portions of the dynamically generated data can be communicated to the device's application via NFC or other wireless communication. For example, tapping a card in proximity to the device can enable the device's application to read one or more portions of the data associated with the contactless card. In some examples, if the device does not have an application that assists in activating the card, the card tap can prompt the customer to the software application store to download a related application to instruct the device or activate the card. In some examples, the user can be prompted to gesture, position, or orient the card sufficiently, such as by facing the card towards the surface of the device, diagonally on the surface of the device, or flat, near, or in proximity to the device. In response to sufficient gesture, placement, and / or orientation of the card, the device can begin to send one or more encrypted portions of the data received from the card to one or more servers.

[0161] 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 sent from the device to the card issuing server for activation of the card.

[0162] At block 1240, one or more servers may decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from a device and decrypt it to compare the received data and record data accessible to the one or more servers. If the comparison of the results of one or more decrypted portions of data by the one or more servers results in a successful match, the card may be activated. If the comparison of the results of one or more decrypted portions of data by the one or more servers results in a failed match, one or more processes may be performed. For example, in response to a determination of a failed match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold with a number of attempts allowed for the user to activate the card. Alternatively, the user may receive a notification on the device, such as a message indicating that the card verification attempt has failed, and make a phone call, send an email, or send a text message to a related service for assistance in activating the card, or receive another notification on the device, such as a phone call indicating that the card verification attempt has failed, and make a phone call, send an email, or send a text message to a related service for assistance in activating the card, or receive another notification, such as an email indicating that the card verification attempt has failed, and make a phone call, send an email, or send a text message to a related service for assistance in activating the card.

[0163] In block 1250, one or more servers may send a return message based on the success of card activation. For example, the device may be configured to receive an output from one or more servers indicating that the activation of the card by the one or more servers has been successful. The device may be configured to display a message indicating that the activation of the card has been successful. When the card is activated, the card may be configured to stop the dynamic generation of data in order to avoid unauthorized use. In this way, the card may not be activated thereafter, and it is notified to one or more servers that the card has already been activated.

[0164] In another example case, a customer wants to access their financial account with their 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 view first-level account information (e.g., recent purchases) and perform first-level account options (e.g., credit card payments). However, when the user wants to access second-level account information (e.g., spending limits) or perform second-level account options (e.g., transfers to external systems), a second factor authentication is required. Therefore, the application requests that the user provide a transaction card (e.g., a credit card) for account verification. Next, the user taps their credit card on the mobile device, and the application verifies 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.

[0165] The systems and methods described herein provide a non-contact card that can initiate a call, pass a token to a telephone system, and be gestured towards a mobile device to activate the non-contact card. In one example, this can be done via a cellular telephone system without using an application. As a result, these techniques provide various advantages including a more efficient method of card activation, enhanced security for consumers and issuing institutions, and elimination of the need for users to utilize an application.

[0166] FIG. 13 shows a card activation system 1300 that includes a non-contact card 1305, a client device 1310, and one or more servers 1320. Although FIG. 13 shows a single instance of the components, system 1300 can include any number of components. The non-contact card 1305, client device 1310 and one or more client applications 1316, and one or more servers 1320 can refer to the same or similar components as those previously described with reference to FIGS. 1A, 1B, 5A, and 5B, such as non-contact card 105, client device 110, and server 120.

[0167] The contactless card 1305 may include one or more processors 1307 and a memory 1309. The memory 1309 may include one or more applets 1311. In some examples, when gestures, including but not limited to one or more gestures, are performed so that the contactless card 1305 can enter the communication range of the client device 1310, e.g., the NFC range, to establish communication, e.g., NFC communication, one or more applets 1311 of the contactless card can generate an NDEF file that can be read by the client device 1310 and / or one or more client applications 1316. The client device 1310 may include one or more processors 1312 and a memory 1314, and may include one or more client applications 1316 comprising instructions for execution on the client device. The one or more client applications 1316 may be software applications configured to perform the client device functions described herein. The client device 1310 and / or the client applications 1316 may communicate data with the contactless card 1305 via a communication interface (not shown). In some examples, the one or more gestures may include at least a tap, a wave, or other gesture of the contactless card 1305 so that the contactless card 1305 enters the communication range of the client device 1310. For example, the contactless card 1305 may be tapped on a client device 1310, such as a mobile device, to initiate a call.

[0168] The NDEF file can initiate one or more communications with one or more client applications 1316 on the client device 1310. As described below, one or more applets 1311 of the contactless card 1305 can dynamically generate information such as a phone number and an ID token or payload that can be attached to the phone number. In some examples, a call using the phone number can be made by phone to one or more servers 1320, and the one or more servers 1320 can be configured to monitor the call and receive the decoded input. For example, the NDEF file can be read from the contactless card 1305 to the client device 1310 and / or one or more client applications 1316, a switch to the phone system is made, and the phone system answers the call, receives the automatic input of the number or payload, sends it to one or more servers 1320, where it is decoded and authenticated and sent back to the phone system, and can indicate success or failure of authentication using one or more fallback options. In some examples, the call is not IP-based. That is, it is not made using Voice-over-IP (VoIP) or other IP-based call mechanisms. The one or more servers 1320 can communicate with the client device 1310 and / or one or more client applications 1316 for data.

[0169] In some examples, one or more processes can be utilized to activate the contactless card 1305. Exemplary processes include, but are not limited to, an initiated call.

[0170] For example, a link can be generated that is configured to initiate a call on the client device 1310. The call can be initiated by the default phone program of the client device 1310, or in other examples, a different or specified phone program can be used. Following this link, a call can be initiated, then paused, and then an ID token can be provided. In this way, the contactless card 1305 can be configured to initiate a call. Examples of links are shown below. tel: / / 1234567890,,,1234567##

[0171] In some examples, the link can include one or more information elements. In some examples, the link can include a first information element, a second information element, and a third information element. For example, the first information element can precede the second element of information, and the second information element can precede the third information element.

[0172] In one embodiment, the first information element can include a phone number such as (123)456-7890. In some examples, the number can be US-based including the area code. In other examples, the number may not be US-based, for example, the number can further include a country code and can result in an international call. In some examples, one or more phone numbers can be generated dynamically, or one or more phone numbers can be retrieved from a pre-set list. The phone number element of the call can be hard-coded to call the card activation phone number or other service, such as tel: / / 1234567890.

[0173] In one embodiment, the second information element may comprise one or more characters such as one or more commas. In some examples, the one or more commas may be interpreted as one or more persistent pauses. For example, the duration of the pause may comprise a fixed period, for example, one second. Thus, if a comma is interpreted as a one-second persistent pause, including four commas (as in the above link example), a four-second pause may occur. In some examples, the number of commas may be of sufficient length for the telephone system to listen and respond. This may ensure that, as described below, the automated telephone system responds to the call and has time to wait for additional information elements.

[0174] In one embodiment, the link may include a third information element that may comprise one or more payloads. For example, a delivered payload such as 1234567## may be configured to authenticate a contactless card. In some examples, this numeric string may be passed to the telephone system in an encrypted format and decrypted with a key. For example, if the decryption process fails for reasons such as the number being deleted for static or other reasons, this process may trigger one or more fallback options. For example, one option may include routing the call to an operator or customer service representative who can handle the call. In other examples, another option may include routing this process to another system to be able to enter the card verification value of the contactless card, as described below.

[0175] In some examples, if an incorrect telephone number is used during the activation of the contactless card 1305, this event may be flagged and stored in a database for analysis of potential suspects. As a result, an unregistered telephone number may indicate a high likelihood of improper conduct.

[0176] In some examples, values such as the card verification value (CVV) of the contactless card 1305 can be configured to activate the contactless card 1305. In other examples that can provide higher security than the CVV method, it includes leveraging one-time passwords (OTPs) generated by one or more card applets 1311, which can be encrypted and decrypted by one or more servers to authenticate the contactless card 1305.

[0177] In some examples, the telephone system can analyze the payload from a call and pass it through one or more web applications for decryption. In some examples, tokens can be encrypted via a secret / public key pair. For example, the secret key can be used to decrypt the data, securely store it, and enable encryption (using the public key) without the secret key. That is, since there is no need to transfer the secret key, it is not affected by eavesdropping by a third party. The number used to initiate a call can be checked and verified by one or more servers 1320 to determine the validity of the phone number. Thus, decrypting the encrypted data and notifying or displaying that the contactless card 1305 has been activated in this way can include sending a text message or an email from one or more servers 1320 to the client device 1310 and / or one or more client applications 1316.

[0178] In some examples, after the contactless card 1305 is successfully activated and one or more client applications 1316 of the client device 1310 receive a notification indicating the activation, the contactless card 1305 may be instructed to disable the dynamic generation of data. In some examples, as described above, after the contactless card 1305 is activated via one of one or more processes, the user of the contactless card 1305 may optionally be directed to customer support, or the contactless card 1305 may be used in a POS device or other system. For example, when the user interacts with a POS device using the activated card, the contactless card 1305 may be instructed to stop the dynamic generation of numbers. In some examples, this may require communication between applets such as a payment applet or a transaction applet shown in one or more other applets 1311 of the contactless card 1305, and stop the generation of the phone number upon the next occurrence of one or more gestures by the contactless card 1305, thereby allowing the contactless card 1305 to enter the communication range of the client device 1310. In this way, the dynamic generation function of the contactless card 1305 may be turned off or disabled in response to the successful activation of the contactless card 1305.

[0179] As an example, the contactless card 1305 can be configured to cause, or the payload of the contactless card 1305 can be configured to cause, one or more of the following in a client device that receives the payload: (i) download an application compatible with the contactless card 1305; (ii) transfer a balance or other amount between one or more accounts belonging to the user of the contactless card 1305; (iii) reset a personal identification number (PIN) associated with the user, the contactless card 1305, or an account associated with the user of the contactless card 1305; (iv) link an account belonging to a user who is not an account to the entity that issued the contactless card 1305; (v) approve or cause a transfer of balance from one or more accounts to an account associated with the contactless card 1305 or from an account; (vi) request an exchange of the card from the issuer of the contactless card 1305; (vii) request or cause an Automated Clearing House (ACH) payment; (viii) approve or cause a wire transfer between the user corresponding to the contactless card 1305 or an account belonging to the user; (ix) perform user registration, registration verification, or authentication to permit connection of the account associated with the user or the contactless card 1305 to a payment service associated with a device 1310 including, but not limited to, Apple Pay®, Samsung Pay®, Android Pay®, Google Pay®, Venmo®, or Paypal®; (x) request an activity associated with the account, such as, for example, increasing the credit limit of a credit account, request a quick transaction (such as clearing a check), or dispute a transaction. Without limitation, one or more of the above can be achieved, for example, by using the contactless card 1305 configured with a specific NDEF message.

[0180] In some examples, the contactless card 1305 may have two-way communication with the client device 1310 and / or one or more client applications 1316. For example, an application installed on the client device 1310 may use its functionality including but not limited to the NFC medium of the client device 1310 to send an NDEF or other message to the contactless card 1305. This message may include information corresponding to, for example, the type of authentication request sent from a service associated with one or more servers 1320. For example, a particular flag or payload received by the contactless card 1305 from the client device 1310 and / or the client application 1316 may modify a particular payload generated by the contactless card 1305. In some examples, the contactless card 1305 may generate a payload tailored for a particular purpose shown, including but not limited to a transfer of balance by the user.

[0181] In some examples, a user may desire to download an application to his or her client device 1310. The download of the application may be restricted by the user verifying his or her identity for the account. In an exemplary embodiment, the application manager may permit the download of a particular application only upon verification of the user. The user may tap his or her contactless card 1305 on the client device 1310 so as to come within the communication range of the client device 1310, and the client device 1310 and one or more client applications 1316 may be configured to receive the phone number and the number linked to the authentication as described above. The application manager may obtain this information and may further append or pass parameters indicating the user application that the user is to download. When this payload is sent, the client device 1310 and / or one or more client applications 1316 may receive a payload for authenticating the contactless card 1305 and / or the user. The received payload may further include information corresponding to the particular application for which the download is requested. For example, if a part of the received payload is encrypted and decrypted by the application manager, the application manager may download the application. In this way, the identity of the user is confirmed and only the authorized user can download the desired application. Further, one or more servers 1320 may, by receiving the payload, maintain or otherwise track which user has downloaded a particular application.

[0182] In some examples, a user may transfer a balance from one account to another. These accounts can be accounts within one institution (e.g., a savings account and a checking account), or accounts that belong to the user but are held at different institutions. The user may initiate a request to transfer the balance. The balance transfer request can occur at a physical location such as a branch, online on a computer, or from a client device 1310. In an exemplary embodiment, to confirm that the user has initiated the request, the user may receive a notification on his or her client device 1310. This notification can include a push notification, a call, or a text message. Upon receiving the notification, the user may gesture, such as tapping, his or her contactless card 1305 against his or her client device 1310 so that the contactless card 1305 enters the communication range of the client device 1310. Next, the contactless card 1305 may send a payload to the client device 1310. Next, upon receiving the payload, the client device 1310 may send a token to one or more servers via a call to verify the user's identity. In an exemplary embodiment, the user is required to gesture, such as tapping, so as to confirm that his or her contactless card 1305 enters the communication range of the client device 1310 within a predetermined period from receiving the notification and that he or she wishes to make a balance transfer request. Upon receiving the payload, one or more servers 1320 may verify the user's identity and approve the requested balance transfer to occur.

[0183] In some examples, the user may request to reset the PIN number associated with his or her contactless card 1305. This PIN number may be associated with the contactless card 1305 associated with the user account, or may be associated with other cards such as debit or credit cards associated with other user accounts. In an exemplary embodiment, the user may initiate a request to reset his or her PIN at a physical location (such as a bank) via an online portal or via the client device 1310. In response to the user request, the service associated with one or more servers 1320 may send a notification to the user. The notification may be sent via any medium including, but not limited to, email, text message, push notification on an application installed on the client device 1310, or via a call. Upon receiving the notification, the user may tap his or her contactless card 1305 on his or her client device 1310, as a result of which the contactless card 1305 may enter the communication range of the client device 1310. As described above, the client device 1310 may be configured to receive a payload from the contactless card 1305. This payload may include a phone number, a comma, and a string of digits following the comma. Next, the client device 1310 and / or one or more client applications 1316 may initiate a call in response to receiving the payload, which may send the number received from the contactless card 1305 to the service associated with one or more servers 1320. In an exemplary embodiment, if the notification is received in the form of a call, one or more servers 1320 may be configured to ignore the portion of the number sent to it that corresponds to the phone number. In some examples, the contactless card 1305 may be configured to conform the form of the payload to include only the portion corresponding to the token following the comma when it receives an NFC signal from the client device 1310 and / or one or more client applications 1316 indicating that a call is already active.Next, this technique can rationalize the information received from the contactless card 1305 without the need to configure one or more servers 1320 to distinguish between the payload portion corresponding to the phone number and the payload portion corresponding to the token.

[0184] In an exemplary embodiment, a user may wish to link a user account external to the entity that issued his or her contactless card 1305 to an account with the entity that issued his or her contactless card 1350. Upon receiving the payload, one or more servers 1320 associated with the entity may verify the identity of the user and approve that the requested balance transfer occurs. In an exemplary embodiment, the user may initiate this request at a physical location (such as a bank), via an online portal, or via a client device 1310. In response to the user request, a service associated with one or more servers 1320 may send a notification to the user. The notification may be sent via any medium including, but not limited to, email, text message, a push notification on an application installed on the client device 1310, or via a call. Upon receiving the notification, the user may tap his or her contactless card 1305 on his or her client device 1310 to bring the contactless card 1305 within the communication range of the client device 1310. As described above, the client device 1310 may be configured to receive a payload from the contactless card 1305. This payload may comprise a phone number, a comma, and a string of digits following the comma. Next, the client device 1310 and / or one or more client applications 1316 may initiate a call in response to receiving the payload, which may pass the number received from the contactless card 1305 to a service associated with one or more servers 1320. In an exemplary embodiment, if the notification is received in the form of a call, one or more servers 1320 may be configured to ignore the portion of the number passed to it that corresponds to the phone number. In an additional exemplary embodiment, the contactless card 1305 may be configured to adapt the form of the payload to include only the portion corresponding to the token following the comma upon receiving an NFC signal from the client device 1310 indicating that a call is already active.Next, this can rationalize the information received from the contactless card 1305 without the need to configure one or more servers 1320 that identify the portion of the payload corresponding to the telephone number and the portion of the payload corresponding to the token.

[0185] In some examples, the user may request a replacement contactless card 1305. This replacement card 1305 may comprise a card corresponding to any account belonging to a user having an entity that issued the contactless card to the user with the above functions. In an exemplary embodiment, this replacement card 1305 may comprise a contactless card corresponding to a user having any entity. In an exemplary embodiment, the user may initiate the request physically, via a web service, via an application on the phone, or by mailing the request to the location, or via any other suitable communication medium. In response to receiving the request, the entity may wish to verify the identity of the individual who requested the replacement card 1305. In response to the request, the service associated with one or more servers 1320 may send a notification to the user to confirm his or her identity. This may take any suitable form, as described above. In response to receiving this request, the user may gesture, such as tapping the contactless card 1305 against his or her client device 1310, so that the contactless card 1305 can enter the communication range of the client device 1310, thereby verifying his or her identity. The contactless card 1305 may comprise a payload configured to be received by the client device, processed to initiate a call, and transmit a series of numbers corresponding to the token via the call to a service associated with one or more servers. As described above, the client device 1310 may be configured to receive the payload from the contactless card 1305. This payload may comprise a phone number, a comma, and a string of numbers following the comma. Next, the client device 1310 may be able to initiate a call in response to receiving the payload, which may pass the number received from the contactless card 1305 to a service associated with one or more servers 1320. In an exemplary embodiment, if the notification is received in the form of a call, one or more servers 1320 may be configured to ignore the portion of the number passed to it corresponding to the phone number.In an additional exemplary embodiment, the contactless card 1305 may be configured to adapt the form of the payload to include only the portion corresponding to the token following the comma when receiving an NFC signal from the client device 1310 indicating that a call is already active. Next, this can rationalize the information received from the contactless card 1305 without the need to configure one or more servers 1320 to identify the portion of the payload corresponding to the phone number and the portion of the payload corresponding to the token.

[0186] In some examples, the user may wish to make a payment via the Automated Clearing House (ACH), request a wire transfer, or increase the debt limit on his or her debit account. In an exemplary embodiment, the user may initiate the request physically, via a web service, via an application on the phone, by mailing the request to a location, or via any other suitable communication medium. In response to receiving the request, the entity may wish to verify the identity of the individual who made the request. As described above, user authentication may occur through a call initiated by a user gesture such as tapping his or her contactless card 1305 on the client device 1310 so that the contactless card 1305 enters the communication range of the client device 1310.

[0187] In an exemplary embodiment, the user may wish to register his or her contactless card 1305, or other transaction card, with a payment system such as Apple Pay®, Samsung Pay®, or Android Pay®. As described above, user authentication may occur through a call initiated by a user gesture such as tapping his or her contactless card 1305 on the client device 1310 so that the contactless card 1305 enters the communication range of the client device 1310.

[0188] FIG. 14 shows a method 1400 for card activation according to an exemplary embodiment. Method 1400 may refer to the same or similar components as described above with respect to FIG. 13.

[0189] In block 1410, when a contactless card is gestured (including but not limited to one or more gestures) to establish communication with a client device, one or more applets of the contactless card may generate an NDEF file that can be read by the client device. In some examples, one or more gestures may include at least tapping, waving, or other gestures of the contactless card such that the contactless card enters the communication range of the client device. For example, tapping a contactless card on a client device such as a mobile device can initiate a call without using an application. The NDEF file may initiate one or more communications with various applications on the client device. As described below, one or more applets of the contactless card may dynamically generate information such as a phone number and an ID token or payload that may be attached to the phone number. In some examples, calls using the phone number may be made by phone to one or more servers, and the one or more servers may be configured to monitor the call and receive the decoded input. For example, the NDEF file can be read from the contactless card to the client device and switched to the phone system. This can respond to the call, obtain the automatic input of the number or payload, send it to the server, where it is decoded and authenticated, and then sent back to the phone system indicating success or failure of authentication with one or more fallback options. In some examples, the call is not IP-based. That is, it is not made using Voice-over-IP (VoIP) or other IP-based call mechanisms.

[0190] In block 1420, one or more processes can be utilized to activate the contactless card, each of which will be described separately. Exemplary processes include, but are not limited to, an initiated call.

[0191] For example, a link configured to initiate a call on a client device may be generated. The call may be initiated by the client device's default phone program, or in other examples, a different or specified phone program may be used. Following this link, a call may be initiated, then paused, and then an ID token may be provided. In this way, the contactless card may be configured to initiate a call. Examples of links are shown below. tel: / / 1234567890,,,1234567##

[0192] In some examples, the link may comprise one or more information elements. In some examples, the link may comprise a first information element, a second information element, and a third information element. For example, the first information element may precede the second element of information, and the second information element may precede the third information element.

[0193] In one embodiment, the first information element may comprise a phone number such as (123)456-7890. In some examples, the number may be US-based including the area code. In other examples, the number may not be US-based, for example, the number may further include a country code and may result in an international call. In some examples, one or more phone numbers may be generated dynamically, or one or more phone numbers may be retrieved from a pre-set list. The phone number element of the call may be hard-coded to call a card activation phone number or other service, such as tel: / / 1234567890.

[0194] In one embodiment, the second information element may comprise one or more characters such as one or more commas. In some examples, the one or more commas may be interpreted as one or more persistent pauses. For example, the duration of the pause may comprise a fixed period, such as one second. Thus, if a comma is interpreted as a one-second pause, including four commas (as in the example link above), a four-second pause may occur. In some examples, the number of commas may be of sufficient length for the telephone system to listen and respond. Thereby, as will be described below, the automated telephone system can respond to the call and ensure the time to wait for additional information elements.

[0195] In one embodiment, the link may include a third information element that may comprise one or more payloads. For example, a delivered payload such as 1234567## may be configured to authenticate a contactless card. In some examples, this numerical string may be passed to the telephone system in an encrypted format and decrypted with a key. If the decryption process fails, for example, due to the number being deleted for static or other reasons, this process may trigger one or more fallback options. For example, one option may include routing the call to an operator or customer service representative who can handle the call. In other examples, other options may include routing this process to another system, as will be described below, to allow entry of the card verification value of the contactless card.

[0196] In some examples, if an incorrect telephone number is used during the activation of a contactless card, this event may be flagged and stored in a database for analysis of potential suspects. As a result, an unregistered telephone number may indicate a high likelihood of improper conduct.

[0197] In some examples, values such as the CVV of a contactless card can be configured to activate the contactless card. Other examples that can provide better security than the CVV method can include leveraging one-time passwords (OTPs) generated by one or more card applets. This can be encrypted and decrypted by one or more servers to authenticate the contactless card.

[0198] In block 1430, in this case, the telephone system can analyze the payload from the call and pass it through one or more web applications for decryption. In some examples, the token can be encrypted via a secret / public key. For example, the secret key can be used to decrypt the data and can also be securely stored so that encryption (by the public key) is performed without the secret key. That is, since there is no need to transfer the secret key, it is not affected by eavesdropping by a third party. The number used to initiate the call can be checked and verified by one or more servers to determine the validity of the phone number. Therefore, decrypting the encrypted data and notifying or displaying that the contactless card has been activated in this way can include sending a text message or an email from one or more servers to the client device.

[0199] After the contactless card is successfully activated at block 1440 and the client device receives a notification indicating the activation, the contactless card may be instructed to disable the dynamic generation of data. In some examples, as described above, after the contactless card is activated via one of one or more processes, the user of the contactless card may optionally be directed to customer support or the contactless card may be used in a POS device or other system. For example, if the user interacts with a POS device using the activated card, the contactless card may be instructed to stop the dynamic generation of numbers. In some examples, this may require communication between applets such as a payment applet or a transaction applet that indicates to one or more other applets of the contactless card to stop generating phone numbers upon the next occurrence of one or more gestures by the contactless card. In this way, the dynamic generation function of the contactless card may be turned off or disabled in response to the successful activation of the contactless card.

[0200] As an example, the contactless card can be configured to cause, or the payload of the contactless card can be configured to cause, one or more of the following in a client device that receives the payload: (i) download an application compatible with the contactless card; (ii) transfer a balance or other amount between one or more accounts belonging to the user of the contactless card; (iii) reset a personal identification number (PIN) associated with the user, the contactless card, or an account associated with the user of the contactless card; (iv) link an account belonging to a user who is not an account to the entity that issued the contactless card; (v) approve or cause a transfer of balance from one or more accounts to an account associated with the contactless card or from an account; (vi) request a replacement of the card from the issuer of the contactless card; (vii) request or cause an Automated Clearing House (ACH) payment; (viii) approve or cause a wire transfer between the user corresponding to the contactless card or an account belonging to that user; (ix) perform user registration, registration verification, or authentication to permit connection of the account associated with the user or the contactless card to a payment service associated with a device including, but not limited to, Apple Pay®, Samsung Pay®, Android Pay®, Google Pay®, Venmo®, or Paypal®; (x) request an activity associated with the account, such as, for example, increasing the credit limit of a credit account, request a quick transaction (such as clearing a check), or dispute a transaction. Without limitation, one or more of the above can be achieved, for example, by using a contactless card configured with a specific NDEF message.

[0201] In some examples, the contactless card may communicate bi - directionally with the client device. For example, an application installed on the client device may use its functionality including but not limited to the NFC medium of the client device to send an NDEF or other message to the contactless card. This message may include, for example, information corresponding to the type of authentication request sent from a service associated with one or more servers. For example, a specific flag or payload received by the contactless card from the client device may modify a specific payload generated by the contactless card. In some examples, the contactless card may generate a payload tailored for a particular purpose shown, including but not limited to the transfer of balance by the user. As previously explained above, a call can be initiated through a user gesture such as tapping his or her contactless card to the client device to perform user authentication, including but not limited to the download of an application, balance transfer, PIN reset, account linking, card exchange, and payment processing.

[0202] In some examples, the present disclosure refers to a tap of a contactless card. However, it is understood that the present disclosure is not limited to taps and includes other gestures (e.g., waving the card or other movements).

[0203] Throughout the specification and claims, the following terms take at least the meanings explicitly associated herein, unless the context clearly dictates otherwise. 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 specified or made clear from the context to be singular.

[0204] In this description, many specific details are set forth. However, it should be understood that the implementation of the disclosed technology may 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 the understanding of this description. References to "some examples", "other examples", "an example", "examples", "various examples", "one embodiment", "embodiment", "some embodiments", "exemplary embodiments", "various embodiments", "one implementation", "implementation", "exemplary implementation", "various implementations", "some implementations", etc. indicate that the implementation of the disclosed technology so described may include a particular feature, structure, or characteristic, but not all implementations necessarily include the particular feature, structure, or characteristic. Further, repeated use of the phrases "in one example", "in one embodiment", or "in one implementation" does not necessarily refer to the same example, embodiment, or implementation, but may.

[0205] As used herein, unless otherwise specified, the use of the ordinal adjectives "first", "second", "third", etc. for describing a common object only indicates that different instances of the same object are being referred to, and it is not meant that the objects so described must be in a particular order in time, space, ranking, or otherwise.

[0206] Particular implementations of the disclosed technology have been described in connection with what are presently considered to be the most practical and various implementations, but the disclosed technology should not be limited to the disclosed implementations, but rather is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Specific terms are used herein, but they are used only in a general and descriptive sense and not for purposes of limitation.

[0207] This written description discloses specific implementations of the disclosed technology, including the best mode, using examples, and enables those skilled in the art to practice specific implementations of the disclosed technology, including the making and using of any device or system and the performing of any incorporated method. The patentable scope of specific implementations of the disclosed technology is defined by the claims and may 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 that differ from the literal language of the claims only in a non-substantial way.

Claims

1. A contactless card, comprising a processor, and a memory containing one or more data, wherein the one or more data includes a telephone number associated with a server and one or more unique identifiers, wherein the processor is configured to generate an activation link based on the one or more data and transmit the activation link to a client device when the contactless card enters a communication range, wherein the activation link includes the telephone number and one or more encrypted payloads, wherein the activation link is configured to initiate a call to the telephone number via the client device and facilitate transmission of the one or more encrypted payloads to the server for verification, A contactless card.

2. The activation link further includes one or more characters following the telephone number, and the one or more encrypted payloads follow the one or more characters, The contactless card according to claim 1.

3. The contactless card according to claim 2, wherein the one or more characters include one or more holds associated with the call.

4. The contactless card according to claim 2, wherein the one or more encrypted payloads include instructions for downloading an application compatible with the contactless card.

5. The contactless card according to claim 2, wherein the one or more encrypted payloads include: (i) transferring a balance or other amount between one or more accounts associated with a user of the contactless card; (ii) resetting a personal identification number (PIN) associated with the user, the contactless card, or an account associated with the user; (iii) linking an account not associated with the user to the entity that issued the contactless card; (iv) authorizing or causing a transfer of balance to or from one or more accounts associated with the contactless card or an account associated with the contactless card; and (v) requesting a card replacement from the entity that issued the contactless card.

6. The one or more encrypted payloads include at least one selected from the group consisting of: (i) requesting or causing an Automated Clearing House (ACH) payment; (ii) authorizing or causing a wire transfer from or to an account associated with the user of the contactless card; (iii) registering, validating, or authenticating the user to permit connecting an account or contactless card associated with the user to a payment service associated with the device; and (iv) requesting an account activity including at least one selected from the group consisting of increasing a credit account debt limit, requesting an expedited transaction, and requesting to dispute a transaction. The contactless card according to claim 2.

7. The one or more unique identifiers match an identification token, The processor is further configured to transmit the identification token with the data. The contactless card according to claim 1.

8. The processor is configured to retrieve the phone number from a pre-set list. The contactless card according to claim 1.

9. A method for activating a contactless card to be usable in a transaction, the method comprising: generating, by a processor of the contactless card, an activation link including a phone number associated with a server, one or more comma characters following the phone number, and one or more encrypted payloads when the contactless card enters a communication range of a client device; when the client device receives the activation link, initiating a call to the server; when a connection with the server is established, transmitting, by the processor, the activation link to the server for verification; when the one or more encrypted payloads are verified by the server, transmitting, by the client device, one or more instructions to the contactless card; A method comprising.

10. The one or more instructions transmitted by the server indicate activation of the contactless card. The method according to claim 9.

11. The method comprises The method according to claim 9, further comprising the server decrypting the one or more encrypted payloads using one or more keys.

12. The method further comprises the server triggering one or more processes based on one or more parameters associated with the contactless card when decryption of the one or more encrypted payloads fails, the method according to claim 11.

13. The one or more processes include at least one selected from the group consisting of routing a call to a desired recipient and prompting for input of one or more parameters associated with the contactless card, the method according to claim 12.

14. The one or more encrypted payloads include instructions for downloading an application compatible with the contactless card, the method according to claim 9.

15. The method according to claim 9, further comprising the processor retrieving the telephone number from a pre-set list.

16. A server, comprising a processor and a memory, wherein the processor is configured to receive an activation link from a contactless card, the activation link is received via a call to a telephone number associated with the server, the activation link includes one or more encrypted payloads associated with one or more data elements stored on the contactless card, wherein the processor verifies the one or more encrypted payloads, and is configured to activate the contactless card after verifying the one or more encrypted payloads. Server.

17. The one or more encrypted payloads include the one or more unique identifiers stored in the memory of the contactless card, the contactless card according to claim 1.

18. The step of the processor receiving an instruction to stop generating the activation link, and in response to the instruction, the step of the processor stopping generating the activation link, further included in the method according to claim 9. The server according to claim 16, further comprising: the server decrypting the one or more encrypted payloads using one or more keys. The server according to claim 19, further comprising: when decryption of the one or more encrypted payloads fails, the server triggering one or more processes based on one or more parameters associated with the contactless card.

Images