System and method for reissuing contactless cards

Abstract

To provide systems and methods for reissuing or otherwise altering information stored in a contactless card.SOLUTION: A contactless card includes a chip that stores encrypted authentication information, including a primary account number (PAN) that identifies the card. The chip includes: a payment / transaction applet for making payments with the card and managing the PAN; and a communication / authentication applet interacting with an outside application and serving as a bridge to the payment / transaction applet. A rewrite of the PAN is triggered by issuing a write command to the communication / authentication applet, or by interacting with the chip in a predetermined manner (e.g., tapping the card on an interactable element a predetermined number of times).SELECTED DRAWING: Figure 6B

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 16 / 731,178, filed on December 31, 2019, which is a continuation - in - part of U.S. Patent Application No. 16 / 205,119, filed on November 29, 2 determined to be a security risk. The disclosure of each of the prior applications is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates to authentication and authorization, and more specifically, to systems and methods for reissuing or otherwise modifying information stored on contactless cards.

Background Art

[0003] Data breaches that expose customers' payment information are becoming increasingly common and widespread, with specific breaches revealing millions of credit card numbers. These data breaches can occur when malicious actors gain access to computing systems associated with major department stores, banks, or credit card issuing companies and steal large amounts of payment data (e.g., credit card numbers, expiration dates, etc.). [[ID=[]]

[0004] Conventionally, credit card issuers have been able to respond to such breaches by reissuing the affected cards. This involves assigning a new credit card number to the user's account, generating a new physical card with the new number embossed, writing a new magnetic stripe, and mailing the card. If the breach is widespread (involving a large number of cards), it can take weeks to months for the user to receive the new card. During this time, the account may not be usable for making payments because the card number may have been invalidated at the time the breach was discovered (to prevent unauthorized access to the account). Clearly, this can be a problem for customers.

[0005] It should be noted that there seems to be an incomplete or incorrect part in the original text at line 7 where the description about "2 determined to be a security risk" is rather unclear. I translated it as best as possible based on the overall context. You may want to check and correct that part for a more accurate translation. The reissuance process can also be costly from the card issuer's perspective, often absorbing the costs of generating and mailing new cards. Depending on the quality of the card stock, creating a new card can cost anywhere from $2 to $30. If cards need to be reissued quickly, additional processing costs can be as high as $10 per card. If millions of card numbers are compromised, the resulting reissuance costs could reach tens of millions of dollars. [Brief explanation of the drawing]

[0006] [Figure 1A] This shows an environment suitable for use in an exemplary embodiment. [Figure 1B] This shows an example of a contactless card with a physical token. [Figure 1C] This shows the structure of an exemplary physical token. [Figure 2A] This shows an example of the interface for a mobile application associated with the owner of a contactless card. [Figure 2B] This shows an example of the interface when a physical token is read by a reader on the owner's mobile device. [Figure 2C] This shows an example of data exchange between a contactless card and a client device. [Figure 2D] This shows an exemplary data structure suitable for use in exemplary embodiments. [Figure 3] This is a flowchart showing the key operation according to an exemplary embodiment. [Figure 4] This is a diagram of a key system according to an exemplary embodiment. [Figure 5] This is a flowchart illustrating a method for generating ciphertext according to an exemplary embodiment. [Figure 6A] This is a flowchart illustrating the key diversification process according to an exemplary embodiment. [Figure 6B] This is a data flow diagram illustrating the exchange of communications in an exemplary embodiment. [Figure 6C]A flowchart illustrating the card-side logic for changing the identifier associated with a contactless card. [Figure 7] This illustrates an exemplary computing system suitable for use in exemplary embodiments. [Figure 8] This shows an exemplary network environment suitable for use in exemplary embodiments. [Modes for carrying out the invention]

[0007] Exemplary embodiments provide a technique for securely reissuing or otherwise modifying information stored on a contactless card based on a remote command. Thus, the number associated with a card can be quickly changed so that the card can continue to be used with the new number. If the card has a number printed or embossed on its surface, the printed number (and / or the number stored on the magnetic stripe) may not match the number stored on the contactless chip. Nevertheless, this card can still be used for contactless payments until a new card with the new number is issued. In some embodiments, the card may include an electronic ink (e-ink) display that shows the number. In this case, when the number stored on the card's contactless chip is updated, the e-ink display may also be updated.

[0008] The chip on a card may contain one or more applets that are activated under specific circumstances. For example, when making a payment with a card, a payment applet may be activated and provide the card number to the requesting device. To use the card with a new number, this payment applet may need to be updated, but for security reasons, the payment applet may be restricted from direct communication with external sources. For this purpose, the chip may contain a second encryption and authentication applet responsible for communicating card information with an external source. The second applet may perform authentication and ensure that the information transmitted from the payment applet is done in a secure manner (e.g., using encryption). As will be described in more detail below, the second applet may also be responsible for performing verification functions (e.g., verifying counters stored on the card). According to an exemplary embodiment, this second applet may be designed to act as a bridge between the external source and the payment applet, and the number on the payment applet may be rewritten based on secure internal (to the chip) communication.

[0009] In some cases, a second applet may be directly instructed to overwrite the card number with a new number. For example, a mobile device running the Android® operating system may issue a Near Field Communication (NFC) write command to a second applet, triggering the second applet to issue a rewrite command to the payment applet. However, some devices may not support such communication (Apple's iOS® is one such example). Therefore, the second applet may also, or instead, be configured to recognize a predefined pattern that causes a rewrite command to be issued. For example, a user may tap a contactless card five times on an NFC reader within one minute. Since tapping the card on the NFC reader triggers the authentication and encryption operations of the second applet, the second applet may be pre-configured to recognize this predefined pattern and issue a rewrite command accordingly.

[0010] In various embodiments, a card may have the ability to limit the number of rewrites that can be performed (e.g., over the card's lifetime or over a specific period). To this end, the card may maintain a counter of rewrite counts and may also store a value representing the maximum number of rewrites allowed. If a number of rewrite requests are received and the total number of requests (past and present) exceeds the stored maximum value, the rewrites may be canceled.

[0011] The following description of embodiments provides non-limiting representative examples that refer to figures in particular to illustrate features and teachings of different aspects of the invention. It should be recognized that the embodiments described may be implemented separately or in combination with other embodiments from the description of embodiments. The description of embodiments should facilitate understanding of the invention to the extent that other embodiments not specifically covered but within the scope of the knowledge of those skilled in the art, as read from the description of embodiments, are understood to be consistent with the application of the invention.

[0012] Figure 1A shows a data transmission environment 100 according to an exemplary embodiment. As will be further described below, the system 100 may include a contactless card 130, a client device 104, a network 114, and a server 116 maintained by the provider of the contactless card 130. While Figure 1A shows a particular configuration of components, those skilled in the art will understand that other configurations, including more or fewer components, or components in other configurations, may be used.

[0013] Environment 100 may include one or more contactless cards 130, which will be further described below with reference to Figure 1B. In some examples, the contactless cards 130 may communicate wirelessly with a client device 104, for example, through NFC communication. The contactless cards may include a contactless chip (see Figure 1C). The contactless chip may maintain a copy of the primary account number (PAN) associated with the card 130, which can be read by a reader (such as an NFC reader 110).

[0014] The environment 100 can include a client device 104 that 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, network appliance, personal computer (PC), workstation, mobile device, telephone, handheld PC, personal digital assistant (PDA), thin client, fat client, Internet browser, or other communication device including, but not limited to, these. The client device 104 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, and / or other smartphones or similar wearable mobile devices.

[0015] The client device 104 and / or the contactless card 130 can be associated with a user 102 who can be the owner of the contactless card. The user 102 can define qualification information for accessing a mobile application on the client device 104, which can be an application associated with the service provider of the contactless card.

[0016] In various examples according to the present disclosure, the client device 104 of the environment 100 can execute one or more applications such as a software application. The software application can enable network communication with one or more components of the environment 100 and can send and / or receive data. Among other computer-executable logic, the client device 104 can include client-side reissuance logic 112 (such as the logic shown in more detail in relation to FIG. 6B).

[0017] Client device 104 can communicate with one or more servers 116 via one or more networks 114. For example, client device 104 can operate as a front end to card provider server 116, which is responsible for maintaining the security of contactless card 130. In some embodiments, card provider server 116 can also approve transactions executed via card 130. Client device 104 can send one or more requests to server 116, for example, from a mobile device application executed on client device 104. Similarly, server 116 can communicate with client device 104 to initiate a card reissue process on client device 104, such as when a data breach occurs.

[0018] To that end, server 116 can instruct client device 104 to change the PAN associated with user 102's card 130. Client device 104 can receive the instruction and notify user 102 that the card number has been reissued (e.g., via a display as shown in FIGS. 2A-2B). Client device 104 can activate one or more applets stored on card 130 by means of a fast command (e.g., an NFC write command) or by requesting that user 102 tap card 130 against NFC reader 110 in a predetermined pattern (e.g., a predetermined number of times, a predetermined speed over a certain period of time, a predetermined pattern, etc.).

[0019] Instructions to change the PAN can be sent individually from server 116 (e.g., if a single user 102's card 130 has been compromised) or the reissue instruction can be broadcast to a group of recipients (which may occur in the event of a large-scale data breach).

[0020] In some embodiments, client 104 (or other device instructing card 130 to change the PAN) may, in coordination with server 116, issue change instructions to card 130. For example, server 116 may provide a new PAN to be used on card 130, which client 104 can communicate with a communication logic / applet on card 130. In other examples, the payment logic / applet on card 130 may be pre-programmed with multiple PANs, and server 116 may identify which PAN to use (or, if the PANs are located in a list in the card's memory, server 116 may instruct the payment logic / applet to select the nth PAN in the list, skipping a certain number of options). In other examples, the payment logic / applet may derive a new PAN from an old PAN (or another identifier stored on the card, such as an identifier associated with user 102 or a user account at a financial institution), and server 116 may provide instructions on how to derive the new PAN or provide a seed number used to generate the new PAN.

[0021] If client device 104 can issue a write request directly to card 130, the write request may include information received from the server (e.g., the new PAN, the number of PANs in the list to skip, a generation technique for deriving the new PAN, or a seed for the new PAN). If client device 104 cannot issue such a write request, card 130 can still coordinate with server 116, albeit in a potentially more limited way. For example, if the communication logic / applet on card 130 is configured to recognize a given tapping pattern as an instruction to change a PAN, as described above, different patterns may be associated with different change instructions. For example, if a user taps card 130 five times on NFC reader 110 within one minute, this may be interpreted as an instruction to move to the next PAN stored in the list. On the other hand, if a user taps card 130 only four times on NFC reader 110 within one minute, this may be interpreted as an instruction to skip two PANs in the list ahead. Instructions from server 116 to client device 104 may identify a specific pattern to be used, and client device 104 may display the appropriate instructions on the user interface. If multiple different patterns are programmed into the communication logic / applet on card 130, device 104 may prompt the user to confirm the pattern to ensure the correct pattern is being used (for example, by prompting the user to tap a predefined pattern, wait a while, and then prompting the user to tap the same predefined pattern again to confirm the change).

[0022] When the PAN is changed, the communication logic / applet on card 130 may report success to server 116. Upon success, the selected new PAN may be identified (directly by reporting the PAN or an encrypted version of the PAN, or indirectly by sending a hash of the PAN or a subset of the PAN). If the updated PAN does not match the PAN expected by server 116, the PAN may be invalidated and the process may be repeated. Alternatively, server 116 may simply accept the PAN as reported by card 130.

[0023] In some examples, server 116 may include one or more processors coupled to memory. Server 116 may be configured as a central system, server, or platform for controlling and retrieving various data at different times to perform multiple workflow actions.

[0024] Figure 1B shows one or more contactless cards 130, which may include payment cards such as credit cards, debit cards, or gift cards issued by a service provider 132, as indicated on the front or back of the card 130. In some examples, the contactless card 130 may include an identification card unrelated to a payment card, but is not limited to this. In some examples, the payment card may be a dual-interface contactless payment card. The contactless card 130 may include a substrate 134 which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 130 may have physical properties conforming to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it is understood that the contactless card 130 relating to this disclosure may have different characteristics, and this disclosure does not require that the contactless card be implemented as a payment card.

[0025] The contactless card 130 may also include identification information 136 displayed on the front and / or back of the card. In some embodiments, the identification information 136 may be printed or embossed directly onto the card. Optionally, an e-ink display 149 (or other type of rewritable display using technology such as liquid crystal diodes) may be provided to display some or all of the identification information 136. For example, the e-ink display 149 may display a card number associated with the card. The e-ink display 149 may be powered by a magnetic field, such as a magnetic field emanating from a client device 104. An antenna on the card 130 (e.g., an antenna on the contact pad 138 described below) may collect power from the magnetic field and power the e-ink display 149 when the card 130 is in close proximity to the client device 104. This allows the e-ink display 149 to change to match a new number provisioned on the applet on the card 130 by the client device 104, as described herein.

[0026] The contactless card 130 may further include a contact pad 138. The contact pad 138 may be configured to establish contact with a user device or other communication device such as a smartphone, laptop, desktop, or tablet computer. The contactless card 130 may also include processing circuits, antennas, and other components not shown in Figure 1C. These components may be located behind the contact pad 138 or elsewhere on the substrate 134. The contactless card 130 may also include a magnetic strip or tape that may be located on the back of the card (not shown in Figure 1B).

[0027] As shown in Figure 1C, the contact pad 138 in Figure 1B may include a processing circuit 140 for storing and processing information, including a microprocessor 142 and memory 144. It is understood that the processing circuit 140 may include additional components, such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamper-proof hardware, as necessary to perform the functions described herein.

[0028] Memory 144 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 130 may include one or more of these memories. Read-only memory is programmable at the factory as read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read many times. Write-once / read-multiple memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten but can be read many times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read many times.

[0029] Memory 144 may be configured to store one or more applets 146, one or more counters 108, and a customer identifier 148. One or more applets 146 may comprise one or more software applications configured to run on one or more contactless cards, such as Java Card applets. However, it is understood that applet 146 is not limited to Java Card applets, but could instead be any software application capable of running on a contactless card or other device with limited memory. One or more counters 108 may comprise numeric counters sufficient to store integers. The customer identifier 148 may comprise a unique alphanumeric identifier assigned to a user of a contactless card 130, the identifier being able to distinguish a user of a contactless card from other contactless card users. In some examples, the customer identifier 148 may identify both the customer and the account assigned to that customer, and further, the contactless card associated with the customer's account.

[0030] Applet 146 may include a payment applet configured to perform a payment transaction with card 130. The payment applet is responsible for, or may utilize, the card's primary account number (PAN), which may be communicated from the card as part of the transaction. Applet 146 may further include authentication and / or encryption applets that are invoked when an external source (such as a client device 104, a POS terminal, or an ATM) attempts to establish communication with card 130 (for example, if the contact pad 138 is located to or near a reader such as an NFC reader 110). The payment applet cannot communicate directly with external sources (i.e., sources outside of processing circuit 140), but can securely communicate with other applets on processing circuit 140, such as authentication and encryption applets. Information may be passed from the payment applet to the authentication and encryption applet for off-card communication.

[0031] Optionally, a payment applet may be preloaded with predefined PANs (e.g., when issuing a card). One of these is designated as the currently active PAN, and the rest are kept as backups. When the applet is requested to issue a new PAN, it may select the next PAN from the list and designate it as the active PAN. Alternatively, the applet may generate a new PAN randomly according to a PAN generation rule, or generate a new PAN based on the previous PAN.

[0032] While the processor and memory elements of the exemplary embodiments described above have been described with reference to the contact pads, the disclosure is not limited thereto. It is understood that these elements may be implemented outside of the pads 138, completely separate from the pads 138, or as additional elements in addition to the processor 142 and memory 144 elements located within the contact pads 138.

[0033] In some examples, the contactless card 130 may include one or more antennas 150. These antennas 150 may be positioned within the contactless card 130, around the processing circuit 140 of the contact pads 138. For example, one or more antennas 150 may be integrated with the processing circuit 140, or they may be used in conjunction with an external booster coil. In other examples, one or more antennas 150 may be located outside the contact pads 138 and the processing circuit 142.

[0034] In one embodiment, the coil of the contactless card 130 can function as the secondary side of an air-core transformer. The terminal can communicate with the contactless card 130 by blocking power or amplitude modulation. The contactless card 130 can infer data transmitted from the terminal using the gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 130 can revert the communication by switching the load on the contactless card's coil or by load modulation. Load modulation can be detected in the terminal's coil by interference.

[0035] As described above, the contactless card 130 may be built on a software platform capable of running on other devices with limited memory, such as smart cards or Java cards, and one or more applications or applets may be securely executed on it. Applets can be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in a variety of mobile application-based use cases. The applet can be configured to respond to one or more requests, such as Near Field Radio Data Interchange (NDEF) 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.

[0036] As described above, an exemplary transaction can validate a transaction requested to an account associated with a contactless card via logic 112 executed on the client device 104. Figures 2A and 2B show exemplary interfaces that may be presented on the client device 104 in response to the logic.

[0037] Figure 2A shows the initial interface 200 of an application associated with a card (for example, an application provided by the card provider). This may be displayed to the client device 104 when the client device 104 receives instructions from the server 116 to reissue the card or to reprovision or modify the information stored on the card. The interface 200 includes a message area 202 that displays information regarding the reissue of card information. This message area 202 may, for example, explain that the user's card has been reissued, why the reissue was made, and the next steps the user needs to take to modify the card information.

[0038] Interface 200 may further include an interactive element 204. To modify the information stored on the card, the user may optionally first be prompted to select the interactive element 204 and confirm that the user wants to reissue the card number (to prevent the user from accidentally overwriting the card information by placing the card near an NFC reader).

[0039] Once an interactive element is selected, the user can rewrite the PAN or other information stored on the card 130 by bringing the contact pad 138 of the card's chip close to the NFC reader of the device 104, as shown in Figure 2B. When the card is close to the NFC reader and the applet on the card confirms that the card's PAN has been successfully changed, a confirmation message 206 indicating that the card's information has been successfully rewritten may be displayed.

[0040] As an alternative to the procedure shown in Figures 2A and 2B, the user may be prompted to tap a card with a predetermined pattern on the NFC reader of the client device (in interface 200). The authentication and encryption applet may register the predetermined pattern.

[0041] Figures 2A and 2B show a card 130 that is rewritten when brought close to a mobile client device 104, but the card is also intended to be rewritten by an automated teller machine, a point-of-sale terminal, or any other device having a suitable transmitter (e.g., an NFC transmitter) for communicating with a contact pad 138.

[0042] As shown in Figure 2B, when a new PAN is written to the chip of a contactless card, the new card number may not match the number printed or embossed on the card, or the information stored in the card's magnetic stripe. In this case, it is desirable to create and send a new physical card to the user so that all of the card's multiple payment options are available. Nevertheless, while the card is in the user's possession, the card's contactless payment functionality can still be used with the information stored in the chip. As mentioned above, if the card includes an e-ink display, the e-ink display may be updated when the PAN is rewritten to reflect the new card number. In this case, there is no need to reissue a physical card, especially if the card does not include a magnetic stripe, or if the user primarily uses the card for contactless payments.

[0043] Figure 2C is a timing diagram showing an exemplary sequence for providing authenticated access according to one or more embodiments of the present disclosure. The system may include a contactless card 130 and a client device 104 which may include an application (which may include a logical 112) and a processor.

[0044] In step 202, the application communicates with the contactless card 130 (for example, after being brought close to the contactless card 130). The communication between the application and the contactless card 130 may include the contactless card 130 being close enough to the card reader (not shown) of the client device 104 to enable NFC data transfer between the application and the contactless card 130.

[0045] In step 204, after communication is established between the client device 104 and the contactless card 130, the contactless card 130 generates a Message Authentication Code (MAC) ciphertext. In some examples, this may occur when the contactless card 130 is read by an application hosting a logical 112. In particular, this may occur during readings such as NFC reading of Near Field Radio Data Exchange (NDEF) tags, which may be created according to the NFC Data Exchange format. For example, a reader such as a logical 112 may send a message, such as an applet selection message, using the applet ID of an NDEF generation applet. Once the selection is confirmed, a sequence of selected file messages followed by read file messages may be sent. For example, the sequence may include "Selected Function File," "Read Function File," and "Selected NDEF File." At this point, a counter value maintained by the contactless card 130 may be updated or incremented, followed by "Read NDEF File." At this point, a message may be generated that may contain a header and a shared secret. Next, a session key may be generated. The MAC ciphertext may be constructed from the message. This may include a header and a shared secret. Next, the MAC ciphertext is concatenated with one or more blocks of random data, and the MAC ciphertext and random numbers (RND) may be encrypted with the session key. Then, the ciphertext and header may be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to the "Read NDEF File" message).

[0046] In some cases, the MAC ciphertext may be transmitted as an NDEF tag, while in other cases, the MAC ciphertext may be included with a uniform resource indicator (e.g., as a formatted string).

[0047] In some examples, logic 112 may be configured to send a request to contactless card 130, the request comprising instructions for generating a MAC ciphertext.

[0048] In step 206, the contactless card 130 transmits the MAC ciphertext to logical 112. In some examples, the transmission of the MAC ciphertext is performed via NFC, but this disclosure is not limited thereto. In other examples, this communication may be performed via Bluetooth®, Wi-Fi, or other wireless data communication means.

[0049] In step 208, logic 112 communicates the MAC ciphertext to the processor.

[0050] In step 210, the processor verifies the MAC ciphertext according to instructions from logic 112. For example, the MAC ciphertext may be verified as described below.

[0051] In some cases, MAC ciphertext verification may be performed by a device other than the client device 104, such as a server 116 communicating data with the client device 104. For example, a processor may output a MAC ciphertext for transmission to server 116, which can then verify the MAC ciphertext.

[0052] In some cases, MAC ciphertext can function as a digital signature for verification purposes. To perform this verification, public-key asymmetric algorithms, such as the Digital Signature Algorithm and the RSA algorithm, or other digital signature algorithms such as zero-knowledge protocols, may be used.

[0053] Figure 2D shows an exemplary technique for generating a protected message 230 according to an exemplary embodiment.

[0054] Message 230 may be configured to deliver information or content from the sender to the recipient. This information or content may be represented by message plaintext 234 (however, the content may optionally be encrypted).

[0055] The message plaintext 234 may be combined with a shared secret 232. The shared secret 232 may be a random number known to both the sender and the receiver. For example, if the message plaintext 234 relates to the authentication action of the contactless card described above, the process of setting up or initializing the card may include sharing a random number between the chip on the card and the transaction verification server. In one embodiment, the random number may be a 32-bit random number. Alternatively, a communication session may be set up by the sender and the receiver. The process of setting up a communication session may include sharing a random number between the sender and the receiver, which may be used as the shared secret 232.

[0056] The message plaintext 234 and the shared secret 232 can be combined in various ways. In one embodiment, the message plaintext 234 can be encoded in a format that can be multiplied by the shared secret 232. The resulting product can be applied to the MAC algorithm.

[0057] When a recipient (e.g., a receiving server) retrieves the combined MAC data, the recipient can refer to that version of shared secret 232 and reverse the process used to combine the MAC data with the shared secret (e.g., split the combined MAC data and shared secret 232 to retrieve the original MAC data).

[0058] Those skilled in the art will recognize that other techniques exist for combining two different instances of data, any of which may be suitable for use in the exemplary embodiments.

[0059] After the message plaintext 234 and the shared secret 232 are combined, they can be provided to a MAC algorithm 236. The MAC algorithm 236 can be any suitable MAC algorithm from among many others, such as the Data Authentication Algorithm (DAA), the Cipher Block Chained Message Authentication Code (CBC-MAC), the Galois Message Authentication Code (GMAC), and the Hash Message Authentication Code (HMAC).

[0060] The MAC algorithm 236 may operate using a key. In an exemplary embodiment, this key may be a first diversified key 250 created using a diversification algorithm 248. The diversification algorithm may operate on a counter 108 received from a contactless card and a first master key 244 (described in more detail below) stored on the contactless card to generate the first diversified key 250. Using the first diversified key 250 and the combined shared secret / plaintext, the MAC algorithm 236 may generate a MAC output 238.

[0061] MAC output 238 may optionally be encrypted by encryption algorithm 240 to generate an encrypted MAC 242. Encryption algorithm 240 can be any suitable encryption algorithm from among many others, such as Data Encryption Standard (DES), Triple DES (3DES), Advanced Encryption Standard (AES), and RSA.

[0062] In some embodiments, the MAC output 238 may be truncated and / or combined with random data 254. For example, in one embodiment, the beginning of the MAC output 238 may be discarded so that only the last 8 bytes are retained (e.g.). The remainder of the MAC output 238 may be combined with randomly generated 8 bytes of data 254. When the receiver receives message 300, the receiver may decrypt the encrypted MAC 242 and discard the random data. The receiver may calculate a version of their own MAC and compare the last 8 bytes of the MAC they generated with the remaining data from the encrypted MAC 242 received as part of message 230, as described below.

[0063] The encryption algorithm 240 may operate using a key. In an exemplary embodiment, this key may be a second diversified key 252 created using a diversification algorithm 248. The diversification algorithm may operate on a counter 108 received from a contactless card and a second master key 246 (described in more detail below) stored on the contactless card to generate the second diversified key 252. Using the second diversified key 252 and the MAC output 238, the encryption algorithm 240 may generate an encrypted MAC 232, which may be included in the header of the message 230.

[0064] The encrypted MAC232 may be transmitted along with the message plaintext 234. The counter value 108 may optionally be transmitted as part of the message plaintext 234 and may be referenced by the recipient (e.g., a server) when authenticating the message. The shared secret 232 is not transmitted directly as part of the message.

[0065] Figure 3 is a flowchart of key operation 300 according to an exemplary embodiment. As shown in Figure 3, in block 310, 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) per card. In some examples, the Bank Identifier Number may consist of one number or a combination of one or more numbers, such as an account number or an unpredictable number provided by one or more servers, and may be used to generate and / or diversify session keys. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.

[0066] In block 320, the counter can be used as diversification data because it changes with each use and provides a different session key each time, in contrast to the master key derivation, which generates one unique set of keys per card. In some examples, it is desirable to use a 4-byte scheme for both operations. Thus, in block 320, two session keys may be created for each transaction from the UDK: one session key from the AUTKEY and one session key from the ENCKEY. On the card, for the MAC key (i.e., the session key created from the AUTKEY), the lower two bytes of the OTP counter can be used for diversification. For the ENC key (i.e., the session key created from the ENCKEY), the entire length of the OTP counter can be used for the ENC key.

[0067] In block 330, the MAC key may be used to prepare the MAC ciphertext, and the ENC key may be used to encrypt the ciphertext. For example, the ciphertext may be prepared using the MAC session key and then encrypted with the ENC key before sending the result to one or more servers.

[0068] In block 340, 2-byte divergence is directly supported by the MAC authentication function of the payment HSM, simplifying MAC verification and processing. Decryption of the ciphertext is performed before MAC verification. Since the session key is derived independently on 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.

[0069] For contactless cards, another unique identifier may be derived that is associated with the application's primary account number (PAN) and the PAN sequence number encoded on the card. Key diversification can be configured to receive the identifier as 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 consist of a first key and a second key. The first key may contain an authentication master key (card ciphertext generation / authentication key - Card-Key-Auth), which can be further diversified to create a MAC session key used when generating and verifying MAC ciphertext. The second key may contain an encryption master key (card data encryption key - Card-Key-DEK), which 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 may be created by diversifying the issuer master key by combining them with the card's unique ID number (pUID) and the payment applet's PAN sequence number (PSN). The pUID may consist of a 16-digit number. As explained above, a pUID can consist of a 16-digit BCD coded number. In some examples, a pUID can consist of a 14-digit number.

[0070] In some cases, the EMV session key derivation method is 2 ∧ Because it can be wrapped with 16, counters such as full 32-bit counters can be added to the initialization array of the diversification method.

[0071] In other examples, such as credit cards, numbers such as account numbers, or unpredictable numbers provided by one or more servers, can be used to generate and / or diversify session keys.

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

[0073] With regard to master key management, two issuer master keys 405, 410 may be required for each part of a portfolio in which one or more applets are issued. For example, the first master key 405 may contain the issuer ciphertext generation / authentication key (Iss-Key-Auth), and the second master key 410 may contain the issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 405, 410 are diversified into card master keys 425, 430, which are unique for each card. In some examples, a network profile record ID (pNPR) 415 and a derived key index (pDKI) 420 can be used as back-office data to identify the issuer master keys 405, 410 to be used in the encryption process for authentication. The system performing authentication can be configured to look up the values ​​of the pNPR 415 and pDKI 420 of the contactless card at the time of authentication.

[0074] In some examples, to enhance the security of the solution, a session key (such as a unique key per session) can be obtained, but as described above, instead of using a master key, a unique key and counter derived from the card can be used as diversification data. For example, a different key may be used each time the card is used in operation to generate the Message Authentication Code (MAC) and perform encryption. Regarding the generation of session keys, the key used to generate ciphertext and encrypt data within one or more applets may be a session key based on the card's unique key (Card-Key-Auth425 and Card-Key-Dek430). The session key (Auth-Session-Key435 and DEK-Session-Key440) is generated by one or more applets and derived using the Application Transaction Counter (pATC)445 in one or more algorithms. Only the lower two bytes of the four-byte pATC445 are used to fit the data to one or more algorithms. In some examples, a 4-byte session key derivation method may consist of: 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 contains a 3DES ECB and MK may contain a card-unique derived master key.

[0075] As described herein, one or more MAC session keys can be derived using the lower two bytes of the pATC445 counter. Each time the contactless card is tapped, the pATC445 is configured to be updated, and the card master keys Card-Key-AUTH425 and Card-Key-DEK430 are further diversified into session keys Aut-Session-Key435 and DEK-Session-Key440. The pATC445 can be initialized to zero during personalization or applet initialization. In some examples, the pATC counter 445 may be initialized during or before personalization and may be configured to increment by 1 with each NDEF read.

[0076] Furthermore, each card update is unique, assigned either by personalization or by an algorithm using a pUID or other identifying information. For example, odd-numbered cards can be incremented or decremented by 2, and even-numbered cards can be incremented or decremented by 5. In some examples, updates can also differ with sequential reads, with a single card being incremented sequentially in a repeating pattern of 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from a unique identifier. This can make it difficult for a replay attacker to generalize from a small number of card instances.

[0077] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may contain only the authentication data and an 8-byte random number followed by the MAC of the authentication data. In some examples, the random number precedes ciphertext A and may be the length of one block. In other examples, there may be no limit to the length of the random number. In further examples, the total data (i.e., random number and ciphertext) may be a multiple of the block size. In these examples, an additional 8-byte block may be added to match the block generated by the MAC algorithm. In other examples, if the algorithm employed uses 16-byte blocks, a multiple of that block size may be used, or the output may be automatically or manually padded to a multiple of that block size.

[0078] MAC can be performed using a function key (AUT-Session-Key) 435. The data specified in the ciphertext can be processed using 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 may be the session key AUT-Session-Key 435, as described above. As described above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As described below, AUT-Session-Key 435 may be used for MAC data 450, and the resulting data or ciphertext A455 and random number RND can be encrypted using DEK-Session-Key 440 to create ciphertext B or output 460 sent in the message.

[0079] In some examples, one or more HSM commands may be processed for decryption so that the last 16 (binary, 32hex) bytes consist of 3DES symmetric encryption using CBC mode with a random zero IV followed by MAC authentication data. The key used for this encryption may consist of a session key DEK-Session-Key440 derived from Card-Key-DEK430. In this case, the ATC value of the session key derivation is the least significant byte of counter pATC445.

[0080] The following format represents an exemplary embodiment of the binary version. In some examples, the first byte may be set to the ASCII character "A". [Table 1]

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

[0082] The UID field of the received message can be extracted, and from the master keys Iss-Key-AUTH405 and Iss-Key-DEK410, the card master keys (Card-Key-Auth425 and Card-Key-DEK430) for that particular card can be derived. Using the card master keys (Card-Key-Auth425 and Card-Key-DEK430), and the counter (pATC) field of the received message, the session keys (Aut-Session-Key435 and DEK-Session-Key440) for that particular card can be derived. Ciphertext B460 can be decrypted using the DEK-Session-KEY. This generates ciphertext A455 and an RND, which can be discarded. The UID field can be used to retrieve the shared secret of a contactless card. This, along with the Ver, UID, and pATC fields of the message, can be processed via an encrypted MAC using the recreated Aut-Session-Key to produce MAC outputs such as 'MAC'. If the MAC is the same as the ciphertext A455, this indicates that the message decryption and MAC check have all passed. Next, read the pATC to determine if it is valid.

[0083] During an authentication session, one or more ciphertexts may be generated by one or more applications. For example, one or more ciphertexts may be generated as a 3DES MAC using Method 2 padding via ISO9797-1 algorithm 3 and one or more session keys such as Auto-Session-Key 435. The input data 450 can take the following format: version(2), pUID(8), pATC(4), shared secret(4). In some examples, the numbers in parentheses may have a length in bytes. In some examples, the shared secret may be generated by one or more random number generators which may be configured to ensure that the random numbers are unpredictable through one or more secure processes. In some examples, the shared secret may consist of a random 4-byte binary number known by the authentication service and injected into the card at personalization. During an authentication session, the shared secret may not be provided to the mobile application from one or more applets. Method 2 padding may include adding a mandatory 0x'80' byte to the end of the input data and adding a 0x'00' byte which may be added to the end of the resulting data up to an 8-byte boundary. The resulting ciphertext may consist of 8 bytes in length.

[0084] In some examples, one advantage of using MAC ciphertext to encrypt non-shared random numbers as the first block is that it acts as an initialization vector while using the CBC (blockchain) mode of the symmetric encryption algorithm. This allows for "scrambling" between blocks without having to establish fixed or dynamic IVs beforehand.

[0085] 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. Furthermore, by including a version in one or more ciphertexts, it becomes difficult for an attacker to deliberately falsify the application version in an attempt to weaken the strength of the encryption solution. In some examples, the pATC may start at zero and be updated 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 less than or equal to a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and the authentication may be rejected. In some examples, if the pATC is greater than a previously received value, it may be evaluated to determine whether it is within an acceptable range or threshold, and if it is above or below the range or threshold, the verification may be considered to have failed or to be untrustworthy. In MAC operation 436, the data 450 is processed via MAC using the Aut-Session-Key 435 to generate the encrypted MAC output (ciphertext A) 455.

[0086] To provide additional protection against brute-force attacks that would expose the key on the card, it is desirable that the MAC ciphertext 455 be encrypted. In some examples, the data or ciphertext A455 contained in the ciphertext may consist of random numbers (8), ciphertext (8). In some examples, the numbers in parentheses may have a length in bytes. In some examples, the random numbers may be generated by one or more random number generators that can be configured to ensure that the random numbers are unpredictable through one or more secure processes. The key used to encrypt this data may consist of a session key. For example, the session key may consist of DEK-Session-Key 440. In encryption operation 441, the data or ciphertext A455 and RND are processed using DEK-Session-Key 440 to produce encrypted data, ciphertext B460. The data 455 is encrypted using 3DES in cryptographic blockchain mode, ensuring that an attacker would have to perform an attack on all ciphertexts. As a non-restrictive example, other algorithms such as Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' can be used. Successfully decrypted data will appear randomly and will be indistinguishable from incorrectly decrypted data, so an attacker attempting to brute-force the key used to encrypt this data will be unable to determine when the correct key was used.

[0087] For the authentication service to verify one or more ciphertexts provided by one or more applets, the following data must be transmitted in plaintext from one or more applets to the mobile device during the authentication session: a version number and message format for verifying the encryption to determine the encryption approach used, so that the approach can be changed in the future; a pUID for looking up the crypto asset and deriving the card key; and a pATC for deriving the session key used for the ciphertext.

[0088] Figure 5 shows a method 500 for generating ciphertext. For example, in block 510, the network profile record ID (pNPR) and derived key index (pDKI) can be used to identify the issuer master key to be used in the cryptographic process for authentication. In some examples, this method may include performing authentication and looking up the pNPR and pDKI values ​​of the contactless card at the time of authentication.

[0089] In block 520, issuer master keys can be diversified by combining them with the card's unique ID number (pUID) and one or more applets, such as the PAN sequence number (PSN) of a payment applet.

[0090] In block 530, Card-Key-Auth and Card-Key-DEK (unique card key) may be created by diversifying the issuer master key to generate a session key that can be used to generate MAC ciphertext.

[0091] In block 540, the key used to generate the ciphertext and encrypt data within one or more applets may have a session key in block 530 based on 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.

[0092] Figure 6 shows an exemplary process 600 illustrating key diversification in one example. Initially, two different master keys may be provisioned to the sender and 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 other data, such as a counter value that can be updated in block 602, and data to be protected that can be securely shared with the receiver.

[0093] In block 604, the counter value may be encrypted by the sender using the data encryption master key to generate a data encryption derived session key, and the counter value may 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 may be used during both encryptions.

[0094] In some cases, the counter value may not be encrypted. In these cases, the counter can be sent in plain text, i.e., without encryption, between the sender and receiver.

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

[0096] In block 608, the data to be protected may be encrypted by the sender using a data encryption derived session key in combination with a symmetric encryption algorithm. In some examples, the MAC is combined with equal amounts of random data, each 8 bytes long, and encrypted using a second session key (DEK-Session-Key).

[0097] In block 610, the encrypted MAC is sent from the sender to the receiver along with enough information to identify additional secrets (such as a shared secret or master key) for verification of the ciphertext.

[0098] In block 612, the receiver uses the received counter value to independently derive two derived session keys from the two master keys, as described above.

[0099] In block 614, the data encryption derived session key is used in conjunction with a symmetric decryption operation to decrypt the protected data. Additional processing is then performed on the exchanged data. In some examples, it is desirable to reconstruct and match the MAC after it has been extracted. For example, when verifying a ciphertext, it can be decrypted using a properly generated session key. The protected data may be reconstructed for verification. A MAC operation can be performed using a properly generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0100] In block 616, the data integrity derived session key is used in conjunction with the cryptographic MAC operation to verify that the protected data has not been altered.

[0101] Several examples of the methods described herein can favorably verify when successful authentication is determined when the following conditions are met: First, the ability to verify the MAC indicates that the derived session key is valid. The MAC can only be correct if decryption is successful and a valid MAC value is obtained. If decryption is successful, it can indicate that a correctly 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 sending device) and receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed genuine. Furthermore, 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.

[0102] Subsequently, the two derived session keys may be discarded, and the next iteration of data exchange may update the counter value (returning to block 602) and create a new set of session keys (in block 604). In some examples, combined random data may be discarded.

[0103] Figure 6B shows a timing diagram illustrating an exemplary message exchange according to one embodiment. Figure 6C shows an exemplary flowchart illustrating a logic 650 executed by an applet, logic, or program on card 130, and is described in parallel with Figure 6B.

[0104] Beginning with Figure 6C, the payment / transaction applet may store one or more PANs for a card in block 652. A PAN may be written to the card when the card is first issued. In some embodiments, only one PAN is issued to the card, and the payment / transaction applet maintains the PAN or accesses it at a defined location in memory. The payment / transaction applet can write to or rewrite PANs and may do so when a new PAN is requested. In other embodiments, multiple PANs may be issued to the card and stored in a list. One PAN (e.g., the first PAN in the list) may be designated as the active PAN used for payments and transactions. When a new PAN is needed, the old PAN is deleted, and the next PAN in the list may become the active PAN. Alternatively or additionally, another PAN in the list may be designated as the current PAN.

[0105] Turning to Figure 6B, the reissue process may be initiated when server 116 sends a reissue message 620 to client 104. The reissue message may indicate that a particular card belonging to an account owner associated with client device 104 should be reissued, modified, or otherwise changed. The account owner may be associated with client device 104 by installing an application on client device 104, which may belong to the card issuer (which may also be server 116).

[0106] For example, a user may install an application that allows them to check their outstanding balance and make payments. Furthermore, a user's specific card may be associated with the application based on the account / card number assigned to the user. The application may communicate with server 116 and register device 104 with the server. The user may log in to their account with the card provider via the application, thereby associating their account with device 104.

[0107] The application may also communicate with the user's card 130, thereby establishing a communication link from the server 116 to the card 130. If the server 116 determines that the user's account number has been compromised (or that the card number needs to be reissued for other reasons), the server 116 may contact the user's application on device 104 to accomplish this. The user's old number or identifier may be invalidated before, during, or after sending the reissue message 620.

[0108] Upon receiving a reissue message, the application on client 104 may recognize that the PAN must be reissued. The application may be programmed with several techniques to communicate this information to the communication / authentication applet on the card with a reissue instruction or tap pattern 622.

[0109] One technique may involve issuing an NFC write command (or other appropriate command using a different communication protocol) to a communication / authentication applet on card 130. The NFC write command may identify that the card number or identifier is being changed. This technique may be suitable for devices that can issue NFC write commands directly to the applet on the card, such as devices running the Android® operating system.

[0110] Some operating systems, such as the iOS® operating system, cannot directly issue NFC write commands to these applets. Therefore, an application may be programmed with logic configured to cause the display device to present the user with instructions requesting the user to tap card 130 on an NFC reader on device 104 in a predetermined pattern. This logic may correspond to a communication / authentication applet and may be configured to recognize a predetermined pattern and interpret this pattern as instructions for reissuing a PAN or identification number.

[0111] At 624, the communication / authentication applet on the card recognizes instruction or pattern 622 and initiates the card change process (block 654 in Figure 6C).

[0112] First, the communications / authentication applet establishes a secure communication channel or secure form of data transmission between the communications / authentication applet and the payment / transaction applet in block 626 (block 656 in Figure 6C). This communication channel may be embedded in a chip on card 130 so as not to require an express setup procedure, or it may be an ad-hoc communication channel or form of data transmission that is set up as needed.

[0113] The communication / authentication applet may send a reissue command 628 to the payment / transaction applet via a secure communication channel (block 658 in Figure 6C). Accordingly, the payment / transaction applet may select a new identifier or PAN at 630 (block 660 in Figure 6C) (for example, by moving to the next PAN in the list, generating a completely new PAN from scratch, or deriving a new PAN from the old PAN and / or other information stored on the card). In some cases, the process for selecting a new identifier or PAN may be coordinated with the server 116, as described above.

[0114] The payment / transaction applet may determine whether the identifier or PAN change was successful (e.g., whether a new PAN was generated that met certain predefined requirements). If there was a problem with the process or if the new PAN could not be validated according to the requirements, the payment / transaction applet may report the failure to the communications / authentication applet (block 652 in Figure 6C). The card chip may optionally revoke authorization at this point to execute the transaction.

[0115] If the PAN or identifier update is successful, the payment / transaction applet may confirm the success to the communication / authentication applet 632, which may relay that confirmation to the server 116 (block 652 in Figure 6C).

[0116] If the card includes a rewritable display such as an e-ink display, then in 634, the display may be rewritten with a new card identifier by a communication / authentication applet (or other appropriate logic on the card) (see block 654 in Figure 6C). Optionally, the card may remain in a magnetic field caused by communication with device 104 during this process, and the energy from the communication may be used to update the display.

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

[0118] In some cases, a contactless card can be tapped on one or more devices, such as computer kiosks or terminals, to verify identity and receive transaction items in response to a purchase, such as coffee. Using contactless cards can establish a secure way to verify identity in loyalty programs. For example, securely verifying identity to receive rewards, coupons, offers, or benefits is established in a way different from simply scanning a barcode. For example, encrypted transactions can occur between the contactless card and the device. This can be configured to handle one or more tap gestures. As described above, one or more applications can be configured to verify the user's identity and then prompt the user to act or respond to it, for example, via one or more tap gestures. In some cases, data such as bonus points, loyalty points, reward points, and healthcare information can be written back to the contactless card.

[0119] In some cases, contactless cards can be tapped onto devices such as mobile devices. As described above, a user's identity may be verified by one or more applications, which will then grant the user the desired benefit based on the verification of their identity.

[0120] In some cases, contactless cards can be activated by tapping a device, such as a mobile device. For example, a contactless card can communicate with a device's application via NFC communication through the device's card reader. In communication where the card tap is close to the device's card reader, the device's application may read the data associated with the contactless card and activate the card. In some cases, activation may allow the card to be used to perform other functions, such as making purchases, accessing accounts or restricted information, or other functions. In some cases, a tap can activate or launch a device's application, and then activate the contactless card by initiating one or more actions or communication with one or more servers. If the application is not installed on the device, tapping a contactless card near a card reader may initiate the download of the application, such as navigating to the application's download page. Following installation, tapping the contactless card activates or launches the application, and then initiates the activation of the contactless card, for example, through the application or other backend communication. After activation, the contactless card can be used in a variety of activities, including but not limited to commercial transactions.

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

[0122] In some embodiments, the exemplary authentication communication protocol can, with some modifications, mimic EMV standard offline dynamic data authentication protocols commonly performed between transaction cards and point-of-sale (POS) devices. For example, since the example authentication protocol is not used to complete payment transactions with the card issuer / payment processor itself, some data values ​​are unnecessary, and authentication can be performed without requiring a real-time online connection to the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system submits a transaction, including the transaction amount, to the card issuer. Whether the issuer approves or rejects the transaction may be based on whether the card issuer is aware of the transaction amount. On the other hand, in certain embodiments of this disclosure, transactions originating from a mobile device lack the transaction amount relevant to the POS system. Therefore, in some embodiments, a dummy transaction amount (i.e., a value that is recognizable to the card issuer and sufficient for activation to occur) may be passed as part of the exemplary authentication communication protocol. POS-based transactions may also reject transactions based on the number of transaction attempts (e.g., a transaction counter). If the number of attempts exceeds the buffer value, it may gradually decrease. A gradual decrease requires further verification before accepting the transaction. In some implementations, the transaction counter buffer value may be modified to avoid a decrease in legitimate transactions.

[0123] In some cases, contactless cards can selectively communicate information depending on the recipient's device. When a contactless card is tapped, it can recognize the device being tapped, and based on this recognition, it can provide the appropriate data to that device. This is advantageous because contactless cards only transmit the information necessary to complete an immediate action or transaction, such as payment or card authentication. By limiting data transmission and avoiding the transmission of unnecessary data, both efficiency and data security can be improved. Information recognition and selective communication can be applied to a variety of scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and reducing step-up fraud.

[0124] When a contactless card tap is directed towards 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 communication with the 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 towards 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 communication with the device (such as encrypted ID information necessary for authentication as described herein).

[0125] As another example, contactless card taps can be directed to POS devices, 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 transmit 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.

[0126] In some examples, a POS device participating in a transaction may 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 a POS device receives data communication from a contactless card, it may recognize the contactless card and request additional information necessary to complete an action or transaction.

[0127] In some cases, a POS device may partner with authorized merchants or other entities that are familiar with or accustomed to performing certain contactless card transactions. However, it is understood that such partnerships are not required for the performance of the described methods.

[0128] In some examples, such as shopping stores, grocery stores, and convenience stores, contactless cards can be tapped on a mobile device without opening an application, indicating a desire or intention to use one or more reward points, loyalty points, coupons, offers, etc., to cover one or more purchases. Thus, the intention behind the purchase is provided.

[0129] In some examples, one or more applications may be configured to determine that they were launched via one or more tap gestures on a contactless card, and as a result, to verify the user's identity, they were launched at 3:51 p.m. and the transaction was processed or executed at 3:56 p.m.

[0130] 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, one or more actions may include collecting rewards, collecting points, deciding on the most important purchase, deciding on the least expensive purchase, and / or reconfiguring into other actions in real time.

[0131] In some examples, data may be collected about tap behavior as biometric / gesture authentication. For example, a cryptographically secure and intercept-resistant unique identifier may be sent to one or more backend services. The unique identifier can be configured to retrieve secondary information about the individual. The secondary information may consist of personally identifiable information about the user. In some examples, the secondary information may be stored within a contactless card.

[0132] In some examples, the device may include an application that splits bills or checks payments between multiple individuals. For example, each individual may, but not be required, own a contactless card and 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 accepting only one card tap to indicate payment, other contactless cards may be used. In some examples, individuals with different financial institutions may own contactless cards that provide information to initiate one or more payment requests from the individual tapping the card.

[0133] The following use examples illustrate specific implementations of this disclosure. They are for illustrative purposes only and not limitable. In one case, a first friend (payer) is obligated to pay an amount to a second friend (recipient). The payer makes the payment via the recipient's smartphone (or other device) using a contactless card, rather than accessing an ATM or requesting an exchange via a peer-to-peer application. The recipient logs into the appropriate application on their smartphone and selects the payment request option. Accordingly, the application requests authentication via the recipient's contactless card. For example, the application displays a prompt requesting the recipient to tap their contactless card. With the application enabled, the recipient taps their contactless card on the smartphone screen, and the contactless card is read and verified. The application then displays a prompt requesting the payer to tap their contactless card to submit the payment. Once the payer taps their contactless card, the application reads the card information and, via the relevant processor, sends the payment request to the payer's card issuer. The card issuer processes the transaction and sends a transaction status indicator to the smartphone. The application then outputs to display the transaction status indicator.

[0134] In another example, a credit card customer might receive a new credit card (or debit card, other payment card, or other card requiring activation) via email. Instead of activating the card by calling a provided phone number associated with the card issuer or visiting a website, the customer might decide to activate the card through an application on their device (e.g., a mobile device such as a smartphone). The customer can select the card activation function from a menu in the application displayed on the device's screen. The application might prompt the customer to tap the credit card on the screen. Once the credit card is tapped on the device's screen, the application can be configured to communicate with a server, such as a card issuer's server, which will activate the customer's card. The application may then display a message indicating that the card activation was successful. The card activation is now complete.

[0135] The methods described above may be embodied as instructions on a computer-readable medium or as part of a computing architecture. Figure 7 shows an exemplary embodiment of a computing architecture 700 suitable for carrying out the various embodiments described above. In one embodiment, the computing architecture 700 may be implemented with or as part of an electronic device such as a computer 701. Embodiments are not limited to this context.

[0136] The terms “system” and “component” as used in this application are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or running software, examples of which are provided by the Exemplary Computing Architecture 700. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, an execution thread, a program, and / or a computer. For example, both an application running on a server and the server itself may be components. One or more components may reside within a process and / or an execution thread, and components may be localized to one computer and / or distributed across two or more computers. Furthermore, components may be coupled together in a communicative manner by various types of communication media and their operation may be coordinated. Coordination may include the one-way or two-way exchange of information. For example, components may communicate information in the form of signals communicated over a communication medium. Information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may use data messages as an alternative. Such data messages can be transmitted over various connections. Examples of connections include parallel interfaces, serial interfaces, and bus interfaces.

[0137] Computing architecture 700 includes a variety of common computing elements such as one or more processors, multicore processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, and power supplies. However, embodiments are not limited to those of computing architecture 700.

[0138] As shown in Figure 7, the computing architecture 700 includes a processing unit 702, system memory 704, and a system bus 706. The processing unit 702 may be any of a variety of commercially available processors, including but not limited to AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core(2)Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures may also be used as the processing unit 702.

[0139] The system bus 706 provides an interface to system components, including but not limited to the system memory 704, to the processing unit 702. The system bus 706 can be one of several types of bus structures that can further interconnect to the memory bus (with or without a memory controller), peripheral bus, and local bus using any of various commercially available bus architectures. Interface adapters can connect to the system bus 706 via slot architectures. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, Industry Standard Architecture ((E)ISA), Microchannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extensible) (PCI(X)), PCI Express, and Personal Computer Memory Card International Association (PCMCIA).

[0140] The computing architecture 700 comprises or can be implemented as a variety of products. These products may include computer-readable storage media for storing logic. Examples of computer-readable storage media include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or rewritable memory. Examples of logic may include executable computer program instructions implemented using any appropriate type of code, such as source code, compiled code, interpretable code, executable code, static code, dynamic code, object-oriented code, and visual code. Embodiments may also be implemented at least partially as instructions contained in or on a non-temporary computer-readable medium, which can be read and executed by one or more processors to enable the performance of the operations described herein.

[0141] The system memory 704 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, ferroelectric polymer memory, ovonic memory, polymer memory such as phase-change or ferroelectric memory, silicon oxide nitride (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in Figure 7, the system memory 704 may include non-volatile memory 708 and / or volatile memory 710. The non-volatile memory 708 may store the basic input / output system (BIOS).

[0142] The computing architecture 700 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 712, a magnetic floppy disk drive (FDD) 714 for reading from or writing to a removable magnetic disk 716, and an optical disk drive 718 for reading from or writing to a removable optical disk 720 (e.g., a CD-ROM or DVD). The HDD 712, FDD 714, and optical disk drive 720 may be connected to the system bus 706 by an HDD interface 722, an FDD interface 724, and an optical drive interface 726, respectively. The HDD interface 722 for external drive implementation may include at least one or both of the Universal Serial Bus (USB) and IEEE 694 interface technologies.

[0143] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored in the drives and memory units 708, 712, including an operating system 728, one or more application programs 730, other program modules 732, and program data 734. In one embodiment, the one or more application programs 730, other program modules 732, and program data 734 may include, for example, various applications and / or components of a messaging system 500.

[0144] The user may input commands and information to the computer 701 via one or more wired / wireless input devices, such as a keyboard 736 and a pointing device such as a mouse 738. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, gamepad, stylus pen, card reader, dongle, fingerprint reader, grab, graphics tablet, joystick, keyboard, retina reader, touchscreen (e.g., capacitive, resistive, etc.), trackball, trackpad, sensor, stylus, etc. These and other input devices are often connected to the processing unit 702 via an input device interface 740 coupled to the system bus 706, but may also be connected via other interfaces such as a parallel port, IEEE 694 serial port, game port, USB port, or IR interface.

[0145] Monitor 742 or other types of display devices are also connected to the system bus 706 via interfaces such as the video adapter 744. Monitor 742 can be located inside or outside the computer 701. In addition to Monitor 742, the computer typically includes other peripheral output devices such as speakers and printers.

[0146] Computer 701 may operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computers 744. Remote computers 744 could be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer devices, or other common network nodes, typically containing many or all of the elements described in relation to computer 701, but for brevity, only a memory / storage device 746 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 748 and / or a larger network, such as a wide area network (WAN) 750. Such LAN and WAN network environments are common in offices and businesses and facilitate enterprise-scale computer networks such as intranets. All of these may connect to global communication networks, such as the Internet.

[0147] When used in a LAN networking environment, computer 701 is connected to LAN 748 via a wired and / or wireless network interface or adapter 752. Adapter 752 may facilitate wired and / or wireless communication to LAN 748, which may include a wireless access point placed on it to communicate with the wireless capabilities of adapter 752.

[0148] When used in a WAN networking environment, computer 701 may include a modem 754, or be connected to a communication server on the WAN 750, or have other means of establishing communication on the WAN 750, such as via the Internet. The modem 754 may be internal or external, wired and / or wireless, and connect to the system bus 706 via an input device interface 740. In a network environment, the program modules, or parts thereof, shown with respect to computer 701 may be stored in a remote memory / storage device 746. The shown network connections are illustrative, and it will be understood that other means of establishing communication links between computers may be used.

[0149] Computer 701 is capable of communicating with wired and wireless devices or entities using the IEEE 802 standard family, such as wireless devices configured to operate wirelessly (e.g., IEEE 802.13 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMAX, and Bluetooth® wireless technologies. Thus, communication can be a predefined structure, similar to conventional networks, or simply ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and high-speed wireless connectivity using wireless technologies called IEEE 802.13x (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to connect to the Internet, or to wired networks (using IEEE 802.3 related media and functions).

[0150] Figure 8 is a block diagram showing an exemplary communication architecture 800 suitable for implementing the various embodiments described above. The communication architecture 800 includes various common communication elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, and power supplies. However, the embodiments are not limited to implementation by the communication architecture 800.

[0151] As shown in Figure 8, the communication architecture 800 includes one or more clients 802 and servers 804. A client 802 may implement a client device 510. A server 804 may implement a server device 526. The clients 802 and servers 804 are operably connected to one or more respective client data stores 806 and server data stores 808, which may be used to store information local to each client 802 and server 804, such as cookies and / or associated contextual information.

[0152] Client 802 and server 804 can communicate information with each other using the communication framework 810. The communication framework 810 can implement well-known communication technologies and protocols. The communication framework 810 can be implemented as a packet-switched network (e.g., a public network such as the Internet, or a private network such as a corporate intranet), a circuit-switched network (e.g., a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (using appropriate gateways and translators).

[0153] The communication framework 810 can implement various network interfaces configured to accept, communicate with, and connect communication networks. Network interfaces can be considered special forms of input / output interfaces. Network interfaces can employ connection protocols including, but not limited to, direct connection, Ethernet (e.g., thick, thin, twisted-pair 10 / 100 / 1000BaseT, etc.), Token Ring, wireless network interfaces, cellular network interfaces, IEEE 802.8a-x network interfaces, IEEE 802.16 network interfaces, and IEEE 802.20 network interfaces. Furthermore, multiple network interfaces can be used to interact with various communication network types. For example, multiple network interfaces can be used to enable communication over broadcast, multicast, and unicast networks. Where processing requirements demand speed and capacity, a distributed network controller architecture can similarly be used to pool, load balance, and otherwise increase the communication bandwidth required by clients 802 and servers 804. Communication networks can be any one or combination of wired and / or wireless networks, including but not limited to direct interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operational missions as nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.

[0154] The components and functions of the devices described above may be implemented using discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or any combination of single-chip architectures. Furthermore, the functions of the devices may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or, where appropriate, any combination thereof. Note that hardware, firmware, and / or software elements may be referred to collectively or individually as “logic” or “circuit” in this specification.

[0155] It should be understood that the exemplary devices shown in the block diagram above may represent only one example illustrating the functionality of many potential implementations. Therefore, the division, omission, or inclusion of block functions shown in the attached diagram does not necessarily mean that hardware components, circuits, software, and / or elements for implementing these functions are divided, omitted, or included in the embodiment.

[0156] At least one computer-readable storage medium may contain instructions that cause the system to perform any of the computer implementation methods described herein at runtime.

[0157] Some embodiments may be described using the expression “one embodiment” or its derivatives. These terms mean that certain features, structures, or characteristics described in relation to an embodiment are included in at least one embodiment. The expression “in one embodiment” appearing in various parts of this specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise specified, the features described above are understood to be usable together in any combination. Thus, any features described individually may be used in combination with each other unless it is noted that these features are incompatible with one another.

[0158] Referring in general to the notation and terminology used herein, the detailed descriptions herein may be presented in relation to program procedures performed on a computer or a network of computers. These descriptions and expressions of procedures are intended to be used by those skilled in the art to most effectively communicate the nature of the work to others skilled in the art.

[0159] Here, a procedure is generally considered to be a consistent series of operations that lead to a desired outcome. These operations require the physical manipulation of physical quantities. Typically, these quantities take the form of electrical, magnetic, or optical signals that can be stored, transferred, combined, compared, or otherwise manipulated. It is sometimes convenient, primarily for general use, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

[0160] Furthermore, the operations performed are often referred to in terms such as addition or comparison, which typically relate to intelligent calculations performed by human operators. In any of the operations described herein that form part of one or more embodiments, such ability of a human operator is neither required nor, in most cases, desirable. Rather, the operations are machine operations. Useful machines for performing the operations of various embodiments include general-purpose digital computers or similar devices.

[0161] Some embodiments may be described using the expressions “joined” and “connected,” along with their derivatives. These terms are not necessarily intended to be synonymous with each other. For example, some embodiments may be described using the terms “connected” and / or “joined,” indicating that two or more elements are in direct physical or electrical contact with one another. However, the term “joined” may also mean that two or more elements are not in direct contact with each other but still cooperate or interact with one another.

[0162] Various embodiments also relate to apparatus or systems for performing these operations. Such apparatus may include a general-purpose computer, which may be specifically constructed for a required purpose and selectively operated or reconfigured by a computer program stored within it. The procedures described herein are not inherently related to any particular computer or other apparatus. Various general-purpose machines may be used with the programs described herein, or it may be convenient to construct more specialized apparatus for performing the required method steps. The necessary structures for these various machines will become apparent from the given description.

[0163] It is emphasized that the disclosure summary is provided to allow readers to quickly confirm the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, it is found that in the aforementioned detailed description, various features are grouped into a single embodiment for the purpose of simplifying the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiment requires more features than expressly described in each claim. Rather, as reflected in the claims below, the subject matter of the invention is less than all the features of the single disclosed embodiment. Thus, the claims below are incorporated into the detailed description, and each claim exists as a separate embodiment in itself. In the attached claims, the terms “including” and “in which” are used as plain English equivalents to “equipped” and “here,” respectively. Also, terms such as “first,” “second,” and “third” are used simply as labels and are not intended to impose numerical requirements on their subjects.

[0164] The above description includes examples of disclosed architectures. Of course, it is impossible to describe all possible combinations of components and / or methodologies, but those skilled in the art will recognize that many more combinations and permutations are possible. Therefore, novel architectures are intended to include all such changes, modifications, and variations that fall within the spirit and scope of the attached claims.

Claims

1. Processor circuit and A computing device comprising a memory coupled to the processor circuit, The memory is configured to store instructions, and when an instruction is executed by the processor circuit, the processor circuit receives the instruction. The process involves performing a near-field wireless communication (NFC) exchange with a contactless card, wherein the NFC exchange with the contactless card takes place when the contactless card is within the NFC communication range of the computing device. Processing a message containing data for activating the aforementioned contactless card, wherein the message is received via NFC exchange, and the data indicates the type of device to be activated. An application is executed, and the application communicates the data to the server to activate the contactless card, wherein the data further includes the type of the computing device, and the activation is performed. Receiving a response from the server, the response indicating whether the contactless card was successfully activated or not, A computing device that performs [some action].

2. The computing device according to claim 1, wherein the message is in NFC Data Interchange Format (NDEF).

3. The computing device according to claim 1, wherein the message is in a format compliant with the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 14443 format.

4. The instruction is given to the processor circuit, The system decides to install the application in order to process the message, communicate the data, and receive the response. The application is further configured to initiate the automatic download and installation of the application, process the message, communicate the data, and receive the response. The computing device according to claim 1.

5. The instruction is given to the processor circuit, Based on the NFC exchange, the application is executed to process the message, communicate the data, and receive the response. The application is further configured to start execution, process the message, communicate the data, and receive the response. The computing device according to claim 1.

6. At least a portion of the aforementioned instructions is implemented as an operating system and configured to install the application via a store application. The computing device according to claim 4.

7. The data includes encrypted identity data for activating the contactless card. The computing device according to claim 1.

8. The aforementioned data is included in the NDEF tag. The computing device according to claim 2.

9. The computing device is Equipped with a display device, The instruction is given to the processor circuit. The system is further configured to cause the display device to display instructions to tap the contactless card on the surface of the computing device. The computing device according to claim 1.

10. The instruction is given to the processor circuit, The presenting of a menu on the graphical user interface (GUI) of the display device, wherein the menu includes user options for activating the contactless card, The system is further configured to prompt the user to tap the contactless card based on the user's input selection for activating the contactless card. The computing device according to claim 9.

11. The instruction is further configured to cause the processor circuit to issue a second instruction regarding whether the contactless card is activated or not, based on a response received from the server. The computing device according to claim 9.

12. At least a portion of the instructions is implemented in the application configured to run on the computing device. The computing device according to claim 1.

13. The aforementioned instructions are implemented in a web page for execution in the web browser of the computing device. The computing device according to claim 1.

14. A method performed on a computer, wherein the method is An application running on a computing device receives a message from a contactless card via near-field communication, wherein the message includes data for activating the contactless card, and the data indicates the type of device to be activated. The application communicates the data to the server and causes the server to activate the contactless card, wherein the data further includes the type of computing device, The application receives a response from the server indicating whether the contactless card was successfully activated or not. The application, based on a response received from the server, causes the graphical user interface (GUI) display on the computing device to show a graphical element indicating whether the contactless card is activated or not. Methods that are performed on a computer, including [specific examples].

15. The method executed on a computer according to claim 14, wherein the message is in NFC Data Interchange Format (NDEF).

16. The aforementioned message is in a format compliant with the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 14443 format. The method performed on a computer according to claim 14.

17. The aforementioned method, Performing an NFC exchange with the aforementioned contactless card, wherein the NFC exchange with the contactless card takes place when the contactless card is within the NFC communication range of the computing device. Based on NFC exchange, it is decided to install the application in order to perform the reception of the message, the communication of the data, the reception of the response, and the presentation of graphical elements. The automatic download and installation of the aforementioned application will begin, A computer-based method according to claim 14, including the following:

18. The aforementioned method, Performing an NFC exchange with the contactless card, wherein the NFC exchange with the contactless card takes place when the contactless card is within the NFC communication range of the computing device. Based on the NFC exchange, it is decided to execute the application in order to perform the reception of the message, the communication of the data, the reception of the response, and the presentation of graphical elements. Starting the execution of the aforementioned application, A computer-based method according to claim 14, including the following:

19. The method performed on a computer according to claim 14, wherein the data includes encrypted identity data for activating the contactless card.

Images