System and method for performing reissue of contactless card

Abstract

Example embodiments relate to reissuing or otherwise changing a contactless card. These embodiments are particularly suitable for emergency reissues, in which many cards have been compromised due to data breaches of major credit card providers or department stores. An exemplary contactless card includes a chip that stores encrypted authentication information, which includes a primary account number (PAN) that identifies the card. The chip may include a first applet responsible for making payments with the card; the first applet may manage the PAN. A second applet may be able to interact with an external application and may be used as a bridge with the first applet. The rewriting of the PAN may be triggered by issuing a write command to the second applet, or by interacting with the chip in a predetermined manner (e.g., tapping the card a predetermined number of times on an interactive element).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] 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, 2018, which claims priority to U.S. Provisional Application No. 62 / 740,352, filed on October 2, 2018, the disclosures of which are hereby incorporated by reference in their entirety. Technical Field

[0003] The present disclosure relates to authentication and authorization, and more particularly, to systems and methods for reissuing or otherwise changing information stored on a contactless card. Background Art

[0004] Data breaches that reveal customer payment information are increasingly common, and becoming more widespread, with millions of credit card numbers being revealed in a given breach. These data breaches may be caused when an unscrupulous actor breaks into a computing system associated with a large department store, bank, or credit card issuer and steals large amounts of payment data (e.g., including credit card numbers, expiration dates, etc.).

[0005] Typically, credit card issuers can respond to such a breach by reissuing the affected cards. This involves assigning a new credit card number to the user's account, producing a new physical card with the new number imprinted on it, writing a new magnetic stripe, and placing the card in the mail. When the breach is widespread (involving a large number of cards), it may take weeks or months for users to receive their new cards. During this time, they may not be able to use their accounts to make payments because it is possible that the card numbers were invalidated when the breach was discovered (to prevent unauthorized use of the account). Obviously, this can be problematic for customers.

[0006] The reissue process can also be expensive from the perspective of the card issuer, which typically absorbs the cost of producing and mailing a new card. Depending on the quality of the card material, the cost of creating a new card can be between $2 and $30. If a card needs to be reissued on an expedited basis, the additional processing costs can reach $10 per card. When millions of card numbers have been compromised, the resulting reissue costs can reach tens of millions of dollars. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A An environment suitable for use with the exemplary embodiments is depicted.

[0008] Figure 1B Depicting an example of a contactless card with a physical token.

[0009] Figure 1C Depicts the structure of an exemplary physical token.

[0010] Figure 2A Depicting an exemplary interface for a mobile application associated with an owner of a contactless card.

[0011] Figure 2B Depicts an exemplary interface when a physical token is read by a reader on an owner's mobile device.

[0012] Figure 2C Depicts an example of data exchange between a contactless card and a client device.

[0013] Figure 2D Depicted are exemplary data structures suitable for use with the exemplary embodiments.

[0014] Figure 3 is a flow chart illustrating key operations according to an example embodiment.

[0015] Figure 4 is a diagram of a key system according to an example embodiment.

[0016] Figure 5 is a flowchart of a method of generating a password according to an example embodiment.

[0017] Fig. 6A is a flow chart illustrating a key diversification process according to an example embodiment.

[0018] Figure 6B is a data flow diagram illustrating the exchange of communications in an exemplary embodiment.

[0019] Figure 6C is a flow chart depicting card-side logic for changing an identifier associated with a contactless card.

[0020] Figure 7 An exemplary computing system suitable for use with the exemplary embodiments is depicted.

[0021] Figure 8 An exemplary network environment suitable for use with the exemplary embodiments is depicted. DETAILED DESCRIPTION

[0022] Exemplary embodiments provide techniques for securely reissuing or otherwise changing information stored on a contactless card based on a remote command. Thus, the number associated with the 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 front, the printed number (and / or the number stored on the magnetic stripe) may not match the number stored on the contactless chip; nevertheless, the card can be used for contactless payments until a new card with the new number can be issued. In some embodiments, the card may include an electronic ink (e-ink) display that displays the number; in this case, the e-ink display can also be updated when the number stored on the contactless chip of the card is updated.

[0023] The chip of card can include one or more applet activated in some cases.For example, when paying with a card, the payment applet can be activated, and the number of the card can be supplied to the requesting device.In order to use the card with a new number, the payment applet may need to be updated, but for the purpose of safety, the payment applet can be limited to communicate directly with an external source.For this purpose, the chip can include a second encryption and authorization applet responsible for transmitting card information back and forth with an external source. The second applet can perform authentication, and it can be ensured that the information transmitted from the payment applet is carried out in a safe manner (for example, using encryption).As described in more detail below, the second applet can also be responsible for performing verification functions (for example, verifying the account stored on the card).According to an exemplary embodiment, this second applet can be made to be used as a bridge between an external source and a payment applet, and the bridge makes the number on the payment applet be rewritten based on the communication inside the secure (chip).

[0024] In some cases, the second small application can be directly instructed to overwrite the number of the card with a new number. For example, the mobile device running the Android operating system can issue a near field communication (NFC) write command to the second small application, and the rewrite command is issued to the payment small application to trigger the second small application. However, some devices may not support such communication (Apple's iOS is an example of this). Therefore, the second small application can also or alternatively be configured to identify the predefined pattern that the rewrite command is issued. For example, the user can tap their contactless card five times to the NFC reader in less than one minute. Because the NFC reader is tapped to trigger the authentication and encryption operation of the second small application, the second small application can be pre-configured to identify this predefined pattern and in response, issue the rewrite command.

[0025] In various embodiments, the card may have the ability to limit the number of number rewrites that can be performed (e.g., during the life of the card, or during a specific time period). To this end, the card may maintain a counter of the number of rewrites, and may further store a value representing the maximum number of rewrites that are allowable. If a request to rewrite a number is received, and the total number of requests (previous and current) exceeds the stored maximum value, the rewrite may be canceled.

[0026] The following description of the embodiments provides non-limiting representative examples of reference numbers that specifically describe the features and teachings of different aspects of the present invention. From the description of the embodiments, the described embodiments should be recognized as being capable of being implemented individually or in combination with other embodiments. The description of the embodiments should facilitate the understanding of the present invention to the extent that other implementations that are not specifically covered but are within the knowledge of those skilled in the art after having read the description of the embodiments will be understood to be consistent with the application of the present invention.

[0027] Figure 1A The data transmission environment 100 is illustrated according to an example embodiment. As discussed further below, the system 100 may include a contactless card 130, a client device 104, a network 114, and a server 116 maintained by a provider of the contactless card 130. Figure 1A A particular configuration of components is illustrated, but one of ordinary skill in the art will appreciate that other configurations including more or fewer components, or components in another configuration, may be used.

[0028] Environment 100 may include the following references Figure 1B One or more contactless cards 130 are further described. In some examples, the contactless card 130 can communicate wirelessly with the client device 104, such as NFC communication. The contactless card can 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 may be read by a reader (such as the NFC reader 110 ).

[0029] Environment 100 may include client device 104, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to, for example, a computer device or a communication device (including, for example, a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client, an Internet browser, or other device). Client device 104 may also be a mobile device; for example, a mobile device may include an iPhone, an iPod, a iPad, or iPad running Apple Any other mobile device running Microsoft's Any device running a mobile operating system, and / or any other smartphone or similar wearable mobile device.

[0030] Client device 104 and / or contactless card 130 may be associated with user 102, who may be the owner of the contactless card. User 102 may define credentials for accessing mobile applications on client device 104, which may be applications associated with the contactless card's service provider.

[0031] In various examples according to the present disclosure, the client device 104 of the environment 100 can execute one or more applications, such as software applications. The software applications can enable network communications with one or more components of the environment 100 and can transmit and / or receive data. Among other computer executable logic, the client device 104 may include client-side resend logic 112 (such as in conjunction with Figure 6B The logic is described in more detail).

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

[0033] To this end, server 116 may instruct client device 104 to change the PAN associated with card 130 of user 102. Client device 104 may receive the instruction and notify user 102 (e.g., via a display such as Figure 2A-2B The client device 104 may cause one or more applets stored on the card 130 to be activated, such as by an express command (e.g., an NFC write command), or by requesting the user 102 to tap the card 130 against the NFC reader 110 in a predetermined pattern (e.g., a predetermined number of times, at a predetermined rate during a period of time, in a predetermined pattern, etc.).

[0034] Instructions to change the PAN may be sent from the server 116 on a personal basis (eg, when a single user's 102 card 130 is compromised), or reissue instructions may be broadcast to a group of recipients (as may be done in the event of a large data breach).

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

[0036] If the client device 104 is able to issue a write request directly to the card 130, the write request may include information received from the server (e.g., a new PAN, a number of skipped PANs in the list, a generation technique for deriving a new PAN, or a seed for a new PAN). If the client device 104 is unable to issue such a write request, the card 130 may still coordinate with the server 116, although perhaps in a more limited manner. For example, if, as noted above, the communication logic / applet on the card 130 is configured to recognize a predetermined tap pattern as an instruction to change a PAN, different patterns may be associated with different change instructions. For example, if a user taps the card 130 five times against the NFC reader 110 in less than one minute, this may be interpreted as an instruction to advance to the next PAN stored in the list. On the other hand, if a user taps the card 130 only four times against the NFC reader 110 in less than one minute, this may be interpreted as an instruction to skip two PANs in the list forward. The instructions from the server 116 to the client device 104 may identify the particular mode to be used, and the client device 104 may display appropriate instructions on a user interface. If multiple different modes are programmed into the communication logic / applet on the card 130, the device 104 may request confirmation of the mode by the user to ensure that the correct mode is used (e.g., by requiring the user to tap in a predetermined mode, wait briefly, and then requiring the user to confirm the change by tapping again in the same predetermined mode).

[0037] Once the PAN is changed, the communication logic / applet on the card 130 can report success to the server 116. The success can identify the new PAN that has been selected (either directly, by reporting the PAN or an encrypted version of the PAN, or indirectly, such as by transmitting a hash of the PAN or a subset of the PAN). If the updated PAN does not match the PAN expected by the server 116, the PAN can be invalidated and the process can be repeated. Alternatively, the server 116 can simply accept the PAN reported by the card 130.

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

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

[0040] 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 on the card. Optionally, an e-ink display 149 (or another type of rewritable display using technology such as liquid crystal diodes) may be provided for displaying 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 emitted from the client device 104). The antenna of the card 130 (e.g., the antenna of the contact pad 138 discussed 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. As discussed herein, this allows the e-ink display 149 to be changed to match the new number of the small application deployed to the card 130.

[0041] The contactless card 130 may further include a contact pad 138. The contact pad 138 may be configured to establish contact with another communication device such as a user device, a smart phone, a laptop, a desktop or a tablet computer. Figure 1C The contactless card 130 may also include a magnetic stripe or tape (on the back of the card) that may be located behind the contact pads 138 or elsewhere on the substrate 134. Figure 1B not shown).

[0042] like Figure 1C As shown, Figure 1B The contact pads 138 may include processing circuitry 140 for storing and processing information, the processing circuitry 140 including a microprocessor 142 and a memory 144. It is understood that the processing circuitry 140 may contain additional components necessary to perform the functions described herein, including processors, memories, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware.

[0043] The memory 144 can be a read-only memory, a write-once read-many memory or a read / write memory, for example, a RAM, a ROM and an EEPROM, and the contactless card 500 may include one or more of these memories. The read-only memory can be factory programmable to be read-only or one-time programmable. One-time programmable provides the opportunity to write once and then be read many times. The write-once / read-many memory can be programmed at a point in time after the memory chip has left the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. The read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read many times.

[0044] Memory 144 can be configured to store one or more small applications 146, one or more counters 108 and customer identifier 148.Described one or more small applications 146 can comprise one or more software applications that are configured to be executed on one or more contactless cards, such as Java card small application.However, understand that small application 146 is not limited to Java card small application, but can be any software application operable on contactless card or other devices with limited memory.Described one or more counters 108 can comprise the numerical value counter that is enough to store integer.Customer identifier 148 can comprise the unique alphanumeric identifier that is assigned to the user of contactless card 130, and this identifier can distinguish the user of contactless card and other contactless card users.In some examples, customer identifier 148 can identify the account that customer and are assigned to this customer, and can further identify the contactless card that is associated with customer's account.

[0045] Small application 146 may include a small application for payment configured to perform payment transactions with card 130. The small application for payment may be responsible for maintaining or may use the primary account number (PAN) of the card, which may be transmitted from the card as a part of the transaction. Small application 146 may further include an authentication and / or encryption small application called when an external source (such as client device 104, point-of-sale terminal, automated teller machine, etc.) attempts to establish communication with card 130 (such as when contact pad 138 is placed close to or adjacent to a reader (such as NFC reader 110)). The small application for payment may not communicate directly with an external source (that is, a source outside the processing circuit system 140), but may be able to communicate securely with another small application (such as authentication and encryption small application) on the processing circuit system 140. Information may be passed from the small application for payment to the authentication and encryption small application for communication outside the card.

[0046] Optionally, the payment applet may be pre-loaded (e.g., when the card is issued) with predefined PANs, one of which is designated as the currently active PAN, with the rest of the PANs held in reserve. When the applet is invoked to issue a new PAN, the applet may select the next PAN in the list and designate it as the active PAN. Alternatively, the applet may randomly generate a new PAN according to a PAN generation rule, or may generate a new PAN based on a previous PAN.

[0047] The processor and memory elements of the foregoing exemplary embodiments are described with reference to the contact pads, but the present disclosure is not limited thereto. It is understood that these elements may be implemented external to the pad 138, or completely separate from it, or as further elements in addition to the processor 142 and the memory 144 disposed within the contact pad 138.

[0048] In some examples, the contactless card 130 may include one or more antennas 150. The one or more antennas 150 may be placed inside the contactless card 130, around the processing circuit system 140 of the contact pad 138. For example, the one or more antennas 150 may be integrated with the processing circuit system 140, and the one or more antennas 150 may be used with an external booster coil. As another example, the one or more antennas 150 may be external to the contact pad 138 and the processing circuit system 142.

[0049] In an embodiment, the coil of the contactless card 130 can act as the secondary of an air core transformer. The terminal can communicate with the contactless card 130 by cutting off power or amplitude modulation. The contactless card 130 can use the gap to infer the data transmitted from the terminal when the contactless card is connected to a power source, and the power connection can be functionally maintained by one or more capacitors. The contactless card 130 can return communication by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected by interference in the coil of the terminal.

[0050] As explained above, contactless card 130 can be built on a software platform operable on a smart card or other devices (such as JavaCard) with limited memory, and one or more applications or applet can be safely executed. Applet can be added to contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various use cases based on mobile applications. Applet can be configured to respond to one or more requests (such as near field data exchange request (NDEF)) from a reader (such as a mobile NFC reader), and generate an NDEF message, which includes an OTP that is encoded as a NDEF text tag, cryptographically secure.

[0051] As noted above, an exemplary transaction may be via logic 112 executing on client device 104 to authenticate a requested transaction to an account associated with a contactless card. Figure 2A-2B An exemplary interface that may be presented on a client device in response to the described logic is depicted.

[0052] Figure 2A Depicting an initial interface 200 for an application associated with a card (e.g., an application provided by a card provider), the initial interface 200 may be displayed on the client device 104 when the client device 104 receives instructions from the server 116 to reissue a card, or otherwise reallocate or change information stored on a card. The interface 200 includes a message area 202 that displays information about the reissue of the card information. The message area 202 may explain, for example, that the user's card has been reissued, why the reissue has occurred, and the next steps required for the user to change the card information.

[0053] Interface 200 may further include interactive element 204. To change the information stored on the card, the user may optionally first be required to select interactive element 204 in order to verify the user's desire to reissue the card number (so that the user does not accidentally overwrite the card information by placing the card adjacent to an NFC reader).

[0054] When an interactive element is selected, such as Figure 2BAs shown, the user can rewrite the PAN or other information stored on the card 130 by bringing the contact pads 138 of the card's chip into proximity with the NFC reader of the device 104. When the card is brought into proximity with the NFC reader and the applet on the card confirms that the card's PAN has been successfully changed, a confirmation message 206 can be displayed indicating that the card's information has been successfully rewritten.

[0055] As Figure 2A-2B Alternatively to the process shown, the user may be prompted (in interface 200) to tap their card on the client device's NFC reader in a predetermined pattern. The authentication and encryption applet may register the predetermined pattern.

[0056] although Figure 2A-2B The card 130 is depicted being rewritten when brought into proximity with the mobile client device 104 , but it is also contemplated that the card may be rewritten by an automated teller machine, point of sale terminal, or any other device having a suitable transmitter (e.g., an NFC transmitter) for communicating with the contact pad 138 .

[0057] like Figure 2B As shown, when a new PAN is written to the chip on the contactless card, the new card number may not match the number printed or embossed on the card or the information stored on the magnetic stripe of the card. In this case, it may still be desirable to have a new physical card created and sent to the user so that all of the card's several payment options can be used. Nevertheless, while the card is being sent to the user, the contactless payment functionality of the card can still be used using the information stored on the chip. If the card includes an e-ink display, as noted above, the e-ink display can be updated when the PAN is rewritten to reflect the new card number. In this case, it may not be necessary to reissue the physical card, especially if the card does not include a magnetic stripe, or if the user primarily uses the card for contactless payments.

[0058] Figure 2C is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure.A system may include a contactless card 130 and a client device 104, which may include an application (which may include logic 112) and a processor.

[0059] At 202, the application communicates with the contactless card 130 (e.g., after being brought into proximity with the contactless card 130). The communication between the application and the contactless card 130 may involve the contactless card 130 being sufficiently close to a card reader (not shown) of the client device 104 to enable NFC data transfer between the application and the contactless card 130.

[0060] In step 204, after communication has been established between the client device 104 and the contactless card 130, the contactless card 130 generates a message authentication code (MAC) password. In some examples, this can occur when the contactless card 130 is read by the application of the hosting logic 112. Specifically, this can occur when a near field data exchange (NDEF) tag is read (such as an NFC read), and the NDEF tag can be created according to the NFC data exchange format. For example, a reader (such as logic 112) can transmit a message with a small application ID of the NDEF that generates a small application, such as a small application selection message. When the selection is confirmed, a sequence of a file selection message followed by a file reading message can be transmitted. For example, the sequence can include "select capability file", "read capability file" and "select NDEF file". At this time, the counter value maintained by the contactless card 130 can be updated or incremented, and the value can be followed by "read NDEF file". At this time, a message that can include a header and a shared secret can be generated. Then a session key can be generated. A MAC password can be created from a message that can include a header and a shared secret. The MAC password may then be concatenated with one or more blocks of random data, and the MAC password and random number (RND) may be encrypted using the session key. Thereafter, the password and header may be concatenated, encoded as ASCII hexadecimal, and returned in the NEDF message format (in response to a "Read NDEF File" message).

[0061] In some examples, the MAC password may be transmitted as an NDEF tag, and in other examples, the MAC password may be included with the uniform resource indicator (eg, as a formatted string).

[0062] In some examples, logic 112 may be configured to transmit a request to contactless card 130 that includes instructions to generate a MAC password.

[0063] In step 206, the contactless card 130 sends the MAC password to the logic 112. In some examples, the transmission of the MAC password occurs via NFC, however, the present invention is not limited thereto. In other examples, the communication can occur via Bluetooth, Wi-Fi, or other wireless data communication means.

[0064] At step 208, the logic 112 transmits the MAC password to the processor.

[0065] At step 210, the processor verifies the MAC password in accordance with instructions from the logic 122. For example, the MAC password may be verified as described below.

[0066] In some examples, verifying the MAC password may be performed by a device other than client device 104, such as server 116 in data communication with client device 104. For example, the processor may output the MAC password for transmission to server 116, which may verify the MAC password.

[0067] In some examples, the MAC password can be used as a digital signature for verification purposes. Other digital signature algorithms (such as public key asymmetric algorithms, for example, the digital signature algorithm and the RSA algorithm) or zero-knowledge protocols can be used to perform the verification.

[0068] Figure 2D An exemplary technique for generating a protected message 230 is depicted in accordance with an exemplary embodiment.

[0069] Message 230 can be configured to deliver information or content from a sender to a recipient. The information or content can be represented by message plaintext 234 (but the content can be optionally encrypted).

[0070] 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 is related to an authentication action for a contactless card as described above, the process of setting up or initializing the card may involve sharing a random number between a chip on the card and a transaction verification server. In one embodiment, the random number may be a 32-bit random number. Alternatively or in addition, a communication session may be set up by the sender and the receiver; the process of setting up the communication session may involve sharing a random number between the sender and the receiver, which may be used as the shared secret 232.

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

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

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

[0074] After the message plaintext 234 and the shared secret 232 are combined, they may be provided to a MAC algorithm 236. The MAC algorithm 236 may be any suitable MAC algorithm, such as a data authentication algorithm (DAA), a cipher block chaining message authentication code (CBC-MAC), a Galois message authentication code (GMAC), and a hashed message authentication code (HMAC), among many others.

[0075] MAC algorithm 236 may operate using a key. In an exemplary embodiment, the 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 the 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, MAC algorithm 236 may generate a MAC output 238.

[0076] MAC output 238 may optionally be encrypted using encryption algorithm 240 to produce encrypted MAC 242. Encryption algorithm 240 may be any suitable encryption algorithm, such as Data Encryption Standard (DES), TripleDES (3DES), Advanced Encryption Standard (AES), and RSA, among many others.

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

[0078] The encryption algorithm 240 may operate using a key. In an exemplary embodiment, the key may be a second diversified key 252 created using a diversification algorithm 248. The diversification algorithm may operate on the counter 108 received from the 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.

[0079] The encrypted MAC 232 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 consulted by the recipient (eg, server) when authenticating the message. The shared secret 232 is not sent directly as part of the message.

[0080] Figure 3 is a flow chart illustrating key operation 300 according to an example embodiment. Figure 3 As shown, at block 310, two unique derivation keys (UDKs) may be generated per card using two bank identifier number (BIN) level master keys in conjunction with an account identifier and a card serial number. In some examples, the bank identifier number may include a number or a combination of one or more numbers, such as an account number or an unpredictable number provided by one or more servers, which may be used for session key generation and / or diversification. The UDKs (AUTKEY and ENCKEY) may be stored on the card during the personalization process.

[0081] At block 320, the counter can be used as diversification data because it changes with each use and provides a different session key each time, as opposed to the master key derivation where each card generates a unique set of keys. In some examples, it is preferred to use the 4-byte method for both operations. Thus, at block 320, two session keys can be created from the UDK for each transaction, i.e., one session key from the AUTKEY and one session key from the ENCKEY. In 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.

[0082] At block 330, a MAC key may be used to prepare a MAC password, and the ENC key may be used to encrypt the password. For example, a MAC session key may be used to prepare the password, and the result may be encrypted using the ENC key before the result is transmitted to the one or more servers.

[0083] At block 340, verification and processing of the MAC is simplified because 2-byte diversification is directly supported in the MAC authentication function of the payment HSM. Decryption of the password is performed before verification of the MAC. The session key is independently derived at the one or more servers to obtain a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) can be used to decrypt the data, and the first derived key (i.e., the MAC session key) can be used to verify the decrypted data.

[0084] For contactless cards, different unique identifiers are derived, which can be related to the application master account number (PAN) and PAN serial number encoded in the card. Key diversification can be configured to receive the identifier as input together with the master key so that for each contactless card, one or more keys can be created. In some examples, these diversified keys can include a first key and a second key. The first key can include an authentication master key (card password generation / authentication key - Card-Key-Auth), and can be further diversified to create a MAC session key used when generating and verifying a MAC password. The second key can include an encryption master key (card data encryption key - Card-Key-DEK), and can be further diversified to create an ENC session key used when encrypting and decrypting the data translated into the password. In some examples, the first key and the second key can be created in the following manner, that is, by combining the issuer master key with the unique ID number (pUID) of the card and the PAN serial number (PSN) of the payment small application to diversify the issuer master key. The pUID can include a 16-bit value. As described above, the pUID can include a 16-bit BCD coded number. In some examples, the pUID may comprise a 14-bit value.

[0085] In some examples, because the EMV session key derivation method may encapsulate at 2^16 uses, a counter (such as a full 32-bit counter) may be added to the initialization array of the diversification method.

[0086] In other examples, such as a credit card, a number (such as an account number or an unpredictable number provided by one or more servers) may be used for session key generation and / or diversification.

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

[0088] Regarding master key management, two issuer master keys 405, 410 may be required for each portion of the folder on which the one or more applets are issued. For example, the first master key 405 may include an issuer password generation / authentication key (Iss-Key-Auth) and the second master key 410 may include an 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, both of which are unique to each card. In some examples, a network profile record ID (pNPR) 415 and a derived key index (pDKI) 420, as back-office data, may be used to identify which issuer master keys 405, 410 are used for authentication in cryptographic processing. The system performing the authentication may be configured to retrieve the values ​​of the pNPR 415 and the pDKI420 for contactless cards at the time of authentication.

[0089] In some examples, in order to improve the security of the solution, a session key (such as a unique key for each session) can be derived, rather than using a master key, as described above, a unique card derivation key and a counter can be used as diverse data. For example, each time the card is used in operation, different keys can be used to create a message authentication code (MAC) and perform encryption. About session key generation, the key used to generate a password in one or more small applications and to translate data into a password can include a session key (Card-Key-Auth 425 and Card-Key-Dek430) based on a card unique key. Session keys (Aut-Session-Key 435 and DEK-Session-Key 440) can be generated by the one or more small applications, and are derived by using an application transaction counter (pATC) 445, utilizing one or more algorithms. In order to put data into one or more algorithms, only 2 low-order bytes are used in the 4-byte pATC 445. In some examples, a four-byte session key derivation method may include: F1:=PATC(low 2 bytes)||'F0'||'00'||PATC(four bytes)F1:=PATC(low 2 bytes)||'0F'||'00'||PATC(four bytes)SK:={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG may include 3DES ECB, and MK may include a master key uniquely derived from the card.

[0090] As described herein, the two bytes of the lower order of the pATC 445 counter can be used to derive one or more MAC session keys. At each tap on a contactless card, pATC 445 is configured to be updated, and the card master key Card-Key-AUTH 425 and Card-Key-DEK 430 are further diversified into session keys Aut-Session-Key 435 and DEK-Session-KEY 440. pATC 445 can be initialized to zero when personalized or small application is initialized. In some examples, pATC counter 445 can be initialized at or before personalized, and can be configured to increase by 1 at each NDEF read.

[0091] Additionally, updates for each card may be unique and either assigned through personalization or algorithmically assigned through a pUID or other identifying information. For example, odd-numbered cards may be incremented or decremented by 2, and even-numbered cards may be incremented or decremented by 5. In some examples, updates may also read changes sequentially, such that a card may be incremented by 1, 3, 5, 2, 2, ... repeatedly in sequence. The specific sequence or algorithmic sequence may be defined at personalization, or from one or more processes derived from a unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0093] The MAC may be performed by a function key (AUT-Session-Key) 435. The data specified in the cipher may be processed using the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 to relate to the EMV ARQC verification method. As described above, the key used for the calculation may include the session key AUT-Session-Key 435. As described above, the lower two bytes of the counter may be used to diversify one or more MAC session keys. As described below, the AUT-Session-Key 435 may be used to MAC data 450, and the resulting data or cipher A 455 and random number RND may be encrypted using the DEK-Session-Key 440 to create cipher B or output 460 sent in a message.

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

[0095] The following format represents a binary version example embodiment. In some examples, the first byte may be set to ASCII "A".

[0096]

[0097]

[0098]

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

[0100]

[0101]

[0102]

[0103]

[0104] The UID field of the received message can be extracted to derive the card master keys (Card-Key-Auth 425 and Card-Key-DEK 430) for that particular card from the master keys Iss-Key-AUTH 405 and Iss-Key-DEK410. Using the card master keys (Card-Key-Auth 425 and Card-Key-DEK 430), the counter (pATC) field of the received message can be used to derive the session keys (Aut-Session-Key 435 and DEK-Session-Key 440) for that particular card. The DEK-Session-KEY can be used to decrypt the cryptogram B 460, which results in cryptogram A 455 and RND, which can be discarded. The UID field can be used to look up the shared secret of the contactless card, which, along with the Ver, UID, and pATC fields of the message, can be processed by the cryptogram MAC, using the recreated Aut-Session-Key to create a MAC output, such as MAC'. If the MAC' is the same as the cipher A 955, this indicates that the message decryption and MAC verification have all passed. The pATC can then be read to determine if it is valid.

[0105] During the authentication session, one or more applications may generate one or more passwords. For example, the one or more passwords may be generated as 3DES MACs using ISO 9797-1 algorithm 3 and method 2 padding via one or more session keys (such as Aut-Session-Key 435). Input data 450 may take the following form: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the number in brackets may include the length of 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 number is unpredictable through one or more security processes. In some examples, the shared secret may include a random 4-byte binary number that is injected into the card during personalization and is known to the authentication service. During the authentication session, the shared secret may not be provided to the mobile application from the one or more applet. 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 password may comprise 8 bytes in length.

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

[0107] By including an application transaction counter (pATC) as part of the data included in the MAC password, the authentication service can be configured to determine whether the value passed in the clean data has been tampered with. Moreover, by including the version in the one or more passwords, it is difficult for an attacker to deliberately misrepresent the application version in an attempt to reduce the advantage of the password solution. In some examples, the pATC can start from zero and be updated with 1 each time one or more applications generate authentication data. The authentication service can be configured to track the pATC used during the authentication session. In some examples, when the authentication data uses a pATC that is equal to or lower than the previous value received by the authentication service, this can be interpreted as an attempt to replay an old message and the authentication can be rejected. In some examples, in the case where the pATC is greater than the previous value received, this can be estimated to determine whether it is within an acceptable range or threshold, and whether it exceeds the range or threshold, or is outside the range or threshold, the verification can be considered to have failed or is unreliable. In a MAC operation 436, data 450 is processed by MAC using Aut-Session-Key 435 to generate a MAC output (Crypt A) 455, which is encrypted.

[0108] In order to provide additional protection against brute force attacks that expose the key on the card, it is desirable that the MAC password 455 is encrypted. In some examples, the data or password A 455 to be included in the cipher text may include: random number (8), password (8). In some examples, the number in brackets may include a length in bytes. In some examples, the random number may be generated by one or more random number generators, which may be configured to ensure that the random number is unpredictable through one or more security processes. The key used to encrypt the data may include a session key. For example, the session key may include a DEK-Session-Key 440. In an encryption operation 441, the data or password A 455 and RND are processed using the DEK-Session-Key 440 to generate encrypted data, password B 460. In a cipher block chaining mode, 3DES may be used to encrypt the data 455 to ensure that an attacker must run any attack on all cipher texts. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'00000000000000000" may be used. Any attacker trying to brute force the key used to encrypt the data will not be able to determine when the correct key has been used because data that has been decrypted correctly will be indistinguishable from data that has been decrypted incorrectly due to its random appearance.

[0109] In order for the authentication service to verify one or more passwords provided by one or more applets, the following data must be transmitted in plain text from the one or more applets to the mobile device during the authentication session: a version number, to determine the cryptographic method used and the message format used to verify the password, so that the method can be changed in the future; a pUID, to retrieve the cryptographic asset and derive the card key; and a pATC, to derive the session key for the password.

[0110] Figure 5 The method 500 for generating a cryptogram is illustrated. For example, at block 510, a network profile record ID (pNPR) and a derived key index (pDKI) may be used to identify which issuer master keys are used for authentication in a cryptographic process. In some examples, the method may include performing an authentication to retrieve the values ​​of the pNPR and pDKI for a contactless card at the time of authentication.

[0111] At block 520, the issuer master key may be diversified by combining the issuer master key with the card's unique ID number (pUID) and a PAN serial number (PSN) of one or more applets (eg, a payment applet).

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

[0113] At block 540, the keys used to generate cryptograms and encrypt data in one or more applets may include session keys based on the card unique keys (Card-Key-Auth and Card-Key-DEK) of block 530. In some examples, these session keys may be generated by the one or more applets and derived using pATC to obtain session keys Aut-Session-Key and DEK-Session-Key.

[0114] FIG. 6 depicts an exemplary process 600 for illustrating key diversification according to an example. Initially, two different master keys may be deployed for a sender and a receiver. For example, a first master key may include a data encryption master key and a second master key may include a data integrity master key. The sender has a counter value that may be updated at block 602 and other data (such as data to be protected) that may be ensured to be shared with the receiver.

[0115] At 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.

[0116] In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted between the sender and the receiver in plain text, i.e., not encrypted.

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

[0118] The sender may use the session key derived from the data encryption in conjunction with a symmetric encryption algorithm to encrypt the data to be protected at block 608. In some examples, the MAC is combined with an equal amount of random data (e.g., each 8 bytes long) and then encrypted using a second session key (DEK-Session-Key).

[0119] At block 610, the encrypted MAC is transmitted from the sender to the receiver along with information sufficient to identify additional secret information (such as a shared secret, master key, etc.) for use in verifying the secret.

[0120] At block 612, the recipient uses the received counter value to independently derive two derived session keys from the two master keys as described above.

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

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

[0123] Some examples of the methods described herein can advantageously confirm 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 appropriate. The MAC can only be correct if the decryption is successful and the appropriate MAC value is obtained. Successful decryption can indicate that the correctly derived encryption key is used to decrypt the encrypted MAC. Because the derived session key is created using a master key known only to the sender (e.g., a transmission device) and the receiver (e.g., a receiving device), it can be trusted that the contactless card that originally created the MAC and encrypted the MAC is actually credible. Moreover, the counter value used to derive the first session key and the second session key can be shown as valid and can be used to perform the authentication operation.

[0124] Thereafter, both derived session keys may be discarded, and the next data exchange iteration will update the counter value (returning to block 602), and a new set of session keys may be created (at block 604). In some examples, the combined random data may be discarded.

[0125] Figure 6B Depicted is a timing diagram showing an exemplary exchange of messages in accordance with an embodiment. Figure 6C An exemplary flow chart showing logic 650 executed by an applet, logic or program on card 130 is depicted and is associated with Figure 6B Discuss in parallel.

[0126] from Figure 6C Initially, the payment / transaction applet can, at box 652, store one or more PANs for the card. The PAN can be written to the card when the card is initially issued. In some embodiments, as long as a PAN is issued to the card, the payment / transaction applet maintains the PAN, or accesses it in a defined location in the memory. The payment / transaction applet can be able to write or rewrite the PAN, and can do so when a new PAN is needed. In other embodiments, multiple PANs can be issued to the card, and can be stored in a list. A PAN (such as the first PAN in the list) can be designated as the active PAN for payment and transactions. When a new PAN is needed, the old PAN can be deleted, and the next PAN in the list can become the active PAN; alternatively or in addition, different PANs in the list can be designated as current PANs.

[0127] Turn to Figure 6B , the reissue process may begin when the server 116 transmits a reissue message 620 to the client 104. The reissue message may be an indication that a particular card belonging to an account holder associated with the client device 104 should have its identifier / PAN reissued, altered, or otherwise changed. The account holder may be associated with the client device 104 by installing an application on the client device 104 belonging to the card issuer (which may also maintain the server 116).

[0128] For example, a user may install an application that allows the user to review their outstanding balances, make payments, etc., and the user's specific card may be associated with the application based on the account number / card number assigned to the user. The application may communicate with the server 116 and may register the device 104 with the server. The user may log into their account with the card provider through the application, thereby associating their account with the device 104.

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

[0130] Upon receiving the reissue message, the application on the client 104 can recognize that the PAN must be reissued. The application can be programmed to use a number of techniques to communicate this information to the communication / authentication applet on the card in a reissue instruction or tap mode 622.

[0131] One technique may involve issuing an NFC write command (or another suitable command using a different communication protocol) to a communication / authentication applet on the card 130. The NFC write command may identify that the card number or card identifier is to be changed. This technique may be suitable for devices that are capable of issuing NFC write commands directly to an applet on the card, such as those running the Android operating system.

[0132] Some operating systems, such as the iOS operating system, cannot issue NFC write commands directly to these applets. Therefore, the application may be written with logic configured to cause the display device to hand the user instructions requesting the user to tap their card 130 against the NFC reader on the device 104 in a predetermined pattern. This logic may have a counterpart on the communication / authentication applet configured to recognize the predetermined pattern and interpret the pattern as a reissued PAN or identification number.

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

[0134] First, in 626 ( Figure 6C In block 656), the communication / authentication applet sets up a secure communication channel or secure data transmission format between the communication / authentication applet and the payment / transaction applet. The communication channel may be built into a chip on the card 130 so that an extremely fast setup process is not required, or may be a peer-to-peer communication channel or data transmission format that is set up on demand.

[0135] The communication / authentication applet can be used over a secure communication channel ( Figure 6C In response, the payment / transaction applet may send the reissue command 628 to the payment / transaction applet at 630 ( Figure 6C ), select a new identifier or PAN (e.g., advance to the next PAN in the list, generate an entirely new PAN from the scratch, derive the new PAN from the old PAN and / or other information stored on the card, etc.). In some cases, the process for selecting a new identifier or PAN may be coordinated with server 116, as previously discussed.

[0136] The payment / transaction applet may determine whether the change of identifier or PAN was successful (e.g., whether a new PAN has been generated that meets certain predefined requirements). If there is a problem in the process, or if the new PAN cannot be verified according to the requirements, the payment / transaction applet may report the failure to the communication / authentication applet ( Figure 6C The card's chip may optionally be deauthorized to perform the transaction at this time.

[0137] If the update of the PAN or identifier is successful, the payment / transaction applet may confirm 632 the success to the communication / authentication applet, which may forward the confirmation back toward server 116 ( Figure 6C 652).

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

[0139] Example embodiments of the systems and methods described herein may be configured to provide security factor authentication. Security factor authentication may include multiple processes. As part of security factor authentication, a first process may include logging in and authenticating a user via one or more applications executed on a device. As a second process, the user may participate in one or more behaviors associated with one or more contactless cards in response to successful login and authentication of the first process via the one or more applications. In practice, security factor authentication may include both securely proving the identity of the user and participating in one or more types of behaviors, including, but not limited to, one or more tap gestures associated with a contactless card. In some examples, the one or more tap gestures may include a user tapping a contactless card of the device. In some examples, the device may include a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process a received tap gesture.

[0140] In some examples, a contactless card can be tapped against a device (such as one or more computer kiosks or terminals) to verify identity in order to receive a transaction item, such as coffee, in response to a purchase. By using a contactless card, a secure method for proving identity in a loyalty program can be established. Proving identity securely, for example, to obtain rewards, coupons, special offers, etc., or to receive benefits is established in a manner different from simply scanning a barcode card. For example, an encrypted transaction can occur between a contactless card and the device, which can be configured to process one or more tap gestures. As described above, the one or more applications can be configured to verify the identity of the user and then enable the user to act or respond to it, for example, via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, health information, etc. can be written back to the contactless card.

[0141] In some examples, a contactless card may be tapped against a device (such as a mobile device). As described above, the user's identity may be verified by the one or more applications, which then grant the user desired benefits based on the verification of the identity.

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

[0143] In some embodiments, a dedicated application may be configured to execute on a client device to perform activation of a contactless card. In other embodiments, a website portal, a web-based application, a small application, etc. may perform activation. Activation may be performed on a client device, or the client device may only serve as a middleman between a 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 that performs activation (e.g., a personal computer, a smart phone, a tablet, or a point of sale (POS) device). In addition, the application may output different and / or additional data for transmission to the account server according to the type of device involved. For example, such data may include information associated with a merchant (such as merchant type, merchant ID), and information associated with the device type itself (such as POS data and POS ID).

[0144] In some embodiments, the example authentication communication protocol can mimic the offline dynamic data authentication protocol of the EMV standard that is usually performed between the transaction card and the point of sale device with some modifications. For example, because the example authentication protocol is not used to complete the payment transaction with the card issuer / payment processor itself, some data values ​​are not required, and the authentication can be performed without involving a real-time online connection to the card issuer / payment processor. As known in the art, the point of sale (POS) system submits the transaction including the transaction value to the card issuer. Whether the issuer approves or rejects the transaction can be based on whether the card issuer recognizes the transaction value. At the same time, in certain embodiments of the present disclosure, the transaction originating from the mobile device does not have a transaction value associated with the POS system. Therefore, in some embodiments, a fictitious transaction value (i.e., a value that is recognizable by the card issuer and sufficient to allow activation to occur) can be passed as part of the example authentication communication protocol. POS-based transactions can also reject transactions based on the number of transaction attempts (e.g., transaction counters). The number of attempts exceeding the buffer value can result in a soft rejection; a soft rejection requires further verification before accepting the transaction. In some implementations, the buffer value for the transaction counter can be modified to avoid rejecting legitimate transactions.

[0145] In some examples, contactless cards can selectively transmit information based on the recipient device. Once tapped, the contactless card can identify the device that was tapped, and based on the identification, the contactless card can provide appropriate data for the device. This advantageously allows the contactless card to transmit only the information required to complete the immediate action or transaction (such as payment or card authentication). By limiting the transmission of data and avoiding the transmission of unnecessary data, both efficiency and data security can be improved. The identification and selective communication of information can be applied to a variety of scenarios, including card activation, balance transfers, account access attempts, commercial transactions, and step-up fraud reduction.

[0146] If the contactless card tap is for a device running Apple If the device has an operating system (such as iPhone, iPod or iPad), the contactless card can be recognized The operating system transmits the appropriate data to communicate with the device. For example, a contactless card may provide the encrypted identity information necessary to authenticate the card using an NDEF tag via, for example, NFC. Similarly, if a contactless card tap is for a running Devices that operate the system (e.g. smartphone or tablet), the contactless card can be recognized operating system, and transmits appropriate data to communicate with the device (such as encrypted identity information necessary for authentication via the methods described herein).

[0147] As another example, a contactless card tap can be directed to a POS device, including, but not limited to, a kiosk, a checkout register, a payment station, or other terminal. Once the tap is performed, the contactless card can identify the POS device and transmit only the information necessary for the action or transaction. For example, once a POS device is identified for completing a commercial transaction, the contactless card can transmit the payment information necessary to complete the transaction in accordance with the EMV standard.

[0148] In some examples, a POS device participating in a transaction may require or specify additional information to be provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, once the POS device receives data communications from a contactless card, the POS device may recognize the contactless card and request additional information necessary to complete the action or transaction.

[0149] In some examples, the POS device may be affiliated with an authorized merchant, or other entity familiar with certain contactless cards or accustomed to performing certain contactless card transactions. However, it is understood that such an affiliation is not required to perform the described methods.

[0150] In some examples (such as shopping stores, grocery stores, convenience stores, etc.), a contactless card may be tapped against a mobile device, without having to open an application, to indicate a desire or intent to cover one or more purchases with one or more of reward points, loyalty points, coupons, special offers, etc., thereby providing the intent behind the purchase.

[0151] In some examples, the one or more applications may be configured to determine that it was initiated via one or more tap gestures of a contactless card such that the activation occurred at 3:51 PM and the transaction was processed or conducted at 3:56 PM to verify the user's identity.

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

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

[0154] In some examples, the device may include an application to split a bill or check payment between multiple individuals. For example, each individual may have a contactless card and may be a customer of the same issuing financial institution, but this is not necessary. Each of these individuals may receive a push notification via the application on their device to split the purchase. Rather than accepting only one card tap to indicate payment, other contactless cards may be used. In some examples, individuals with different financial institutions may have contactless cards to provide information to initiate one or more payment requests from the individual tapping the card.

[0155] The following example use cases describe examples of specific implementations of the present disclosure. These are intended for illustrative purposes only, not for limiting purposes. In one case, a first friend (payer) owes a second friend (payee) a sum of money. Instead of going to an ATM or requesting an exchange through a peer-to-peer application, the payer wishes to use a contactless card to make a payment via the payee's smartphone (or other device). The payee logs into the appropriate application on his smartphone and selects the payment request option. In response, the application requests authentication via the payee's contactless card. For example, the application outputs a display requesting the payee to tap his contactless card. Once the payee, with the application enabled, taps his contactless card against the screen of his smartphone, the contactless card is read and authenticated. Next, the application displays a prompt for the payee to tap his contactless card to send a payment. After the payee taps his contactless card, the application reads the card information and transmits the payment request to the payee's card issuer via an associated processor. The card issuer processes the transaction and sends a status indicator of the transaction to the smartphone. The application then outputs a status indicator of the transaction for display.

[0156] In another example scenario, a credit card customer may receive a new credit card (or debit card, other payment card, or any other card that needs to be activated) in the mail. Rather than activating the card by calling a provided phone number associated with the card issuer or visiting a website, the customer may decide to activate the card via an application on his or her device (e.g., a mobile device, such as a smart phone). The customer may select a card activation feature from an application menu displayed on a display of the device. The application may prompt the customer to tap his or her credit card against the screen. When the credit card is tapped against the screen of the device, the application may be configured to communicate with a server (such as a card issuer server that activates the customer's card). The application may then display a message indicating successful activation of the card. Card activation will then be complete.

[0157] The above methods may be implemented as instructions on a computer-readable medium or as part of a computing architecture. Figure 7The illustration illustrates an embodiment of an exemplary computing architecture 700 suitable for implementing various embodiments as previously described. In one embodiment, computing architecture 700 may include or be implemented as part of an electronic device, such as computer 701. The embodiments are not limited in this context.

[0158] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 700. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable instruction, an execution thread, a program, and / or a computer. For example, both an application running on a server and a server can be a component. One or more components can reside in a process and / or execution thread, and a component can be locally located on a computer and / or distributed between two or more computers. In addition, components can be coupled to each other through various types of communication media to coordinate operations. The coordination can involve a unidirectional or bidirectional exchange of information. For example, a component can transmit information in the form of a signal transmitted through a communication medium. The information can be implemented as a signal assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments can alternatively adopt data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0159] The computing architecture 700 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation via the computing architecture 700.

[0160] like Figure 7 As shown, computing architecture 700 includes a processing unit 702, a system memory 704, and a system bus 706. Processing unit 702 can be any of a variety of commercially available processors, including, but not limited to, and processor; application, embedded and security processors; and and Processors; IBM and Cell processor; Core(2) and Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as the processing unit 702 .

[0161] The system bus 706 provides an interface for system components including, but not limited to, the system memory 704 to the processing unit 702. The system bus 706 may be any of several types of bus structures that may be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may be connected to the system bus 706 via a slot architecture. Example slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Cardbus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0162] The computing architecture 700 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media that store logic. Examples of computer-readable storage media may include any tangible media that stores electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or non-writable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable code type, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable the operations described herein to be performed.

[0163] The system memory 704 may include various types of computer-readable storage media in the form of one or more higher-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, polymer memory (such as ferroelectric polymer memory), Osram memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, device arrays (such as redundant independent array of disks (RAID) drives) solid-state memory devices (e.g., USB memory, solid-state drives (SSDs), and any other type of storage medium suitable for storing information. Figure 7 In the illustrated embodiment shown, system memory 704 may include non-volatile memory 708 and / or volatile memory 710. A basic input / output system (BIOS) may be stored in non-volatile memory 708.

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

[0165] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, several 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 the messaging system 500.

[0166] A user may enter commands and information into the computer 701 through one or more wired / wireless input devices (e.g., a keyboard 736 and a pointing device such as a mouse 738). Other input devices may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus, a card reader, a dongle, a fingerprint reader, a glove, a graphic tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a track pad, a sensor, a stylus, etc. These and other input devices are typically connected to the processing unit 702 through an input device interface 740 coupled to the system bus 706, but may be connected through other interfaces such as a parallel port, an IEEE 694 serial port, a game port, a USB port, an IR port, etc.

[0167] A monitor 742 or other type of display device is also connected to the system bus 706 via an interface, such as a video adapter 744. The monitor 742 may be internal or external to the computer 701. In addition to the monitor 742, computers typically include other peripheral output devices, such as speakers, printers, and the like.

[0168] Computer 701 can operate in a networked environment using logical connections via wired and / or wireless communications with one or more remote computers, such as remote computer 744. Remote computer 744 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment appliance, peer device, or other common network node, and typically includes many or all of the elements described with respect to computer 701, but, for example, only memory / storage device 746 is illustrated for the purpose of simplicity. The depicted logical connections include wired / wireless connections to a local area network (LAN) 748 and / or a larger network (e.g., a wide area network (WAN) 750). Such LAN and WAN networking environments are common in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communication network, such as the Internet.

[0169] When used in a LAN networking environment, the computer 701 is connected to the LAN 748 through a wired and / or wireless communication network interface or adapter 752. The adapter 752 may facilitate wired and / or wireless communication with the LAN 748, which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 752.

[0170] When used in a WAN networking environment, the computer 701 may include a modem 754, or be connected to a communications server on the WAN 750, or have other means for establishing communications on the WAN 750 (such as through the Internet). The modem 754, which may be internal or external to a wired and / or wireless device, is connected to the system bus 706 via an input device interface 740. In a networking environment, program modules described with respect to the computer 701 or portions thereof may be stored in a remote memory / storage device 746. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0171] The computer 701 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged in wireless communications (e.g., IEEE 802.13 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth, among other technologies. TM Wireless technology. Therefore, the communication can be a predefined structure like a conventional network, or simply a peer-to-peer communication between at least two devices. W-Fi networks use radio technology called IEEE 802.13x to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE802.3 related media and functions).

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

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

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

[0175] The communication framework 810 can implement various network interfaces arranged to accept, communicate and connect to the communication network. The network interface can be considered as a special form of input and output interface. The network interface can adopt connection protocols, including, but not limited to, direct connection, Ethernet (e.g., fat, thin, twisted pair 10 / 100 / 1000 Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.8ax network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. In addition, multiple network interfaces can be used to participate in various communication network types. For example, multiple network interfaces can be used to allow communication through broadcast, multicast and unicast networks. If the processing requirements determine a larger amount of rate and capacity, the distributed network controller architecture can be similarly used to concentrate the communication bandwidth required by the client 802 and the server 804, load balance the communication bandwidth, and otherwise improve the communication bandwidth. The communication network can be any one or combination of wired and / or wireless networks, including, but not limited to, direct interconnections, secured 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), operating missions as nodes on the Internet (OMNI), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.

[0176] The components and features of the above-described apparatus may be implemented using any combination of discrete circuitry, application specific integrated circuits (ASICs), logic gates, and / or single chip architectures. In addition, where appropriate, the features of the apparatus may be implemented using a microcontroller, a programmable logic array, and / or a microprocessor, or any combination of the foregoing. Note that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0177] It will be appreciated that the exemplary devices shown in the above block diagrams may represent an example of a functional description of many possible implementations. Therefore, the division, omission or inclusion of block functions depicted in the accompanying drawings does not infer that the hardware components, circuits, software and / or elements used to implement these functions will necessarily be divided, omitted or included in the embodiments.

[0178] At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.

[0179] Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment. Furthermore, unless otherwise indicated, the above-described features are recognized as being usable together in any combination. Therefore, any features discussed individually may be combined with each other unless indicated that the features are incompatible with each other.

[0180] Generally referring to the symbols and nomenclature used in this document, the detailed descriptions herein can be presented in terms of program processes executed on a computer or computer network. These process descriptions and representations are used by those skilled in the art to more efficiently convey the substance of their work to other technical personnel in the field.

[0181] A process is generally conceived here as a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be noted, however, that all of these terms and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0182] In addition, the manipulations performed are often referred to in terms commonly associated with mental operations performed by a human operator, such as adding or comparing. Such capabilities of a human operator are not necessary, or in most cases desirable, in any of the operations described herein that form a part of one or more embodiments. Instead, the operations are machine operations. Useful machines for performing the operations of the various embodiments include general purpose digital computers or similar devices.

[0183] Some embodiments may be described using the expressions "coupled" and "connected," along with their derivatives. These terms are not necessarily intended to be synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0184] Various embodiments also relate to devices or systems for performing these operations. The device is specially constructed for the desired purpose, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The processes presented herein are not inherently related to a specific computer or other device. Various general-purpose machines may be used with programs written according to the teachings herein, or it may prove convenient to construct more specialized devices that perform the desired method steps. The required structure for a variety of these machines will appear from the given description.

[0185] It is emphasized that the abstract of the present disclosure is provided so that the reader can quickly ascertain 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. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the present disclosure. This method of the present disclosure is not to be interpreted as reflecting the intention that the claimed embodiment requires more features than the features explicitly recited in each claim. On the contrary, as reflected in the claims, the subject matter of the invention lies in less features than all the features of the disclosed single embodiment. Therefore, the claims are hereby incorporated into the detailed description, and each claim represents a separate embodiment alone. In the appended claims, the terms "including" and "wherein" are used as the plain English equivalents of the corresponding terms "including" and "wherein", respectively. Moreover, the terms "first", "second", "third", etc. are used only as labels, and are not intended to impose numerical requirements on their objects.

[0186] What has been described above includes examples of the disclosed architecture. Of course, it is not possible to describe every conceivable combination of components and / or methods, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Therefore, the novel architecture is intended to embrace all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A contactless card, include: processor circuit; a memory coupled to the processor circuit, the memory being configured to store: a first applet configured to store a first account number for the contactless card in the memory, the first account number identifying an account number associated with the contactless card to perform a transaction; a second applet, the second applet being different from the first applet and configured to interact with an application of the device, wherein the second applet: receiving from the device an instruction to change the first account; causing the contactless card to generate a cryptogram with a diversified key by applying a first algorithm with a first diversified key to a shared secret to generate a result, and applying a second algorithm with a second diversified key to the result and random data to generate a cryptogram, The password generated by the contactless card is transmitted to the authentication server, and receiving an authentication approval from the authentication server to authenticate the contactless card; In response to authentication of the contactless card, transmitting to the first applet a command to change the first account to a second account, wherein the command to change the first account to the second account is sent in response to the contactless card being tapped against the device in a predetermined pattern; and In response to the command, the first applet changes the first account to the second account.

2. The contactless card of claim 1, wherein the first applet sets a second account number to perform transactions in place of the first account number.

3. The contactless card of claim 1, wherein the first applet selects the second account from a plurality of accounts in a memory.

4. The contactless card of claim 1, wherein the first applet generates the second account number as a new account number. 5 . The contactless card of claim 1 , wherein the instruction to change the first account number is received from the device via near field communication (NFC).

6. The contactless card according to claim 5, in, The processor circuit establishes an NFC connection with the device via an NFC exchange initiated in response to the contactless card entering an NFC communication range of the device.

7. The contactless card of claim 1, comprising a display, and the processor circuit is configured to cause the display to display an identification number derived from the first account number.

8. The contactless card of claim 7, the processor circuit being responsive to changing the first account number to a second account number to update the display with a second identification number derived from the second account number.

9. The contactless card according to claim 1, in, The predetermined pattern is based on the number of times a contactless card is tapped on the device within a predefined time limit.

10. The contactless card according to claim 1, in, The predetermined pattern is based on a ratio of the number of times a contactless card is tapped on the device.

11. The contactless card according to claim 1, in, The predetermined mode is based on a near field communication exchange with the device to perform an authentication operation, an encryption operation, or a combination thereof.

12. A computer-implemented method for changing an account number on a contactless card using a secure applet, include: storing, by a first applet of the contactless card, a first account number in a memory of the contactless card, the first account number being configured to identify an account number associated with the contactless card for transactions; receiving, from a device via a second applet of the contactless card, an instruction to change the first account number, wherein the second applet is different from the first applet; The contactless card generates a password, transmits the password generated by the contactless card to an authentication server, and receives an authentication approval from the authentication server to authenticate the contactless card. In response to authenticating the contactless card, transmitting, by the second applet, a command to change the first account to a second account, wherein the command to change the first account to the second account is sent in a predetermined pattern in response to tapping a contactless card against the device; as well as By means of the first applet and in response to the command, the first account is changed to a second account, The password with the diversified key is generated by applying a first algorithm with a first diversified key to a shared secret to generate a result, and applying a second algorithm with a second diversified key to the result and random data to generate the password.

13. The computer-implemented method of claim 12, comprising setting, via the first applet, a second account to perform transactions in place of the first account.

14. The computer-implemented method of claim 13, comprising selecting, by the first applet, the second account from a plurality of accounts to set up the second account to perform the transaction.

15. The computer-implemented method of claim 13, generating, by the first applet, the second account as a new account and setting the second account to perform transactions.

16. The computer-implemented method of claim 12, include: An NFC communication channel is established with the mobile device by the second applet through an NFC exchange initiated in response to the contactless card entering the NFC communication range of the device, and wherein the instruction to change the first account received from the device is communicated via NFC communication of the near field communication NFC channel.

17. The computer-implemented method of claim 12, comprising displaying an identification number derived from the first account number on a display of a contactless card.

18. The computer-implemented method of claim 17, comprising, in response to changing a first account to a second account, updating the display with a second identification number derived from the second account.

Images