CN113490952A - System and method for performing complementary distribution of contactless cards - Google Patents

Abstract

Example embodiments relate to reissuing or otherwise altering contactless cards. These embodiments are particularly suited for emergency reimbursements where many cards have been compromised due to data leakage from a host credit card provider or department store. An exemplary contactless card includes a chip that stores encrypted authentication information including 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. The second applet may be capable of interacting with external applications and may act as a bridge with the first applet. 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 interactable element).

Description

System and method for performing complementary distribution of contactless cards

Cross Reference to Related Applications

The present application claims priority from U.S. patent application No.16/731,178 filed on day 31, 12, 2019, a continuation-in-part application of U.S. patent application No.16/205,119 filed on day 29, 11, 2018, and U.S. provisional application No.62/740,352 filed on day 2, 10, 2018, the disclosures of which are hereby incorporated by reference in their entirety.

Technical Field

The present disclosure relates to authentication and authorization, and more particularly, to systems and methods for reissuing or otherwise altering information stored on a contactless card.

Background

Data leaks that reveal customer payment information are becoming more common and more widespread, with millions of credit card numbers being revealed in a given leak. When an unauthorized agent intrudes 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.), such data may be caused to leak.

Typically, credit card issuers can respond to such leakage by reissuing the affected card. This involves assigning a new credit card number to the user's account, creating a new physical card with the new number imprinted thereon, writing a new magnetic stripe, and placing the card in the mail. When leakage is common (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 make payments using their account, as it is possible that the card number is voided (to prevent unauthorized use of the account) when the leak is discovered. Obviously, this can be problematic for the customer.

Reissue processing can also be expensive from the perspective of the card issuer, which often absorbs the cost of creating and mailing new cards. Depending on the quality of the card material, the cost of creating a new card may be between $2 and $ 30. If the cards require urgent reissues, the additional processing cost may be $10 per card. When millions of card numbers have been compromised, the resulting reimbursement costs may amount to tens of millions of dollars.

Drawings

FIG. 1A depicts an environment suitable for use with the illustrative embodiments.

Fig. 1B depicts an example of a contactless card with a physical token.

Fig. 1C depicts the structure of an exemplary physical token.

Fig. 2A depicts an exemplary interface for a mobile application associated with an owner of a contactless card.

Fig. 2B depicts an exemplary interface when a physical token is read by a reader on the owner's mobile device.

Fig. 2C depicts an example of data exchange between a contactless card and a client device.

FIG. 2D depicts an exemplary data structure suitable for use with the illustrative embodiments.

FIG. 3 is a flow diagram illustrating key operations according to an example embodiment.

FIG. 4 is a diagram of a key system according to an example embodiment.

FIG. 5 is a flow diagram of a method of generating a password according to an example embodiment.

Fig. 6A is a flowchart illustrating a key diversification process according to an example embodiment.

Fig. 6B is a data flow diagram illustrating the exchange of communications in an exemplary embodiment.

Fig. 6C is a flow diagram depicting card-side logic for changing an identifier associated with a contactless card.

FIG. 7 depicts an exemplary computing system suitable for use with the illustrative embodiments.

FIG. 8 depicts an exemplary network environment suitable for use with the illustrative embodiments.

Detailed Description

Exemplary embodiments provide techniques for securely reissuing or otherwise altering information stored on a contactless card based on a remote command. Thus, the number associated with the card may be changed quickly so that the card may continue to be used with the new number. If the card has a number printed or embossed on its front face, the printed number (and/or the number stored on the magnetic strip) may not match the number stored on the contactless chip; nevertheless, the card may be used for contactless payment until a new card with a 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 may also be updated when the number stored on the contactless chip of the card is updated.

The chip of the card may include one or more applets that are activated in some cases. For example, when making a payment with a card, the payment applet may be activated and the number of the card may be supplied to the requesting device. The payment applet may need to be updated in order to use the card with the new number, but for security purposes the payment applet may be restricted from communicating directly with the external source. For this purpose, the chip may include a second encryption and authorization applet responsible for communicating card information to and from external sources. The second applet may perform authentication and may ensure that information transmitted from the payment applet is so conducted in a secure manner (e.g., using encryption). As described in more detail below, the second applet may also be responsible for performing authentication functions (e.g., authenticating an account stored on the card). According to an exemplary embodiment, this second applet may be made to act as a bridge between the external source and the payment applet, which causes the number on the payment applet to be overwritten based on secure (chip) internal communication.

In some cases, the second applet may be instructed directly to overwrite the card number with the new number. For example, a mobile device running an android operating system may issue a Near Field Communication (NFC) write command to the second applet to trigger the second applet to issue an override command to the payment applet. However, some devices may not support such communications (Apple's iOS is one such example). Thus, the second applet may also or alternatively be configured to recognize a predefined pattern that will cause an overwrite command to be issued. For example, a user may tap their contactless card five times in less than one minute for an NFC reader. Because tapping the NFC reader card triggers authentication and encryption operations of the second applet, the second applet may be pre-configured to recognize the predefined pattern and in response, issue a rewrite command.

In various embodiments, the card may have the ability to limit the number of number rewrites that may be performed (e.g., during the life of the card, or during a particular 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 allowable rewrites. The overwrite can be cancelled if a request to overwrite the number is received and the total number of requests (previous and current) exceeds the stored maximum value.

The following description of embodiments provides non-limiting representative examples of numbers that reference features and teachings that specifically describe various aspects of the present invention. From the description of the embodiments, it should be recognized that the described embodiments can be implemented alone or in combination with other embodiments. The description of the embodiments should facilitate an understanding of the invention to the extent that other implementations are not specifically contemplated, but within the knowledge of one 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.

FIG. 1A illustrates a data transmission environment 100 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. Although fig. 1A illustrates a particular configuration of components, those of ordinary skill in the art will appreciate that other configurations may be used including more or fewer components, or components in another configuration.

Environment 100 may include one or more contactless cards 130, which are further described below with reference to fig. 1B. In some examples, the contactless card 130 may communicate wirelessly with the client device 104, e.g., NFC communication. The contactless card may include a contactless chip (see fig. 1C). The contactless chip may maintain a copy of a Primary Account Number (PAN) associated with the card 130, which may be read by a reader, such as the NFC reader 110.

The environment 100 may include a client device 104, and the client device 104 may be a network-enabled computer. As referred to herein, network-enabled computers may include, but are not limited to: such as 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 telephone, a handheld PC, a Personal Digital Assistant (PDA), a thin client, a thick client, an internet browser, or other device). Client device 104 may also be a mobile device; for example, the mobile device may include an iPhone, an iPod, from

Or running Apple

Any other mobile device operating the system, running Microsoft Windows

Any device of a mobile operating system, and/or any other smart phone or similar wearable mobile device.

The client device 104 and/or the contactless card 130 may be associated with the user 102, and the user 102 may be the owner of the contactless card. The user 102 may define credentials for accessing mobile applications on the client device 104, which may be applications associated with a service provider of the contactless card.

In various examples according to the disclosure, the client device 104 of the environment 100 may execute one or more applications, such as software applications. The software application may enable network communication with one or more components of environment 100 and may transmit and/or receive data. Among other computer-executable logic, the client device 104 may include client-side reissue logic 112 (such as logic depicted in more detail in connection with fig. 6B).

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

To do so, the server 116 may instruct the client device 104 to change the PAN associated with the card 130 of the user 102. Client device 104 may receive the instruction and notify user 102 (e.g., via a display, such as the one depicted in fig. 2A-2B) that the card number is being reissued. Client device 104 may cause one or more applets stored on card 130 to be activated, such as by a express command (e.g., an NFC write command), or by requesting that user 102 tap card 130 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.) against NFC reader 110.

Instructions to change PANs may be sent from the server 116 on a personalized basis (e.g., when the cards 130 of a single user 102 are compromised), or complementary instructions may be broadcast to a group of recipients (which may be done in the event of a large data leak).

In some embodiments, the client 104 (or another device that instructs the card 130 to change the PAN) may issue a change instruction to the card 130 in coordination with the server 116. For example, server 116 may provision a PAN to be used on card 130, which client 104 may communicate to the communication logic/applet on card 130. In another example, the payment logic/applet on the card 130 may be pre-programmed with multiple PANs, and the server 116 may identify which PANs to use (or, if the PANs are arranged in a list in the memory of the card, the 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 the user 102 or the user's account at the financial institution), and the server 116 may provide instructions on how to derive the new PAN, or may provide a seed number to be used in generating the new PAN.

If client device 104 is able to send a write request directly to 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 used to derive the new PAN, or a seed for the 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 the communication logic/applet on the card 130 is configured to recognize a predetermined tap pattern as an instruction to change the PAN, as noted above, different patterns may be associated with different change instructions. For example, if the user taps the card 130 five times in less than one minute against the NFC reader 110, this may be interpreted as an instruction to proceed to the next PAN stored in the list. On the other hand, if the user taps the card 130 only four times in less than one minute against the NFC reader 110, 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 the appropriate instructions on a user interface. If multiple different patterns are programmed into the communication logic/applet on the card 130, the device 104 may request the user to confirm the pattern to ensure that the correct pattern is used (e.g., by asking the user to tap in a predetermined pattern, wait briefly, and then ask the user to confirm the change by again tapping in the same predetermined pattern).

Once the PAN is changed, the communication logic/applet on the card 130 may report success back to the server 116. The success may 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 may be voided and the process may be repeated. Alternatively, the server 116 may simply accept the PAN reported by the card 130.

In some examples, the server 116 may include one or more processors coupled to a memory. The server 116 may be configured as a central system, server, or platform that controls and invokes various data at different times to perform a plurality of workflow actions.

Fig. 1B illustrates one or more contactless cards 130, and the contactless cards 130 may include payment cards, such as credit cards, debit cards, or gift cards issued by a service provider 132 and displayed in front of or behind the cards 130. In some examples, the contactless card 130 is independent of a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual interface contactless payment card. Contactless card 130 may include a substrate 134, and substrate 134 may include a single layer or one or more laminate 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 that conform to the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may otherwise conform to the ISO/IEC 14443 standard. However, it is understood that contactless cards 130 according to the present disclosure may have different characteristics, and the present disclosure does not require that contactless cards be implemented in payment cards.

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 employing 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 the 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. This allows the e-ink display 149 to be changed to match the new number assigned to the applet on the card 130, as discussed herein.

The contactless card 130 may further include contact pads 138. The contact pad 138 may be configured to establish contact with another communication device, such as a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 130 may also include processing circuitry, an antenna, and other components not shown in fig. 1C. These components may be positioned behind the contact pads 138 or elsewhere on the substrate 134. The contactless card 130 may also include a magnetic strip or tape (not shown in fig. 1B) that may be positioned behind the card.

As shown in fig. 1C, the contact pads 138 of fig. 1B 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 processing circuitry 140 may contain additional components necessary to perform the functions described herein, including a processor, memory, error and parity/CRC checkers, data encoders, collision avoidance algorithms, controllers, command decoders, security primitives, and tamper-resistant hardware.

The memory 144 may be a read-only memory, a read-once-write-many memory, or a read/write memory, such as RAM, ROM, and EEPROM, and the contactless card 500 may include one or more of these memories. The read only memory may be factory programmable as read only or one time programmable. One-time programming provides the opportunity to write once and then be read multiple times. The write once/read many times memory may 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 multiple times. The read/write memory may be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times.

The memory 144 may be configured to store one or more applets 146, one or more counters 108, and a client identifier 148. The one or more applets 146 can include one or more software applications, such as Java card applets, configured to execute on one or more contactless cards. However, it is understood that the applet 146 is not limited to a Java card applet, but may be any software application operable on a contactless card or other device having limited memory. The one or more counters 108 may include a numerical counter sufficient to store an integer. The customer identifier 148 may include a unique alphanumeric identifier assigned to the user of the contactless card 130 that may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 148 may identify both the customer and an account assigned to the customer, and may further identify a contactless card associated with the customer's account.

The applet 146 may include a payment applet configured to conduct payment transactions with the card 130. The payment applet may be responsible for maintaining or may use the card's Primary Account Number (PAN), which may be transferred from the card as part of a transaction. The applet 146 may further include an authentication and/or encryption applet that is invoked when an external source (such as the client device 104, point-of-sale terminal, automated teller machine, etc.) attempts to establish communication with the card 130 (such as when the contact pad 138 is placed in close proximity or proximity to a reader, such as the NFC reader 110). The payment applet may not communicate directly with an external source (i.e., a source external to the processing circuitry 140), but may be able to securely communicate with another applet on the processing circuitry 140, such as an authentication and encryption applet. Information may be passed from the payment applet to the authentication and encryption applet for off-card communication.

Alternatively, the payment applet may pre-load (e.g., when the card is issued) predefined PANs, one of which is designated as the currently active PAN, with the remaining PANs remaining on standby. 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 PAN generation rules, or may generate a new PAN based on a previous PAN.

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

In some examples, contactless card 130 may include one or more antennas 150. The one or more antennas 150 may be placed within the contactless card 130 around the processing circuitry 140 of the contact pads 138. For example, the one or more antennas 150 may be integrated with the processing circuitry 140, and the one or more antennas 150 may be used with an external boost coil. As another example, the one or more antennas 150 may be external to the contact pads 138 and the processing circuitry 142.

In an embodiment, the coil of the contactless card 130 may act as the secondary of an air-core transformer. The terminal may communicate with the contactless card 130 by cutting off power or amplitude modulation. Contactless card 130 may use the gap to infer data transmitted from the terminals when the contactless card is connected to a power supply, which may be functionally maintained by one or more capacitors. The contactless card 130 may communicate back by switching the load or load modulation on the contactless card's coil. The load modulation can be detected by interference in the coils of the terminals.

As explained above, the contactless card 130 may be built on a software platform operable on a smart card or other device with limited memory (such as a JavaCard), and one or more applications or applets may be securely executed. Applets may be added to contactless cards to provide one-time passwords (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may be configured to respond to one or more requests, such as near field data exchange requests (NDEFs), from a reader, such as a mobile NFC reader, and generate a NDEF message that includes a cryptographically secure OTP encoded as a NDEF text tag.

As noted above, an exemplary transaction may verify, via logic 112 executing on client device 104, a requested transaction for an account associated with a contactless card. 2A-2B depict exemplary interfaces that may be presented on a client device in response to the logic.

Fig. 2A depicts an initial interface 200 for an application associated with a card (e.g., an application provided by a card provider), which initial interface 200 may be displayed on client device 104 when client device 104 receives an instruction from server 116 to replenish the card, or otherwise reconfigure or change the information stored on the card. The interface 200 includes a message area 202, the message area 202 displaying information regarding reissuing of card information. The message area 202 may illustrate, for example, the user's card has been redeployed, why redeployment has occurred, and the next steps required by the user to change the card's information.

The interface 200 may further include an interactable element 204. To change the information stored on the card, the user may optionally first be asked to select the interactable 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 in proximity to the NFC reader).

Upon selection of the interactable element, as shown in fig. 2B, the user can overwrite 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 PAN of the card has been successfully changed, a confirmation message 206 may be displayed indicating that the information of the card has been successfully rewritten.

As an alternative to the process shown in fig. 2A-2B, the user may be prompted (in interface 200) to tap their card on the NFC reader of the client device in a predetermined pattern. The authentication and encryption applet may register the predetermined pattern.

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

As shown in fig. 2B, 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 several payment options for the card can all be used. Nevertheless, the contactless payment functionality of the card may still be used with the information stored on the chip while the card is being sent to the user. If the card includes an e-ink display, the e-ink display may be updated as the PAN is rewritten, as indicated above, 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 is primarily using the card for contactless payment.

Fig. 2C is a timing diagram illustrating an example sequence for providing authenticated access in accordance with one or more embodiments of the present disclosure. The system may include a contactless card 130 and a client device 104, and the client device 104 may include an application (which may include logic 112) and a processor.

At 202, the application communicates with the contactless card 130 (e.g., after being brought into proximity of 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.

At 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 may occur when contactless card 130 is read by an application of managed logic 112. In particular, this may occur when a near field data exchange (NDEF) tag is read (such as an NFC read), which may be created according to an NFC data exchange format. For example, a reader (such as logic 112) may transmit a message, such as an applet selection message, with an applet ID that generates the NDEF for the applet. When a selection is confirmed, a sequence of selecting file messages followed by reading file messages may be transmitted. For example, the sequence may include "select capability file", "read capability file", and "select NDEF file". At this point, the counter value maintained by the contactless card 130 may be updated or incremented, which may be followed by "reading the NDEF file". At this time, a message may be generated that may include a header and a shared secret. A session key may then be generated. The MAC password may be created from a message that may include a header and a shared secret. The MAC cipher may then be concatenated with random data of one or more blocks, and the MAC cipher and Random Number (RND) may be encrypted with a session key. Thereafter, the password and header may be concatenated, encoded as ASCII hexadecimal, and returned in NEDF message format (in response to the "read NDEF file" message).

In some examples, the MAC password may be transmitted as an NDEF tag, in other examples, the MAC password may be included with a uniform resource indicator (e.g., as a formatted string).

In some examples, logic 112 may be configured to transmit a request to contactless card 130, the request including an instruction to generate a MAC password.

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

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

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

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

In some examples, the MAC password may be used as a digital signature for authentication purposes. Other digital signature algorithms (such as public key asymmetric algorithms, e.g., digital signature algorithm and RSA algorithm) or zero-knowledge protocols may be used to perform this verification.

Fig. 2D depicts an exemplary technique for generating a protected message 230 according to an exemplary embodiment.

The message 230 may be configured to deliver information or content from a sender to a recipient. The information or content may be represented in message plaintext 234 (although the content may optionally be encrypted).

The message plaintext 234 may be combined with the shared secret 232. The shared secret 232 may be a random number known to both the sender and the recipient. For example, if the message plaintext 234 is associated with 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 the chip on the card and the transaction verification server. In one embodiment, the random number may be a 32-bit random number. Alternatively or additionally, the communication session may be set by the sender and the recipient; the process of setting up the communication session may involve sharing a random number between the sender and the recipient, which may be used as the shared secret 232.

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.

When a recipient (e.g., a receiving server) retrieves the combined MAC data, the recipient may consult its version of the shared secret 232 and may perform the process for combining the MAC data with the shared secret in reverse (e.g., divide by the combined MAC data and shared secret 232 to retrieve the original MAC data).

One 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 illustrative embodiments.

After the message plaintext 234 and the shared secret 232 are combined, they may be provided to the 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.

The 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 the 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 a first diversified key 250. Using the first diversified key 250 and the combined shared secret/plaintext, the MAC algorithm 236 may generate a MAC output 238.

The MAC output 238 may optionally be encrypted with an encryption algorithm 240 to produce an encrypted MAC 242. The 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.

In some embodiments, the MAC output 238 may be truncated and/or combined with the random data 254. For example, in one embodiment, the beginning of the MAC output 238 may be discarded such that, for example, only the last 8 bytes are retained. The remainder of the MAC output 238 may be combined with the 8 bytes of the randomly generated data 254. When the recipient receives the message 300, the recipient may decrypt the 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 with the data remaining from the encrypted MAC 242 received as part of the message 230.

The encryption algorithm 240 may operate using a key. In an exemplary embodiment, the key may be a second diversified key 252 created using 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 a second diversified key 252. Using second diversification key 252 and MAC output 238, encryption algorithm 240 may generate encrypted MAC 232, and encrypted MAC 232 may be included in the header of message 230.

Encrypted MAC 232 may be transmitted along with 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 (e.g., a server) when authenticating the message. The shared secret 232 is not sent directly as part of the message.

Fig. 3 is a flow diagram illustrating a key operation 300 according to an example embodiment. As shown in fig. 3, two Bank Identifier Number (BIN) -level master keys may be used in conjunction with an account identifier and a card serial number to generate two Unique Derivative Keys (UDKs) per card at block 310. In some examples, the bank identifier number may include one or a combination of one or more digits, such as an account number or an unpredictable number provided by one or more servers, that may be used for session key generation and/or diversification. UDKs (authkey and ENCKEY) may be stored on the card during the personalization process.

At block 320, the counter may be used as diversification data because it changes with each use and each time provides a different session key, completely different from the master key derivation in which each card generates a unique set of keys. In some instances, it is preferable to use a 4 byte approach for both operations. Thus, at block 320, two session keys may be created from the UDK for each transaction, i.e., one session key from authkey and one session key from ENCKEY. In the card, for the MAC key (i.e., the session key created from authkey), the lower two bytes of the OTP counter may be used for diversification. For ENC keys (i.e., session keys created from ENCKEY), the entire length of the OTP counter may be used for the ENC key.

At block 330, a MAC password may be prepared using the MAC key and may be encrypted using the ENC key. For example, the MAC session key may be used to prepare a password, and the result may be encrypted with the ENC key before being transmitted to the one or more servers.

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 cipher is performed prior to authentication of the MAC. The session keys are independently derived at the one or more servers, resulting in a first session key (ENC session key) and a second session key (MAC session key). The second derived key (i.e., the ENC session key) may be used to decrypt the data, and the first derived key (i.e., the MAC session key) may be used to verify the decrypted data.

For contactless cards, a different unique identifier is derived, which may be related to the application Primary Account Number (PAN) and PAN serial number encoded in the card. Key diversification may be configured to receive as input an identifier along with a master key, such that for each contactless card, one or more keys may be created. In some examples, the diversified keys may include a first key and a second key. The first Key may comprise an authentication master Key (Card password generation/authentication Key — Card-Key-Auth), and may be further diversified to create a MAC session Key used in generating and verifying a MAC password. The second Key may comprise an encryption master Key (Card-data encryption Key-DEK), and may be further diversified to create ENC session keys for use in encrypting and decrypting cryptographically encrypted data. In some examples, the first and second keys may be created by diversifying the issuer master key by combining it with the card's unique ID number (plid) and the PAN Serial Number (PSN) of the payment applet. The pUID may include a 16-bit value. As explained above, the plid may include a 16-digit BCD encoded number. In some examples, the plid may include a 14-bit value.

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

In other examples, such as credit cards, numbers (such as account numbers or unpredictable numbers provided by one or more servers) may be used for session key generation and/or diversification.

FIG. 4 illustrates a diagram of a system 400 configured to implement one or more embodiments of the present disclosure. As explained below, two cryptographic keys may be uniquely assigned to each card during the contactless card creation process. The cryptographic keys may include symmetric keys that may be used in both data encryption and decryption. The triple DES (3DES) algorithm can be used by EMV and it is implemented by hardware in contactless cards. 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 the key.

With respect to 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 comprise an issuer crypto-generation/authentication Key (Iss-Key-Auth), and the second master Key 410 may comprise an issuer data encryption Key (Iss-Key-DEK). As further explained herein, the two issuer master keys 405, 410 are diversified as card master keys 425, 430, which are unique to each card. In some examples, the network profile record id (pnpr)415 and derivative key index (pDKI)420, as background office data, may be used to identify which issuer master keys 405, 410 are used for authentication in the cryptographic process. The system performing the authentication may be configured to retrieve the values of pNPR 415 and pDKI 420 for the contactless card at the time of authentication.

In some examples, to improve the security of the solution, instead of using a master key, a session key (such as a unique key per session) may be derived, as explained above, a unique card derived key and counter may be used as the diversification data. For example, each time the card is used in operation, a different key may be used to create a Message Authentication Code (MAC) and perform encryption. With respect to session Key generation, the keys used to generate the password and to cipher the data into the password in one or more applets may include session keys based on Card unique keys (Card-Key-Auth 425 and Card-Key-Dek 430). The Session keys (Aut-Session-Key 435 and DEK-Session-Key 440) may be generated by the one or more applets and derived using one or more algorithms using an application transaction counter (pATC) 445. To place the data into one or more algorithms, only the 2 lower bytes of the 4-byte pATC 445 are used. In some examples, a four byte session key derivation method may include: f1: ═ PATC (2 bytes low) | 'F0' | | '00' | PATC (four bytes) F1: ═ PATC (2 bytes low) | '0F' | | '00' | PATC (four bytes) SK { (ALG (MK) [ F1]) | ALG (MK) [ F2] }, where ALG may comprise 3DES ECB, MK may comprise the card-uniquely derived master key.

As described herein, the lower two bytes of the pATC 445 counter may be used to derive one or more MAC session keys. Upon each tap of the contactless Card, the pATC 445 is configured to be updated, and the Card master KEYs 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 may be initialized to zero at personalization or applet initialization. In some examples, the pATC counter 445 may be initialized at or before personalization and may be configured to increment by 1 each time NDEF reads.

Further, updates to each card may be unique and either assigned through personalization or algorithmically assigned through the 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, the updates may also read changes in order, such that one card may be repeated in order increments of 1, 3, 5, 2, … …. The specific sequence or algorithm sequence may be defined at personalization or from one or more processes derived from the unique identifier. This may make it more difficult for a replay attacker to generalize from a few card instances.

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

The MAC may be performed by a function Key (AUT-Session-Key) 435. The data specified in the password may utilize javacard. ALG _ DES _ MAC8_ ISO9797_1_ M2_ ALG3 for processing in connection with EMV ARQC verification method. As explained above, the Key used for this calculation may include the Session Key AUT-Session-Key 435. As explained above, the lower two bytes of the counter may be used to diversify one or more MAC session keys. As explained below, the AUT-Session-Key 435 may be used for the MAC data 450, and the resulting data or password a 455 and random number RND may be encrypted using the DEK-Session-Key 440 to create password B or an output 460 sent in a message.

In some examples, one or more HSM commands may be processed for decryption such that the final 16 (binary, 32 hexadecimal) bytes may include 3DES symmetric encryption using a CBC mode with a random number of zero IV followed by 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.

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

Another exemplary format is shown below. In this example, the tag may be encoded in hexadecimal format.

The UID field of the received message may 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-DEK 410. 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 may be used to decrypt the password B460, which results in password A455 and RND, which may 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 through the cryptographic MAC using the recreated Aut-Session-Key to create a MAC output, such as MAC'. If MAC' is the same as password A955, this indicates that both message decryption and MAC verification have passed. Then, pATC can be read to determine if it is valid.

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 a 3DES MAC by using ISO 9797-1 algorithm 3 with method 2 padding via one or more Session keys (such as Aut-Session-Key 435). The input data 450 may take the form of: version (2), uid (8), pATC (4), shared secret (4). In some examples, the number in parentheses may include the length of a byte. In some examples, the shared secret may be generated by one or more random number generators, which may be configured to ensure that the random numbers are unpredictable through one or more security processes. In some examples, the shared secret may include a random 4-byte binary number that is injected into the card at personalization time and known to the authentication service. The shared secret may not be provided from the one or more applets to the mobile application during the authentication session. Method 2 padding may include adding a mandatory 0x '80' byte to the end of the input data and adding 0x '00' bytes, which may be added to the end of the resulting data up to an 8-byte boundary. The resulting password may comprise 8 bytes long.

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

By including the application transaction counter (pATC) as part of the data included in the MAC password, the authentication service may be configured to determine whether the value passed in the clean data has been tampered with. Moreover, by including versions in the one or more passwords, it is difficult for an attacker to deliberately mislead the application versions in an attempt to reduce the advantages of the cryptographic solution. In some examples, pATC may start from zero and be updated with 1 each time one or more applications generate authentication data. The authentication service may be configured to track pATC used during the authentication session. In some examples, when the authentication data uses pATC that is equal to or lower than the previous value received by the authentication service, this may be interpreted as an attempt to replay the old message, and authentication may be denied. In some examples, where pATC is greater than the previous value received, this may be evaluated 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 may be deemed to have failed or be unreliable. In MAC operation 436, data 450 is processed by MAC using Aut-Session-Key 435 to generate MAC output (password a)455, MAC output (password a)455 being encrypted.

In order to provide additional protection against brute force attacks that expose keys on the card, it is desirable that MAC password 455 be cryptographically deciphered. In some examples, data to be included in the cipher text or cipher a 455 may include: random number (8) and password (8). In some examples, the numbers in parentheses may include lengths in bytes. In some examples, the random numbers may be generated by one or more random number generators, which may be configured to ensure that the random numbers are unpredictable through one or more security processes. The key used to decrypt the data into a cipher may comprise a session key. For example, the Session Key may include the DEK-Session-Key 440. In encryption operation 441, the data or password A455 and RND are processed using the DEK-Session-Key 440 to generate encrypted data, password B460. In cipher block chaining mode, the data 455 may be ciphered using 3DES to ensure that an attacker must run any attack on all cipher text. Other algorithms, such as Advanced Encryption Standard (AES), may be used as non-limiting examples. In some examples, an initialization vector of 0 x' 0000000000000000 "may be used. Any attacker who tries to brute force the key used to cipher the data will not be able to determine when the correct key has been used because the correctly decrypted data will be indistinguishable from the incorrectly decrypted data due to its random occurrence.

In order for the authentication service to verify the one or more passwords provided by the one or more applets, the following data must be communicated in clear 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, which enables the method to change in the future; a pUID to retrieve the cryptographic asset and derive a card key; and pATC to derive a session key for the cipher.

Fig. 5 illustrates a method 500 for generating a password. For example, at block 510, a network profile record id (pnpr) and derived key index (pDKI) may be used to identify which issuer master keys are used in the cryptographic process for authentication. In some examples, the method may include performing authentication to retrieve values of pNPR and pDKI for the contactless card at the time of authentication.

At block 520, the issuer master key may be diversified by combining it with the unique ID number (plid) of the card and the PAN Serial Number (PSN) of one or more applets (e.g., payment applets).

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

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

Fig. 6 depicts an exemplary process 600 illustrating key diversification according to an example. Initially, two different master keys may be provisioned for the sender and the recipient. For example, the first master key may comprise a data encryption master key and the second master key may comprise a data integrity master key. The sender has a counter value that can be updated at block 602 and other data (such as data to be protected) that can be guaranteed to be shared with the recipient.

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.

In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted in the clear between the sender and the recipient, i.e., not encrypted.

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

At block 608, the sender may encrypt the data to be protected using the session key derived from the data encryption in conjunction with a symmetric encryption algorithm. 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).

At block 610, the encrypted MAC is transmitted from the sender to the recipient along with information sufficient to identify the appended secret information (such as a shared password, master key, etc.) for use in authenticating the password.

At block 612, the recipient uses the received counter values to independently derive two derived session keys from the two master keys as explained above.

At block 614, the protected data is decrypted using the session key derived from the data encryption in conjunction with a symmetric decryption operation. Additional processing on the exchanged data will then occur. In some instances, after the MAC is extracted, it may be desirable to reproduce and match the MAC. For example, when a password is authenticated, it may be decrypted using a properly generated session key. The protected data may be reconstructed for verification. A MAC operation may be performed using a properly generated session key to determine if it matches a 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.

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.

Some examples of the methods described herein may advantageously confirm when a successful authentication is determined when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key is appropriate. The MAC may only be correct if the decryption is successful and the proper MAC value is obtained. Successful decryption may 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., the transmitting device) and the recipient (e.g., the receiving device), the contactless card that originally created the MAC and encrypted the MAC may be trusted as being in fact. Also, the counter values used to derive the first and second session keys may be shown as valid and may be used to perform authentication operations.

Thereafter, both derived session keys may be discarded and the next data exchange iteration will update the counter values (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.

Fig. 6B depicts a timing diagram that shows an exemplary exchange of messages according to an embodiment. Fig. 6C depicts an exemplary flow diagram of logic 650 that illustrates the execution of an applet, logic or program on card 130, and is discussed in parallel with fig. 6B.

Beginning with fig. 6C, the payment/transaction applet may store one or more PANs for the card at block 652. The PAN may be written to the card when the card is initially issued. In some embodiments, the payment/transaction applet maintains the PAN or accesses it in a defined location in memory whenever a PAN is issued to the card. The payment/transaction applet may be able to write or rewrite the PAN, and may do so when a new PAN is needed. In other embodiments, multiple PANs may be issued to the card and may be stored in a list. One PAN (such as the first PAN in the list) may be designated as the active PAN for payment and transactions. When a new PAN is needed, the old PAN may be deleted and the next PAN in the list may become the active PAN; alternatively or additionally, a different PAN in the list may be designated as the current PAN.

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

For example, a user may install an application that allows the user to review their outstanding balance, make payments, etc., and a particular card of the user may be associated with the application based on an account/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.

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 number 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 do so. The user's old number or old identifier may be revoked before, during, or after the reissue message 620 is sent.

Upon receiving the reissue message, the application on client 104 may recognize that the PAN must be reissued. The application may be written with a number of techniques for transferring this information to the communication/authentication applet on the card in the reissue order or tap mode 622.

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. The techniques may be suitable for devices that are capable of issuing NFC write commands directly to applets on the card, such as those running the Android operating system.

Some operating systems, such as the iOS operating system, cannot issue NFC write commands directly to these applets. Thus, the application may be written with logic configured to cause the display device to give the user instructions to tap their card 130 to the NFC reader on the device 104 in a predetermined pattern. The logic may have a corresponding portion on the communication/authentication applet configured to recognize the predetermined pattern and interpret the pattern as a reissued PAN or identification number.

At 624, the communication/authentication applet on the card recognizes the instruction or pattern 622 and initiates the card change process (block 654 of fig. 6C).

First, at 626 (block 656 of FIG. 6C), the communication/authentication applet sets up a secure communication channel or secure form of data transfer between the communication/authentication applet and the payment/transaction applet. This communication channel may be built into the chip on the card 130 so that no express setup process is required, or may be a peer-to-peer communication channel or a form of data transfer that is setup on demand.

The communication/authentication applet may transmit the reissue command 628 to the payment/transaction applet over a secure communication channel (block 658 of figure 6C). In response, the payment/transaction applet may select a new identifier or PAN at 630 (block 660 of fig. 6C) (e.g., proceed 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 the server 116, as previously discussed.

The payment/transaction applet may determine whether the change in identifier or PAN was successful (e.g., whether a new PAN meeting certain predefined requirements has been generated). 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 a failure to the communication/authentication applet (block 652 of figure 6C). The chip of the card may optionally be revoked at this time for performing the transaction.

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 the server 116 (block 652 of FIG. 6C).

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

Example embodiments of the systems and methods described herein may be configured to provide security factor authentication. Security factor authentication may include a number of processes. As part of the security factor authentication, the first process may include logging in and authenticating the user via one or more applications executing on the device. As a second process, the user may engage in one or more activities 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 a user and engaging in one or more types of behavior 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 tap of a contactless card of the device by a user. 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.

In some examples, a contactless card may be tapped on 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 contactless cards, a secure method of proving identity in a loyalty programme can be established. Securely certifying identity, e.g., to obtain rewards, coupons, specials, etc., or accepting benefits is established in a manner other than just scanning a bar code card. For example, an encrypted transaction may occur between the contactless card and the device, which may be configured to process one or more tap gestures. As explained above, the one or more applications may be configured to verify the identity of the user and then have the user act or respond to it, e.g., via one or more tap gestures. In some examples, data such as bonus points, loyalty points, reward points, healthcare information, and the like may be written back to the contactless card.

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

In some examples, a contactless card may be activated by tapping the contactless card on a device (such as a mobile device). For example, a contactless card may communicate with an application of the device via a card reader of the device through NFC communication. The communication in which a tap of a card in proximity to a card reader of the device may allow an application of the device to read data associated with a contactless card and activate the card. In some examples, activation may authorize the card to be used to perform other functions, such as purchasing, accessing an account or restricted information, or other functions. In some examples, tapping may activate or launch an 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, a tap of the contactless card proximity card reader may initiate a download of the application, such as navigating to a download page of the application. After installation, tapping of the contactless card may activate or launch the application and then initiate activation of the contactless card, e.g., via the application or other backend communication. After activation, the contactless card may be used in a variety of activities, including, but not limited to, commercial transactions.

In some embodiments, a dedicated application may be configured to execute on the client device to perform activation of the contactless card. In other embodiments, a web portal, web-based application, applet, or the like may perform the activation. The activation may be performed on the client device, or the client device may simply act as an intermediary between the contactless card and an external device (e.g., an account server). According to some embodiments, upon providing the activation, the application may indicate to the account server the type of device performing the activation (e.g., personal computer, smartphone, tablet, or point of sale (POS) device). Furthermore, the application may output different and/or additional data for transmission to the account server depending on the type of device involved. For example, such data may include information associated with the merchant (such as merchant type, merchant ID), as well as information associated with the device type itself (such as POS data and POS ID).

In some embodiments, the example authentication communication protocol may emulate an offline dynamic data authentication protocol of the EMV standard, with some modifications, that is typically implemented between the transaction card and the point-of-sale device. For example, because the example authentication protocol is not used to complete a payment transaction with the card issuer/payment processor itself, some data values are not required, and authentication may be performed without involving an online connection in real time to the card issuer/payment processor. As is known in the art, a point of sale (POS) system submits a transaction, including a transaction value, to a card issuer. Whether the issuer approves or denies the transaction may be based on whether the card issuer recognizes the transaction value. Also, in certain embodiments of the present disclosure, the transaction originating from the mobile device has no transaction value associated with the POS system. Thus, in some embodiments, dummy transaction values (i.e., values recognizable by the card issuer and sufficient to allow activation to occur) may be communicated as part of an example authentication communication protocol. POS-based transactions may also deny the transaction based on the number of transaction attempts (e.g., transaction counters). The number of attempts to exceed the buffer value may result in a soft rejection; the soft reject requires further verification before accepting the transaction. In some implementations, the buffer value for the transaction counter may be modified to avoid rejecting legitimate transactions.

In some examples, the contactless card may selectively communicate information based on the recipient device. Once tapped, the contactless card can identify the device for which the tap is directed, and based on that identification, the contactless card can provide the appropriate data for that device. This advantageously allows the contactless card to transmit only the information needed to complete an instant action or transaction, such as payment or card authentication. By limiting the transmission of data and avoiding unnecessary transmission of data, both efficiency and data security may be improved. The identification and selective communication of information may be applied in a variety of scenarios, including card activation, balance transfer, account access attempts, commercial transactions, and incremental fraud reduction.

If the contactless card tap is for running Apple

Operating system devices (e.g., iPhone, iPod, or iPad), in a contactless mannerThe card can be identified

Operating the system and communicating the appropriate data with the device. For example, the contactless card may provide encrypted identity information necessary to authenticate the card using the NDEF tag via, for example, NFC. Similarly, if the contactless card tap is for run

The device that operates the system (e.g.,

smart phone or tablet), the contactless card can be identified

The operating system and transmits appropriate data to communicate with the device (such as encrypted identity information necessary for authentication by the methods described herein).

As another example, the contactless card tap may be for a POS device, including, but not limited to, a kiosk, checkout register, payment station, or other terminal. As soon as 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, upon identifying a POS device for completing a commercial transaction, the contactless card may transmit payment information necessary to complete the transaction in accordance with the EMV standard.

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

In some examples, the POS device may be affiliated with an authorized merchant, or other entity that is familiar with or accustomed to performing certain contactless card transactions. However, understanding such membership is not required to perform the described methods.

In some examples (such as shopping stores, grocery stores, convenience stores, etc.), the contactless card may be tapped against the 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, specials, etc. Thus, the intention behind the purchase is provided.

In some examples, the one or more applications may be configured to determine that it was launched via one or more tap gestures of the contactless card such that launching occurs at 3:51 PM and a transaction is processed or conducted at 3:56 PM in order to verify the identity of the user.

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

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

In some examples, the apparatus may include an application to divide bills or check payments among multiple individuals. For example, each individual may own a contactless card and may be a customer of the same issuing financial institution, but this is not essential. Each of these individuals may receive push notifications on their devices via the application to divide purchases. Instead of accepting a single card tap to indicate payment, other contactless cards may be used. In some examples, individuals with different financial institutions may own contactless cards to provide information to initiate one or more payment requests from the card tap individual.

The following example use cases describe examples of particular implementations of the present disclosure. These are intended for illustrative purposes only and are not intended to be limiting. In one case, the first friend (payer) owes the second friend (payee) a sum of money. Instead of going to the ATM or requiring an exchange through a peer-to-peer application, the payer wishes to make a payment via the payee's smart phone (or other device) using a contactless card. The payee logs in to 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 output requests a display of the payee tapping his contactless card. Once the payee taps his contactless card against the screen of his smartphone with the application enabled, the contactless card is read and verified. The application then displays a prompt for the payer to tap his contactless card to send payment. After the payer taps his contactless card, the application reads the card information and, via an associated processor, transmits a payment request to the payer's card issuer. The card issuer processes the transaction and sends a status indicator of the transaction to the smartphone. The application then outputs for display a status indicator of the transaction.

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 requires activation) in the mail. Rather than activating the card by invoking 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 smartphone). The customer may select the card activation feature from an application menu displayed on the display of the device. The application may prompt the customer to tap his or her credit card against the screen. Upon tapping the credit card 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.

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

As used in this application, the terms "system" and "component" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution, examples of which are provided by the exemplary computing architecture 700. For example, a component may be, but is not limited to being, a process running on a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Further, the components may be coupled to each other by various types of communication media to coordinate operations. The coordination may involve a unidirectional or bidirectional exchange of information. For example, a component may communicate information in the form of signals communicated over the communications media. The information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages may be sent over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

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

As shown in FIG. 7, the computing architecture 700 includes a processing unit 702, a system memory 704 and a system bus 706. The processing unit 702 can be any of various commercially available processors including, but not limited to,

and

a processor;

application, embedded, and secure processors;

and

and

a processor; IBM and

a Cell processor;

Core(2)

and

a processor; and the like. Dual microprocessors, multi-core processors and othersA processor architecture may also be employed as the processing unit 702.

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 structure that may further interconnect 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. The interface adapter may be connected to the system bus 706 via a slotted architecture. Example slot architectures can include, but are not limited to, Accelerated Graphics Port (AGP), card bus, (extended) industry standard architecture ((E) ISA), Micro Channel Architecture (MCA), NuBus, peripheral component interconnect (extension) (PCI (x)), PCI express, Personal Computer Memory Card International Association (PCMCIA), and the like.

The computing architecture 700 may comprise or implement various articles of manufacture. An article of manufacture may comprise a computer-readable storage medium to store logic. Examples of a computer-readable memory medium may include any tangible medium that stores electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or non-writeable memory, and so forth. 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, and the like. 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 performance of the operations described herein.

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), ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices (such as Redundant Array of Independent Disks (RAID) drives) solid state memory devices (e.g., USB memory, Solid State Drives (SSDs), and any other type of storage media suitable for storing information-in the illustrated embodiment shown in figure 7, the system memory 704 may include non-volatile memory 708 and/or volatile memory 710. A basic input/output system (BIOS) can be stored in the non-volatile memory 708.

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 to read from or write to a removable magnetic disk 716, and an optical disk drive 718 to read from or write to a removable optical disk 720 (e.g., a CD-ROM or DVD). The HDD 712, FDD 714 and optical disk drive 720 can be connected to the system bus 706 by 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 Universal Serial Bus (USB) and IEEE 694 interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can 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 messaging system 500.

A user can 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 pen, a card reader, a dongle, a fingerprint reader, gloves, a graphics tablet, a joystick, a keyboard, a retinal reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a track pad, a sensor, a stylus pen, and so forth. These and other input devices are often connected to the processing unit 702 through an input device interface 740 that is coupled to the system bus 706, but may be connected by other interfaces, such as a parallel port, IEEE 694 serial port, game port, USB port, IR interface, or the like.

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 so forth.

The computer 701 may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s) 744. The remote computer(s) 744 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 701, although, for purposes of brevity, only a memory/storage device 746 is illustrated. The logical connections depicted include wired/wireless connectivity to a Local Area Network (LAN)748 and/or larger networks, e.g., a Wide Area Network (WAN) 750. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communication network, e.g., the Internet.

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 a LAN 748, which LAN 748 may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 752.

When used in a WAN networking environment, the computer 701 can include a modem 754, or is connected to a communications server on the WAN 750, or has other means for establishing communications over the WAN 750, such as by way of the Internet. The modem 754, which can be internal or external to a wired and/or wireless device, is connected to the system bus 706 via the input device interface 740. In a networked environment, program modules depicted relative to the computer 701, or portions thereof, can be stored in the 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.

The computer 701 is operable to communicate with wire and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (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^TMWireless technology. Thus, the communication may be a predefined structure as with a conventional network, or simply a peer-to-peer communication between at least two devices. The W-Fi network uses a radio technology known as IEEE 802.13x to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

Fig. 8 is a block diagram depicting an exemplary communication architecture 800 suitable for implementing various embodiments as previously described. The communications architecture 800 includes various common communications elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, and so forth. Embodiments, however, are not limited to implementation by the communications architecture 800.

As shown in fig. 8, the communications architecture 800 includes one or more clients 802 and servers 804. The client 802 may implement a client device 510. The server 804 may implement the server device 526. The clients 802 and the servers 804 are operatively connected to one or more respective client data stores 806 and server data stores 808, and the client data stores 806 and server data stores 808 can be employed to store information local to the respective clients 802 and servers 804, such as cookies and/or associated contextual information.

The clients 802 and the servers 804 may communicate information with each other using a communication framework 810. The communications framework 810 may implement any well-known communications techniques and protocols. The communications framework 810 may be implemented as a packet-switched network (e.g., a public network such as the internet, a private network such as an enterprise 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).

The communications framework 810 may implement various network interfaces arranged to accept, communicate, and connect to a communications network. A network interface may be considered a special form of input-output interface. The network interface may employ a connection protocol including, but not limited to, a direct connection, an ethernet (e.g., fat, thin, twisted pair 10/100/1000 Base T, etc.), a token ring, a wireless network interface, a cellular network interface, an IEEE 802.8a-x network interface, an IEEE 802.16 network interface, an IEEE 802.20 network interface, etc. Further, multiple network interfaces may be used to participate in various communication network types. For example, multiple network interfaces may be used to allow communication over broadcast, multicast, and unicast networks. If processing requirements dictate a greater amount of rate and capacity, a distributed network controller architecture may similarly be used to centralize, load balance, and otherwise increase the communication bandwidth required by the clients 802 and servers 804. The communication network may be any one or combination of wired and/or wireless networks including, but not limited to, a direct interconnect, a secured custom connection, a private network (e.g., an enterprise intranet), a public network (e.g., the internet), a Personal Area Network (PAN), a Local Area Network (LAN), a Metropolitan Area Network (MAN), an operational task as a node on the internet (OMNI), a Wide Area Network (WAN), a wireless network, a cellular network, and other communication networks.

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. Further, where appropriate, the features of the apparatus may be implemented using microcontrollers, programmable logic arrays and/or microprocessors, or any combination of the foregoing. Note that hardware, firmware, and/or software elements may be referred to collectively or individually as "logic" or "circuitry" herein.

It will be appreciated that the exemplary apparatus illustrated in the block diagrams above may represent one functionally descriptive example of many possible implementations. Thus, division, omission or inclusion of block functions depicted in the accompanying figures does not infer that the hardware components, circuits, software and/or elements for implementing these functions would necessarily be divided, omitted, or included in the embodiments.

The at least one computer-readable storage medium may include instructions that, when executed, cause the system to perform any of the computer-implemented methods described herein.

Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. The terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. Moreover, unless otherwise indicated, the above features are recognized as being usable together in any combination. Thus, any features discussed separately may be combined with each other unless such features are indicated to be incompatible with each other.

Referring generally to the symbols and nomenclature used herein, the detailed description herein may be presented in terms of program processes executing on a computer or network of computers. These process descriptions and representations are used by those skilled in the art to more effectively convey the substance of their work to others skilled in the art.

A process is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The 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 has proven 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 borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

Furthermore, manipulations performed are often referred to in terms commonly associated with mental operations performed by human operators, such as additions or comparisons. Such capability of a human operator is not necessary or desirable in most cases in any of the operations described herein that form part of one or more embodiments. Instead, the operation is a machine operation. Useful machines for performing the operations of the various embodiments include general purpose digital computers or similar devices.

Some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as 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. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

Various embodiments are also directed to an apparatus or system for performing these operations. This apparatus may be specially constructed for the required purposes, or it may comprise 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 particular computer or other apparatus. Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given.

It is emphasized that the abstract of the disclosure is provided to allow the reader to 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 disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "including" and "in which" are used as the plain-english equivalents of the respective terms "comprising" and "wherein," respectively. Moreover, the terms "first," "second," "third," and the like are used merely as labels, and are not intended to impose numerical requirements on their objects.

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

Claims (20)

1. A non-transitory computer readable medium storing:

a first applet configured to authorize a transaction for a contactless card and maintain a first Primary Account Number (PAN) for the contactless card, the first PAN identifying the contactless card in the transaction;

a second applet different from the first applet and configured to interact with an external application and act as a bridge between the external application and the first applet;

instructions configured to cause processing circuitry to:

receiving, at the second applet, an instruction to change the first PAN;

authenticating the contactless card by instructing the contactless card to generate a password, transmitting the password generated by the contactless card to an authentication server, and receiving an authentication approval from the authentication server;

in response to authenticating the contactless card, instructing the first applet from the second applet over a secure communication channel to change the first PAN; and is

Changing the first PAN to a second PAN at the first small application, wherein changing the first PAN causes the first small application to use the second PAN in place of the first PAN in future transactions.

2. The media of claim 1, wherein the first applet is preloaded with a plurality of PANs when the contactless card is issued and changing the first PAN to the second PAN comprises advancing to a next preloaded PAN.

3. The medium of claim 1, wherein the instruction to change the first PAN received at the second applet is received via Near Field Communication (NFC).

4. The medium of claim 1, wherein changing the first PAN received at the second applet involves tapping the contactless card against an interactable element in a predetermined pattern.

5. The medium of claim 1, wherein the instruction to change the receipt at the second applet is received from an Automated Teller Machine (ATM) or a point of sale (POS) terminal.

6. The medium of claim 1, wherein the contactless card comprises an electronic ink (e-ink) display configured to display an identification number of the card derived from a PAN currently assigned to the contactless card, and wherein changing the first PAN to the second PAN comprises updating the e-ink display.

7. The media of claim 1, wherein instructing the first applet to change the first PAN comprises coordinating the change in the first PAN with a backend server associated with the second applet.

8. A method, comprising:

storing an original number of a credit account in digital payment logic on a chip of a contactless card;

receiving, at communication logic stored on the chip and remote from the digital payment logic, an instruction to update an original number of the credit account;

authenticating the contactless card by instructing the contactless card to generate a password, transmitting the password generated by the contactless card to an authentication server, and receiving an authentication approval from the authentication server;

establishing a secure data transfer from the communication logic to the digital payment logic in response to authenticating the contactless card;

sending a command from the communication logic to the digital payment logic to update the original number using the secure data transfer;

in response to receiving the command, updating the original number to an updated number using the digital payment logic.

9. The method of claim 8, wherein the digital payment logic derives the updated number from the original number.

10. The method of claim 8, wherein the instruction to update the original number received at the communication logic is received via Near Field Communication (NFC).

11. The method of claim 8, wherein the instruction to update the original number received at the communication logic comprises tapping the contactless card against an interactable element in a predetermined pattern.

12. The method of claim 8, wherein the instruction to update the original number received at the communication logic is received from an Automated Teller Machine (ATM) or a point of sale (POS) terminal.

13. The method of claim 8, wherein the contactless card comprises an electronic ink (e-ink) display configured to display an identification number of the card based on the updated number.

14. The method of claim 8, wherein issuing the command comprises coordinating an update of the number with a backend server associated with the communication logic.

15. A device having a contact pad, comprising:

an antenna configured to receive short-range communications from an apparatus;

a microprocessor circuit powered by the antenna using energy from the short-range communication;

a memory, the memory storing:

transaction logic configured to reference an identifier for the device associated with a transaction; and

encryption and authentication logic configured to communicate with the apparatus via the antenna, wherein

The encryption and authentication logic is further configured to: identifying an indication command from the apparatus and received by the antenna, the indication command indicating that the identifier is to be overwritten; authenticating the contactless card by instructing the contactless card to generate a password, transmitting the password generated by the contactless card to an authentication server, and receiving an authentication approval from the authentication server; and in response to authenticating the contactless card, transmitting the indication command to the transaction logic; and is

The transaction logic is further configured to overwrite the identifier based on the indication command.

16. The device of claim 15, wherein the first applet is preloaded with a plurality of PANs when the contactless card is issued and changing the first PAN to the second PAN comprises advancing to a next preloaded PAN.

17. The apparatus of claim 15, wherein the instruction to overwrite the identifier is received via the antenna using Near Field Communication (NFC).

18. The device of claim 15, wherein the instruction to overwrite the identifier is registered by the encryption and authentication logic as a tap of the device against an interactable element in a predetermined pattern.

19. The apparatus of claim 15, wherein the device is an Automated Teller Machine (ATM) or a point of sale (POS) terminal.

20. The device of claim 15, further comprising a rewritable display configured to display the identifier, and wherein rewriting the identifier comprises updating the rewritable display.

Images