Technique for controlling applet of non-contact card

Abstract

To provide a system for, a device for, and an apparatus for controlling an applet of a transaction card.SOLUTION: The present invention is directed to a communication flow for a data transaction system to validate / invalidate an applet. The flow has steps of establishing a communication link with a transaction card, and causing a client device such as a mobile device, a personal computer, a portable information terminal, and so on for detecting an attempt to execute an applet of the transaction card to determine whether the applet is valid or invalid for the transaction card and, based on whether it is valid or invalid, permit or reject execution of the applet of the transaction card.SELECTED DRAWING: Figure 1C

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 731,009, entitled "Techniques for Controlling Contactless Card Applets," filed December 30, 2019, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] Currently, credit card users may use their cards at merchants across the country and around the world. Card issuers work tirelessly to provide enhanced features and new functions. However, one drawback of current card technology is that it cannot be easily upgraded in a secure manner. Therefore, when there is a problem with a card or when new features are available, card issuers typically issue a new card and the old card is discarded. This approach is costly and can leave card users without a card while they wait for the new card. Summary of the Invention

[0003] Various embodiments described herein may include a device, system, apparatus, etc. that includes a near field communication (NFC) interface, a network interface, a memory for storing instructions, and a processing circuit coupled to the memory, the NFC interface, and the network interface. The processing circuit may be operable to execute instructions that, when executed, cause the processing circuit to establish a communications link with a transaction card via the NFC interface and transmit, via the NFC interface of the communications link, instructions to execute an applet on the transaction card, the applet being stored in memory on the transaction card and receiving, via the NFC interface of the communications link, a counter value associated with the applet. When executing the instructions, the processing circuit sends a first message to the server via the network interface, the first message including the counter value and an identifier that identifies the applet, receives a second message from the server via the network interface, the second message including an instruction to allow an attempt to execute the applet or an instruction to deny an attempt to execute the applet, and allows the attempt to execute the applet based on the instruction to allow received in the second message, or denies the attempt to execute the applet based on the instruction to deny received in the second message.

[0004] Various embodiments may also include a device, system, apparatus, etc., including a network interface, a memory for storing instructions, and a processing circuit coupled to the memory and the network interface. The processing circuit may be operable to execute instructions that, when executed, cause the processing circuit to receive a first message from a client device via the network interface, the first message including a counter value and an identifier identifying an applet, the counter value being associated with the applet, the counter value and the applet being stored in a memory of a transaction card, determine other counter values ​​stored in storage, other counter values ​​associated with the transaction card, compare the counter value with the other counters, and determine whether to allow or deny execution of the applet on the transaction card. Further, based on the comparison of the counter value with the other counter values, the processing circuit may determine whether to allow or deny an attempt to execute the applet on the transaction card. The processing circuit may also communicate a second message to the client device including instructions to allow or deny an attempt to execute the applet. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 is a diagram of a data transmission system. [Figure 1B] 1 illustrates an example of a communication flow of a data transmission system for determining whether an applet is enabled or disabled. [Figure 1C] 1 illustrates an example of a communication flow for a data transaction system to enable / disable an applet. [Figure 2A] FIG. 1 is a diagram of a transaction card according to an embodiment. [Figure 2B] FIG. 2 is a diagram of a contact pad of a transaction card according to an embodiment. [Figure 3] 1 is an example of a system according to embodiments discussed herein. [Figure 4] 1 shows an example of a first flow diagram. [Figure 5] 10 shows an example of a second flow diagram. [Figure 6] 10 shows an example of a third flow diagram. [Figure 7] 1 illustrates an example computing architecture. DETAILED DESCRIPTION OF THE INVENTION

[0006] Various embodiments are generally directed to systems, devices, techniques, etc. for controlling applets on a transaction card. More specifically, embodiments include determining whether applets are valid or invalid for a transaction card, and allowing or denying execution of applets on a transaction card based on whether they are valid or invalid.

[0007] For example, embodiments may include a device, such as a mobile device, personal computer, personal digital assistant, or the like, configured to establish a communications link with a transaction card and detect an attempt to execute an applet on the transaction card. The device may communicate with the transaction card upon establishing the communications link, including sending an indication of the attempt to execute the applet to the transaction card. Additionally, the device may receive data from the transaction card, and the information may include a counter value associated with the applet and may be stored on the transaction card.

[0008] In embodiments, the device may be further communicatively coupled to one or more other systems, such as a banking system, including a server that may be utilized to determine whether an applet is valid or invalid for a transaction card. For example, the device may transmit data to the server including a counter value and an identifier for identifying the applet. The server may determine whether the applet is valid or invalid based on a counter value corresponding to the applet stored in a data store. For example, the server may compare the received counter value with a stored counter value to determine whether they match or whether one is greater than or less than the other. Based on the results of the comparison, the server may determine whether the applet is valid or invalid. For example, if they match or the stored counter value is less than the received value, the applet may be valid. If the stored counter value is greater than the received counter value, the applet may be disabled. In some cases, the stored counter value may be set to a value such as NULL or "0000" to indicate that the applet is disabled.

[0009] In embodiments, the server may send, and the device may receive, data including instructions to allow or deny the attempt to run the applet based on the results of the comparison, e.g., allow the applet to run if the applet is valid and deny execution if the applet is invalid. Embodiments are not so limited.

[0010] Embodiments may also include systems, devices, and techniques for enabling and disabling applets on a transaction card. For example, a client device may determine to enable an applet for a transaction card and may receive, for example, user input or selection of the applet. The client device may further establish communication with the transaction card to communicate data, including determining a counter value associated with the applet.

[0011] In embodiments, the device may transmit data including the counter value and identifier of the applet to the banking system or its server. The server may use the data received from the device to set the corresponding counter value in a data store to the received counter value. The applet may then be enabled for use with the transaction card.

[0012] In other examples, the device may decide to disable the applet for a transaction based on, for example, a user selection, fraud detection, etc. The device may communicate the data to a server, and the server may set a corresponding counter value in a data store to a value that disables the applet, e.g., NULL, "0000," etc. Embodiments are not limited to these examples, and further details are provided below.

[0013] Reference is now made to the drawings. Like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. However, it may be apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate description thereof. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0014] 1A illustrates a system 100 according to an example embodiment. As described further below, system 100 may include a transaction card 105, a client device 110, a network 115, and a server 120. Although FIG. 1 illustrates a single instance of the components, system 100 may include any number of components.

[0015] System 100 may include one or more transaction cards 105, which are further described below with reference to Figures 2A-2B. In some embodiments, transaction card 105 may communicate with devices such as client device 110 via various wired and wireless communication technologies, such as near field communication (NFC) and Europay, Mastercard, and Visa (EMV). However, embodiments are not limited in this manner and may include communicating with devices via other technologies.

[0016] System 100 may include client device 110, which may be a network-enabled computer. In embodiments, client device 110 may be a mobile device. For example, the mobile device may include an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, a device running Microsoft's Windows® Mobile operating system, a device running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices. However, embodiments are not limited in this manner, and client device 110 may be other types of devices, such as a communications device, a handheld personal computer (PC), a server, a network appliance, a PC, a workstation, a personal digital assistant, a thin client, a fat client, etc.

[0017] The client device 110 may include components including a processor and memory, and it is understood that the processor may include additional components, including processing circuitry, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, necessary to perform the functions described herein. The client device 110 may further include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, a flat-panel display, and a mobile device screen, including a liquid crystal display (LCD), a light-emitting diode display, a plasma panel, a touchscreen display, etc. The input devices may include any device for inputting information into a user's device that is available and supported by the user's device, such as a touchscreen display, a keyboard, a mouse, a cursor control device, a touchscreen, a microphone, a digital camera, a video recorder or camcorder, etc. These devices may be used to input information and interact with the software and other devices described herein. For example, the client device 110 may include one or more components for allowing a user to perform one or more operations on an applet on the transaction card 105, such as enabling or disabling.

[0018] In an embodiment, the client device 110 may include one or more input / output (I / O) devices, including devices for communicating using wireless and wired technologies. For example, the client device 110 may include one or more transceivers for communicating in cellular frequency bands, e.g., the 700 megahertz (MHz) frequency range, the 800 megahertz (MHz) frequency range, the 850 MHz frequency range, the 1700 MHz frequency range, the 1900 MHz frequency range, the 2100 MHz frequency range, the 2300 MHz frequency range, the 2500 MHz frequency range, the 2600 MHz frequency range, etc. The transceiver itself may include components and circuitry for performing transmit and receive operations. The components and circuitry include analog-to-digital converters, digital-to-analog converters, modulators, amplifiers, etc. In an embodiment, the transceiver may be coupled to one or more antennas for performing communications. Additionally, the transceiver may include and / or be coupled with additional physical layer and medium access control (MAC) layer circuitry and software to communicate according to one or more cellular standards, such as second generation (2G), 3G, 4G, and 5G or new radio (NR) standards. Additional cellular standards and / or technologies include enhanced data rates for GSM Evolution (EDGE), Evolution-Data Optimized (EVDO), General Packet Radio Service (GPRS), High Speed ​​Packet Access (HSPA), Evolved HSPA (HSPA+), Long Term Evolution (LTE), Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), etc. The transceiver may utilize one or more radio technologies and protocols (cellular protocols), such as code division multiple access (CDMA), frequency division duplexing (FDD), time division duplexing (TDD), multiple input and multiple output (MIMO), orthogonal frequency division multiple access (OFDMA), etc. The embodiments are not so limited.

[0019] In an embodiment, the client device 110 may include an additional I / O device, such as an NFC device coupled with an NFC antenna, e.g., a loop antenna. The NFC device may be a radio / controller operable to communicate according to an NFC protocol and use electromagnetic induction via the NFC antenna. In one example, the NFC device may communicate over unlicensed radio frequencies in the 13.56 MHz Industrial, Scientific, and Medical (ISM) band of the International Organization for Standardization / International Electrotechnical Commission (ISO / IEC) 18000-3 air interface, achieving data rates of 106 to 424 kilobits per second (kbit / s). As discussed in more detail below, the NFC device may be used and provided via an application to communicate with other NFC-enabled devices, e.g., transaction cards 105.

[0020] In one example, the client device 110 includes an NFC device that may act as an initiator, and the transaction card 105 may act as a target. In this example, the client device 110 and the transaction card 105 may operate in a passive mode of operation. The client device 110, acting as the initiator, is powered on and provides a carrier field to the transaction card 105, acting as the target. The transaction card 105 derives its operating power from the electromagnetic field provided by the initiator. In an embodiment, the client device 110, including the NFC device, may continuously and periodically (or semi-periodically) search for a target, e.g., the transaction card 105. In an embodiment, the client device 110 may communicate signals containing data with the transaction card 105 according to an NFC protocol. For example, the client device 110 may communicate with the transaction card 105 to determine the status of an applet on the transaction card 105. The embodiments are not limited in this manner.

[0021] In embodiments, the client device 110 may also include an EMV reader / writer that can read and write to the transaction card 105 via EMV protocols and standards. The EMV reader / writer may be used by the client device 110, for example, to read from and write to an integrated chip on the transaction card. The EMV reader / writer may include one or more pads that may be communicatively, physically, and electrically coupled to one or more pads on the transaction card 105. Once coupled, the client device 110 may utilize the EMV reader / writer to write data, information, applets, etc. to the transaction card 105.

[0022] In some embodiments, client device 110 of system 100 may also communicate with other components of system 100, including one or more servers 120. For example, client device 110 may communicate with one or more servers 120 via one or more networks 115 and may operate as a respective front-end to back-end pair with server 120. Client device 110 may send one or more requests to server 120, for example, from an application or code executing on client device 110. The one or more requests may be associated with retrieving data from and providing data to server 120. For example, server 120 may receive one or more requests from client device 110. Based on the one or more requests from client device 110, server 120 may be configured to retrieve the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, server 120 may be configured to transmit the received data to client device 110, the received data responding to the one or more requests.

[0023] In some embodiments, the server 120 may be coupled to a data store to store data and information regarding applets on the transaction card 105. The data store may be any type of data store, such as one or more databases stored in a local and / or remote storage system, a cloud-based data store system, or the like. In some cases, the client device 110 may communicate with the server 120 to determine whether execution of one or more applets on the transaction card 105 is enabled or disabled. For example, the server 120 may receive data regarding one or more applets 105 from the client device 110 and determine, based on the information in the data store, whether the applet is enabled or disabled for the transaction card. The data received from the client device 110 may include information about the applet, such as an applet identifier and a counter value associated with the applet, which may be used by the server to perform a lookup and determine whether the applet is enabled or disabled, as described in more detail below in FIG. 1B.

[0024] In other examples, the client device 110 may communicate with the server 120 to enable and / or disable one or more applets on the transaction card 105. For example, the client device 110 may receive user input requesting an applet to enable or disable the transaction card 105 and communicate the request to the server 120. The server 120 may perform one or more operations to enable / disable the applet, as discussed in more detail in FIG. 1C .

[0025] In embodiments, one or more servers 120 may have additional components, such as one or more processors coupled to memory. Server 120 may be configured as a central system, server, or platform for controlling and retrieving various data at different times to perform multiple workflow actions. Server 120 may be configured to connect to one or more databases. Server 120 may also be connected to at least one client device 110. Embodiments are not limited to these components, and server 120 may include other components for performing the operations discussed herein.

[0026] The system 100 may include one or more networks 115. In some examples, the network 115 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks and may be configured to connect the client devices 110 to the server 120. For example, the network 115 may include one or more of an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplex-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, etc.

[0027] Additionally, network 115 may include, but is not limited to, a telephone line, optical fiber, IEEE Ethernet 902.3, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. Furthermore, network 115 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 115 may further include one network or any number of the exemplary types of networks listed above, operating as a standalone network or in cooperation with one another. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may translate to or from one or more protocols of network devices from other protocols. While network 115 is shown as a single network, it should be understood that, according to one or more examples, network 115 may include multiple interconnected networks, such as the Internet, a service provider network, a cable television network, an enterprise network such as a credit card association network, and a home network.

[0028] 1B illustrates an exemplary communication flow 150 that may be performed by the system 100 to determine whether an applet is valid or invalid for a transaction card 105. The illustrated example, for purposes of simplicity, includes a transaction card 105, a client device 110, and a server 120. However, embodiments are not so limited, and the systems discussed herein may include additional devices, components, apparatus, etc. and still be consistent with the embodiments discussed herein.

[0029] At step 152, the client device 110 may detect an attempt to execute an applet on the transaction card 105. For example, the client device 110 may include one or more applications that may be executed on the client device 110. The client device 110 may receive a request from a user via user input and / or an application to initiate an applet on the transaction card 105, and the applet may be at least partially stored on the transaction card 105. For example, initiation of the applet may be triggered by the transaction card 105 being sufficiently close to the client device 110, e.g., at an NFC operating distance. In some cases, the client device 110 may include presenting a graphic in a graphical user interface (GUI) on a display to indicate to the user to bring the transaction card 105 closer to the client device 110. In other examples, initiation of the applet may occur automatically when the transaction card 105 is sufficiently close to the client device 110.

[0030] At step 154, the client device 110 may establish a communications link with the transaction card 105, which may be used to communicate data between the client device 110 and the transaction card 105. The client device 110 may perform one or more wireless exchanges with the transaction card 105 in accordance with an NFC protocol to establish the communications link. For example, the exchange may include one or more verification and validation processes for the client device 110 and the transaction card 105. Embodiments are not so limited.

[0031] At step 156, the client device 110 may transmit, via the NFC interface of the communications link, an indication of an attempt to execute the applet on the transaction card 105. In some embodiments, the indication to execute the applet on the transaction card 105 may be transmitted in an applet selection message and may include an identifier that identifies the applet, e.g., an applet ID.

[0032] In embodiments, the applet may be a Near Field Wireless Data Exchange (NDEF) generated applet, and the applet selection message may be transmitted according to the NFC data exchange format. The applet may be stored in memory or storage of the transaction card 105 and may enable one or more functions or operations to be performed on the transaction card 105 and / or the client device 110, e.g., by circuitry of the transaction card 105 and / or circuitry of the client device 110. For example, the applet may trigger an action to provide authentication functionality to provide single or multi-factor authentication, include a uniform resource indicator (URI) for causing one or more operations to be performed on the client device 110, include code snippets (executable code) to be executed by the transaction card 105 and / or the client device 110, etc. In some embodiments, the applet, when executed, may cause the processing circuitry of the client device 110 to perform at least one of: launching a website in a web browser (pointed to by the URI), launching an application for execution by the processing circuit (a code snippet), and causing communication with other devices (pointed to by the URI), such as sending rewards data to a server identified by the URI and / or sending a message to the server including instructions to update a rewards account.

[0033] In some embodiments, upon confirmation of selection and communication of the applet select message, a sequence of select file messages followed by a read file message may be transmitted between the transaction card 105 and the client device 110. For example, the client device 110 may transmit a sequence including "select feature file," "read feature file," and "select NDEF file." In some embodiments, the applet may also be identified in the application ID field of at least one or more of the select and read messages, e.g., "select NDEF file."

[0034] At step 158, the client device 110 may receive a counter value associated with the applet via the NFC interface of the communications link. In embodiments, the transaction card 105 may determine the counter value associated with the applet by performing a lookup based on an identifier in the applet selection message or a “select NDEF file” (applet ID or application ID). In embodiments, the transaction card 105 may store one or more counter values ​​in memory, each of which may be associated with a particular applet and populated by circuitry on the transaction card 105 using the identifier. In embodiments, the counter value for an applet may be incremented with each message exchanged between the client device 110 and the transaction card 105 of the associated applet. As described in more detail, the counter value may be utilized to generate a session key based on a master key to enable secure communication of data between the client device 110 and the transaction card 105 of the particular applet.

[0035] The transaction card 105 may generate a message including a header and a shared secret. The shared secret may be any type of data for communicating with the client device 110, such as authentication information, account information, user information, etc. Additionally, a message authentication code (MAC) ciphertext may be created from the message, which may include the header and the shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with a session key. The session key may be generated by the transaction card 105 for a particular exchange session and may be generated from a master key shared between the client device 110 and the transaction card 105 and further encrypted based on the applet's counter value.

[0036] The ciphertext and header may then be concatenated, encoded as ASCII hexadecimal, and returned to the client device along with the counter value in NDEF message format (in response to a "Read NDEF file" message). In some cases, the counter value may be sent to the client device 110 in clear text, and in other cases, the counter value may be encrypted. Additionally, the MAC ciphertext may be sent by the transaction card 105 as an NDEF tag, included in a URI (e.g., as a formatted string), and / or along with executable code.

[0037] In embodiments, the client device 110 may perform one or more communications with the server 120 to determine whether the applet is valid or invalid for the transaction card 105. More specifically, at step 160, the client device 110 may send one or more communications to the server 120 via a network interface, where the communications may include a counter value and an identifier for identifying the applet. The counter value may be a counter value received from the transaction card 105 and associated with the applet. The identifier may be an applet ID or application ID previously sent to the transaction card 105 in an applet selection message in a "select NDEF message." In some cases, the communication may be a single message communicated from the client device 110 to the server 120. However, in other examples, the communication may be two or more messages sent from the client device 110 to the server 120. For example, the counter value and the identifier may be sent in separate messages and / or may include the number of communications with the server 120. Embodiments are not limited in this manner.

[0038] In embodiments, the client device 110 may communicate additional information along with the counter value and identifier. For example, the client device 110 may also transmit a user identifier, a device identifier, a transaction card identifier, the current date, a location, etc. The client device 110 may also encrypt messages and data using an encryption key, which may be a session key for a particular session key or a shared master key known to the client device 110 and the server 120. These keys may be the same or different keys used to communicate data with the transaction card 105. Similarly, the client device 110 may sign messages so that the server 120 may identify the source of the message. Thus, data may be transmitted securely between the client device 110 and the server 120.

[0039] In step 162, server 120 may determine whether to allow or deny an attempt to execute the applet based on whether the applet is valid or invalid. For example, server 120 may receive a message from client device 110 and determine other corresponding counter values ​​for the applet. More specifically, server 120 may perform a lookup based on the identifier received in the message from client device 110 to determine corresponding counter values ​​associated with the applet and stored in a data store. In some cases, server 120 may use additional information, such as user identification information (username), account identification information (account number), transaction card identification information (card number), etc. As mentioned above, the data store may be a locally or remotely stored database and / or a cloud-based database. However, embodiments are not limited to this.

[0040] In an embodiment, the server 120 compares the counter values ​​received in messages from the client device 110 and the transaction card 105 with other counter values ​​retrieved from a data store associated with the server 120. Based on the comparison between the counter values ​​and the other counter values, the server 120 may decide whether to allow or deny the transaction card 105's attempt to execute the applet.

[0041] In one example, the server 120 may determine that an applet is valid for a transaction card 120 if the counter values ​​match or if the counter value received from the client device 110 is greater than the counter value retrieved by the server 120. In embodiments, the counter value stored on the transaction card 105 and transmitted via the client device 110 may become out of sync with the counter value on the server 120; for example, the counter value on the transaction card 105 may be incremented without the knowledge of the server 120. Thus, a value on the transaction card 105 may be greater than the counter value on the server 120 and still be valid. However, unless the applet is disabled, the counter value on the server 120 should not be greater than the counter value on the transaction card 105. Thus, if the counter value retrieved by the server 120 is greater than the counter value on the transaction card 105, the applet may be disabled. In some cases, the counter value may be set to a particular value to indicate that it has been disabled. For example, the counter value on the server 120 may be set to NULL, "0000," or another particular value to disable the applet.

[0042] In embodiments, if the server 120 determines in step 162 that the applet is enabled, the server 120 may send a communication over the network to the client device 110 in step 164, the communication including a message including instructions to allow an attempt to execute the applet on the transaction card 105. If the server 120 determines in step 162 that the applet is disabled, the server 120 may send a message to the client device 110 in step 164, the message including instructions to deny an attempt to execute the applet on the transaction card 105. The instruction sent to the client device 110 may be a particular value, such as a binary "0" indicating that the applet is disabled and a binary "1" indicating that the applet is enabled. However, embodiments are not limited to this example, and other values ​​may be agreed upon to indicate that the applet is disabled. Further, in step 166, the client device 110 may allow or deny an attempt to execute the applet based on the instructions received from the server 120.

[0043] FIG. 1C illustrates an example communication flow 170 that may occur to enable or disable an applet. In embodiments, one or more applets may be enabled or disabled by a user, an administrator, a computing system, automatically based on one or more settings, or the like. In one example, a user may utilize a client device 110 to enable and / or disable applets on a transaction card 105. The illustrated example of FIG. 1C includes a transaction card 105, a client device 110, and a server 120 for purposes of simplicity. However, embodiments are not so limited, and the systems discussed herein may include additional devices, components, apparatus, etc. and still be consistent with embodiments discussed herein.

[0044] At step 172, the client device 110 may receive instructions to enable the applet on the transaction card 105. For example, the client device 110 may receive user input via an input device of the client device 110 indicating a selection to enable the applet. In some cases, the user input may be via a touchscreen with the user interacting with one or more GUIs associated with applications to control and configure settings on the transaction card 105, e.g., a banking application, a transaction card applet, a payment application, a web browser website, etc.

[0045] In some cases, client device 110 may retrieve a counter value associated with the applet from transaction card 105 to ensure that the stored counter value on server 120 is set appropriately by server 120. At step 174, client device 110 may establish a communications link with transaction card 105. Similar to above, transaction card 105 and client device 110 may be brought sufficiently close to each other to transmit data via NFC communications. To establish the communications link, client device 110 and transaction card 105 may perform one or more verification and authentication processes.

[0046] In step 176, the client device 110 may communicate an identifier for the applet to the transaction card 105. In embodiments, the identifier may be an applet ID sent in the applet selection message or an application ID sent in the "select NDEF file." The transaction card 105 may utilize the identifier to determine a counter value stored in memory for the applet. As described, each applet may be associated with a corresponding counter value stored in memory of the transaction card 105 and configured by circuitry on the transaction card 105. However, in some cases, embodiments include a less detailed approach, where the transaction card 105 may have only a single counter value, and each applet on the transaction card 105 may be controlled together, e.g., all enabled or all disabled, by a single counter.

[0047] At step 178, the transaction card 105 may transmit the counter value to the client device 110. In embodiments, the counter value may be transmitted in plaintext or encrypted form. Additionally, the counter value may be transmitted in a MAC ciphertext. However, embodiments are not so limited, and in some cases, the counter value may be transmitted by itself in a message or communication.

[0048] At step 180, client device 180 may communicate data to server 120 to initiate activation of the applet. For example, client device 180 may send a message to server 120 via a network interface that includes a counter value and an identifier for the applet. The message may include additional information, including, but not limited to, a user identifier, a transaction card identifier, an account identifier, an indication of a selection to activate the applet, etc.

[0049] At step 182, server 120 activates the applet on transaction card 105. For example, server 120 may determine a counter value associated with the applet in a data store communicatively coupled to server 120, which may be local, remote, cloud-based, etc. In an embodiment, server 120 may determine the associated counter value based on the applet's identifier and one or more user identification information (username), account identification information (account number), card identification information (card number), etc. Server 120 may set the associated counter value to the counter value received from client device 110. In some cases, server 120 may set the associated counter value to a value less than the received counter value. At step 184, server 120 may send a confirmation message to client device 110 indicating whether the applet was successfully activated or whether activation failed.

[0050] In some embodiments, a user may disable an applet on a transaction card 105. For example, at step 172, the client device 110 may receive an instruction via user input or selection via a touchscreen interface. If the applet is disabled for the transaction card 105, the client device 110 may not communicate with the transaction card 105 to determine the counter value of the applet, for example, because a counter value may not be required to disable the applet. In these examples, the client device 110 may communicate an instruction to disable the applet directly with the server 120, and flow may proceed directly to step 180. Similar to above, the client device 110 may send additional information to the server 120 to disable the applet, such as user identification information, account identification information, card identification information, etc.

[0051] To disable an applet, server 120 may perform a lookup to determine the location of the associated counter value and set the associated counter value to a null value or other value ("00000000") in step 182. In step 184, server 120 may communicate a confirmation indicating whether disabling the applet was successful or unsuccessful.

[0052] Communication flow 170 is one possible flow for enabling and / or disabling applets on a transaction card 105. However, embodiments are not limited in this manner. As previously described, an administrator, such as a banker, credit employee, card management employee, or someone authorized to access a user's financial information, may enable and / or disable applets on a transaction card 105. For example, the administrator may interface with the server 120 via an application, such as a banking application, or via a website in a web browser to enable or disable applets on a transaction card 105. Allowing an administrator or banker to configure applets may be convenient for card users calling into the phone system or in person at a bank office.

[0053] In some cases, applets may be automatically disabled and / or enabled by a computer-based system. For example, server 120 may be coupled to and in communication with a fraud detection system configured to detect security breaches and / or attempted fraud. Server 120 may receive an indication from the fraud detection system indicating that a breach and / or attempted fraud may have occurred. The indication may include information for identifying the account affected by the breach or fraud. Server 120 may utilize the identifying information to set a counter value and disable applets in server 120's data store for the affected transaction cards. In another example, server 120 may be coupled to and / or part of a banking system, and the banking system may decide to enable one or more applets for the first time. In this example, server 120 may set the associated counter value to a starting value (one or zero). The starting value may be the same as the starting value set on the transaction card at the time of manufacture. In other words, the transaction card may be configured with an applet disabled and later made available for use by a user. Embodiments are not limited in this manner.

[0054] FIG. 2A illustrates an example configuration of a transaction card 200, which may include a payment card such as a contactless card, credit card, debit card, or gift card issued by a service provider as a service provider indicia 205 on the front or back of the card 200. In some examples, the transaction card 200 may be unrelated to a payment card and may include, but is not limited to, an identification card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, or the like. The transaction card 200 may include a substrate 210, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the transaction card 200 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard; otherwise, the transaction card may conform to the ISO / IEC 14443 standard. However, it is understood that transaction card 200 according to the present disclosure may have different characteristics, and the present disclosure does not require that the transaction card be embodied in a payment card.

[0055] Transaction card 200 may also include identification information 215 displayed on the front and / or back of the card, and contact pad 220. Contact pad 220 may include one or more pads and be configured to establish contact with other client devices, such as ATMs, user devices, smartphones, laptops, desktops, or tablet computers, via the transaction card. The contact pad may be designed according to one or more standards, such as the ISO / IEC 7816 standard, to enable communication according to EMV protocols. Transaction card 200 may also include processing circuitry, an antenna, and other components, as further discussed in FIG. 2B . These components may be located behind contact pad 220 or elsewhere on substrate 210, e.g., within a different layer of substrate 210. Transaction card 200 may also include a magnetic strip or tape (not shown in FIG. 2A ) that may be located on the back of the card. Transaction card 210 may also include an NFC device coupled with an antenna capable of communicating via an NFC protocol. Embodiments are not so limited.

[0056] As shown in FIG. 2B , contact pad 220 may include or be coupled to an integrated chip 225 for storing and processing information, including a microprocessor 230 containing processing circuitry and memory 235. It is understood that integrated chip 225 may include additional components, including a processor, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware, as needed to perform the functions described herein. While shown as part of or behind contact pad 220, embodiments are not limited in this manner. In some cases, an integrated chip may be located in a different location on transaction card 200 and coupled to contact pad 220 via one or more traces or interconnects to enable communication via EMV.

[0057] The memory 235 may be any type of memory, including, but not limited to, read-only memory, write-once-read-multiple memory, or read / write memory, such as, but not limited to, RAM, ROM, and EEPROM, and the transaction card 200 may include one or more of these memories. In some cases, the transaction card 200 may include multiple types of memory, including encrypted and unencrypted corresponding memory. Read-only memory may be programmable at the factory as read-only or one-time programmable. A one-time program allows it to be written once and read many times. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritten, but it may be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory and may also be read many times.

[0058] The memory 235 may be configured to store data including one or more applets 240, one or more counters 245, and a customer identifier 250. The one or more applets 240 may include one or more software applications configured to run on one or more transaction cards, such as a Java card applet. However, it is understood that the applet 240 is not limited to a Java card applet and may instead be any software application capable of operating on a transaction card or other device with limited memory. In some embodiments, the applet may cause the processing circuitry of the client device to at least one of launch a website in a web browser (pointed to by a URI), launch an application for execution (a code snippet) by the processing circuit, and communicate with another device (pointed to by a URI), e.g., send rewards data to a server identified by the URI and / or send a message to the server including instructions for updating a rewards account.

[0059] The one or more counter values ​​245 may include a numeric counter sufficient to store an integer. In embodiments, each of the one or more counter values ​​245 may be associated with and / or identified to a particular applet 240. Thus, each applet 240 has its own counter value 245. In embodiments, the counter value 245 may be incremented each time a device, such as the client device 110, communicates with the transaction card 205 regarding the associated applet. As described, the counter value may be obtained and sent to the client device to determine whether the associated applet is valid or invalid. The counter value may also be utilized to generate a session key based on a master key distributed and stored with the transaction card 200, for example, in memory 235 (not shown). In some cases, the transaction card 200 may include a single counter value stored in memory 235, which may be used to control and enable each of the applets 240 on the transaction card 200. For example, all applets may be enabled and / or disabled by setting the associated counter value stored in the data store to an appropriate value, e.g., NULL to disable the applet, or a matching value to enable the applet.

[0060] Customer identifier 250 may include a unique alphanumeric identifier assigned to a user of transaction card 200, which may distinguish the user of the transaction card from other users of transaction cards. In some examples, customer identifier 250 may identify both a customer and an account assigned to the customer, and may further identify the transaction card associated with the customer's account. In some cases, customer identifier 250 may be provided to the client device and server to determine whether an applet is enabled or disabled.

[0061] In an embodiment, memory 235 may store one or more keys (not shown), e.g., one or more master keys. Each key may be part of a key pair that may be used to encrypt and decrypt data, as described above for transmitting MAC ciphertext. As described above, a key may be encrypted based on a counter value and used as a session key for securely communicating applet data during a session.

[0062] In embodiments, transaction card 200 may also include an NFC device 260 capable of communicating according to an NFC protocol. NFC device 260 may operate passively and may be energized by a signal emitted by an NFC device of a client device. NFC device 260 may, for example, derive its power from an electromagnetic field caused by the NFC device of a client device. However, embodiments are not limited in this manner. In other examples, transaction card 200 may include a power source (not shown) operable to provide power to NFC device 260 so that it can activate its own electromagnetic field. In one example, as described above, transaction card 200 may provide status updates and communicate data with an ATM or client device via the NFC device. Embodiments are not limited in this manner, and transaction card 200 may communicate other data with other devices.

[0063] In some examples, transaction card 200 may include one or more antennas 255. The one or more antennas 255 may be disposed within transaction card 200 around integrated chip 225 and contact pads 220. For example, one or more antennas 255 may be integral with processing circuit 225, or one or more antennas 255 may be used with an external booster coil. As another example, one or more antennas 255 may be external to contact pads 220 and processing circuit 225. In an embodiment, one or more antennas 255 may be coupled to NFC device 260 and configured to enable NFC communication.

[0064] In one embodiment, the antenna 255, including the coil of the transaction card 200, may function as the secondary of an air-core transformer. For example, an ATM may communicate with the transaction card 200 by interrupting power or amplitude modulation. The transaction card 200 may use a gap in the transaction card's power connection to infer data transmitted from the ATM, which may be maintained functionally via one or more capacitors. The transaction card 200 may regain communication by switching the load or load modulation of the transaction card's coil. The load modulation may be detected in the terminal's coil through interference.

[0065] 3 illustrates a system 300 that includes a client device 310, such as a mobile device, that can perform operations to maintain an applet on a transaction card 305. System 300 illustrates client device 310 having several components that can couple to and communicate with transaction card 305 and other server 310. Components of client device 310 include a display 311, a processor 312, and an NFC device 313. In embodiments, client device 310 may include additional components not shown, such as an EMV device, one or more interfaces, memory, etc., and embodiments are not so limited. FIG. 3A illustrates a limited number of components for illustrative purposes only.

[0066] The client device 310 may communicate with one or more servers 320 via one or more networks 315, which may be wired and / or wireless networks. The client device 310 may transmit data to the server 320 via the client device's 310 networking interface. In one example, the client device 310 may transmit requests associated with retrieving data and information from one or more servers 320 and databases 335. For example, the server 320 may receive one or more requests from the client device 310 and process the requests. Based on the one or more requests from the client device 310, the server 320 may be configured to retrieve the requested data from one or more databases 335, for example. In an embodiment, the client device 310 may transmit data to the server 320 via the network 315. The data may include information regarding the user's account, account number, PIN entry, operations to be performed, etc.

[0067] In some cases, the client device 310 may communicate information to determine whether an applet is valid or invalid from the transaction card 305 before allowing the applet to continue execution. The transaction card 305 may perform a determination based on information from the client device 310 to determine a counter value associated with the applet and stored in the database 335. As described above, the server 320 may determine the counter value in the database using the applet's identifier and one or more identifiers, such as a user identification, an account identification, a card identification, a unique customer identifier, etc. Based on the results of a comparison of the counter value received from the client device 310 with the counter value stored in the database 335, the server 310 may determine whether the applet is valid or invalid. Additionally, the server 310 may communicate a result or an indication of the result to the client device 310 via the network 315.

[0068] The client device 310 may communicate with the server 320 over the network 315 to enable and disable applets on the transaction card 305. For example, the server 310 may receive instructions to disable an applet on the transaction card 305 from the client device 310 over the network 315. The server 320 may set a counter value associated with the applet to a value, e.g., NULL, to disable the applet in the database 335. Similarly, the server 320 may receive a counter value from the client device 310 and set a counter value in the database 335 to the received counter value.

[0069] In embodiments, the client device 310 may include a processor 312, which may be coupled with other components, including memory. The processor 312 may be any type of processor, including circuits, cache, control units, logic, registers, clocks, buses, etc. Additionally, the memory may be any type of memory. In embodiments, the memory may store one or more applications or software including instructions that may be executed by the processor 312 and processing circuits. The software may include instructions for performing operations discussed herein, such as instructions for performing transaction operations and transaction card management operations.

[0070] In embodiments, the client device 310 may communicate with one or more interfaces capable of communicating with the transaction card 305. In one example, the client device 310 includes an NFC device 313 capable of communicating with the transaction card 305 using short-range wireless communication (e.g., NFC). Notably, those skilled in the art will understand that a distance of less than 20 centimeters corresponds to an NFC range. When the transaction card 305 is in proximity to the client device 310, the NFC device 313 may read data stored on the card, such as the status of an applet. In one example, the NFC device 313 may perform one or more actions or communications with the transaction card 305, such as detecting the transaction card 305 including its NFC device, authenticating the card, polling the card for the status of the applet, and receiving the status. In some cases, as described above, the NFC device 313 may be capable of energizing and providing power to the NFC device of the transaction card 305. In other examples, the transaction card 305 may provide its own power to the NFC device.

[0071] 4 illustrates an example logic flow 400 that may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 400 may illustrate operations performed by a client device to determine whether an applet is enabled or disabled.

[0072] At block 410, the logic flow 400 includes establishing a communication link with a transaction card. For example, the client device may establish the communication link with the transaction card by communicating one or more messages with the transaction card according to an NFC protocol to perform verification and / or validation operations between the devices. The communication link may be utilized by the client device and / or the transaction card to communicate data.

[0073] At block 420, the logic flow 400 includes sending an instruction to the transaction card to attempt to execute the applet, the applet being stored in memory of the transaction card. In an embodiment, the instruction may be sent to the transaction card as an applet selection message and / or a "select NDEF file" message and includes an identifier of the applet.

[0074] At block 430, the logic flow 400 includes receiving, by the client device, a counter value associated with the applet. The counter value may be received in a MAC ciphertext or another message and may be in the clear or encrypted. The counter value is associated with the applet and may indicate approximately the number of communications the transaction card has performed with the applet.

[0075] At block 440, the logic flow 400 includes sending, by the client device, a first message to a server, where the first message may include a counter value and an identifier for identifying the applet. In some cases, the client device may send additional information related to the applet, such as user identification information, account identification information, card identification information, a unique customer identifier, etc. In other examples, the server may determine the additional information separately and perform an information lookup based on the identity of the client device sending the message. The counter value, the applet identifier, and other information may be used by a system including the server to determine whether the applet is enabled or disabled in the system.

[0076] At block 450, logic flow 400 includes receiving, by the client device, a second message from the server, where the second message may include instructions to allow or deny the attempt to run the applet. Further, at block 460, logic flow 440 includes allowing, by the client device, the attempt to run the applet based on the indication of permission received in the second message, or denying, by the client device, the attempt to run the applet based on the indication of denial received in the second message.

[0077] 5 illustrates an example logic flow 500 that may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 500 may illustrate operations performed by a server to determine whether an applet is enabled or disabled and to communicate with a client device.

[0078] At block 510, the logic flow 500 includes receiving, by the server, a message from the client device. In embodiments, the message includes a counter value and an identifier for identifying the applet, the counter value being associated with the applet. In some embodiments, the server may receive additional information from the client device, such as a user identification, an account identification, a card identification, a unique customer identifier, etc. However, embodiments are not so limited.

[0079] At block 520, the logic flow 500 includes determining, by the server, other counter values ​​stored in storage, other counter values ​​associated with the transaction card and the applet. For example, the server 500 may use information received from the client device to obtain the other counter values ​​from a data store, for example, by performing a lookup in a database.

[0080] At block 530, logic flow 500 includes comparing the counter value from the client device with other counter values ​​retrieved from the data store to determine whether to allow or deny an attempt to execute the transaction card applet. The result of the comparison may indicate whether the counter value received from the client device matches, is less than, or is greater than the other counter values. Based on the comparison, the server may determine whether the applet is valid or invalid. More specifically, at block 540, logic flow 500 includes determining whether to allow or deny an attempt to execute the transaction card applet based on the comparison. For example, if the counter value received from the client device matches or is greater than the stored counter value, the applet may be allowed. If the received counter value is less than the stored counter value or if the stored counter value is set to NULL or another value indicating invalidity, the applet may be prohibited.

[0081] At block 560, the logic flow 500 includes communicating, by the server, a second message to the client device, the second message including instructions to allow the attempt to run the applet or instructions to deny the attempt to run the applet.

[0082] 6 shows an example process 600 illustrating key derivation according to one example. Initially, a sender, e.g., a transaction card, and a recipient, e.g., a client device, may be provisioned with two different master keys. For example, the first master key may include a data encryption master key and the second master key may include a data integrity master key. The sender has a counter value that may be updated in block 610, and other data, such as data to be protected, that may be secured for sharing with the recipient.

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

[0084] In some examples, the counter value may not be encrypted. In these examples, the counter may be transmitted between the sender and receiver in the clear, i.e., without encryption.

[0085] The data to be protected is processed in a cryptographic MAC operation by the sender using the data integrity session key and the cryptographic MC algorithm at block 630. The protected data, including the plaintext and the shared secret, may be used to generate a MAC ciphertext using one of the session keys (AUT-Session-Key).

[0086] At block 640, the data to be protected may be encrypted by the sender using the Data Encryption-Derived Session Key in combination with a symmetric encryption algorithm. In some examples, the MAC ciphertext is combined with an equal amount of random data, e.g., each 8 bytes in length, and encrypted using a second session key (DEK-Session-Key).

[0087] At block 650, the encrypted MAC ciphertext is transmitted from the sender to the receiver along with sufficient information to identify additional secret information (eg, a shared secret, a master key, etc.) for verification of the ciphertext.

[0088] At block 660, the recipient independently derives two derived session keys from the two master keys using the received counter values, as described above.

[0089] At block 670, the data encryption-derived session key is used in combination with a symmetric decryption operation to decrypt the protected data. Additional processing is then performed on the exchanged data. In some instances, after the MAC is extracted, it may be desirable to recreate and match the MAC. For example, when verifying the ciphertext, it may be decrypted using a properly generated session key. The protected data may then be reconstructed for verification. A MAC operation may be performed using a properly generated session key to determine if it matches the decrypted MAC. Because the MAC operation is an irreversible process, the only way to verify is to recreate the MAC operation from the source data.

[0090] At block 680, the data integrity derived session key is used in combination with a cryptographic MAC operation to verify that the protected data has not been altered.

[0091] Some examples of the methods described herein may advantageously confirm when authentication is determined to be successful 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 decryption is successful and results in a proper MAC value. Successful decryption may indicate that a correctly derived encryption key was used to decrypt the encrypted MAC. Because the derived session key is created using a master key known only to the sender (e.g., sending device) and receiver (e.g., receiving device), the contactless card that created and encrypted the MAC may be trusted to be authentic. Furthermore, the counter values ​​used to derive the first and second session keys may be shown to be valid and may be used to perform the authentication operation.

[0092] The two derived session keys may then be discarded, the counter value may be updated (returning to block 610) on the next iteration of the data exchange, and a new set of session keys may be created (at block 620). In some examples, the combined random data may be discarded.

[0093] 7 illustrates an embodiment of an exemplary computing architecture 700 suitable for implementing various embodiments as described above. In one embodiment, computing architecture 700 may be included or implemented as part of system 100.

[0094] As used in this application, the terms “system” and “component” are intended to refer to any computer-related entity: hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 700. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other and coordinate operations by various types of communication media. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. Information may be embodied as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over a variety of connections, examples of which include parallel interfaces, serial interfaces, and bus interfaces.

[0095] Computing architecture 700 may include 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, etc. However, embodiments are not limited to implementation by computing architecture 700.

[0096] 7, computing architecture 700 includes a processing unit 704, a system memory 706, and a system bus 708. Processing unit 704 may be any of various commercially available processors.

[0097] The system bus 708 provides an interface from the system memory 706 to system components including, but not limited to, the processing unit 704. The system bus 708 may be any of several types of bus structures 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. Interface adapters may connect to the system bus 708 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

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

[0099] The system memory 706 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, 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, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 7, the system memory 706 may include non-volatile memory 710 and / or volatile memory 712. The non-volatile memory 710 may store a basic input / output system (BIOS).

[0100] The computer 702 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 714, a magnetic floppy disk drive (FDD) 716 that reads from or writes to a removable magnetic disk 718, and an optical disk drive 720 that reads from or writes to a removable optical disk 722 (e.g., a CD-ROM or DVD). The HDD 714, FDD 716, and optical disk drive 720 may be connected to the system bus 708 by an HDD interface 724, an FDD interface 726, and an optical drive interface 728, respectively. The HDD interface 724 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0101] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored on the drives and memory units 710, 712, including an operating system 730, one or more application programs 732, other program modules 734, and program data 736. In one embodiment, the one or more application programs 732, other program modules 734, and program data 736 may comprise, for example, various applications and / or components of the system 700.

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

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

[0104] The computer 702 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 748. The remote computer 748 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node and typically includes many or all of the elements described relative to the computer 702, although for purposes of brevity, only a memory / storage device 750 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 752 and / or larger networks, e.g., a wide area network (WAN) 754. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks, such as intranets. All of these may be connected to a global communications network, e.g., the Internet.

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

[0106] When used in a WAN networking environment, the computer 702 may include a modem 758 or have other means for establishing communications over the WAN 754, such as connected to a communications server on the WAN 754 or via the Internet. The modem 758 may be internal or external, a wired and / or wireless device, and connects to the system bus 708 via the input device interface 742. In a networked environment, program modules depicted relative to the computer 702, or portions thereof, may be stored in the remote memory / storage device 750. 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.

[0107] The computer 702 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.11 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, and the like. Thus, communication can be in a predefined structure, similar to a traditional network, or simply ad hoc communication between at least two devices. A Wi-Fi network provides secure, reliable, and high-speed wireless connectivity using radio technologies called IEEE 802.11 (a, b, g, n, etc.). A Wi-Fi network can be used to connect computers to each other, to the Internet, or to wired networks (using IEEE 702.3-related media and functions).

[0108] 1A through 6 may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as desired computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance constraints desired for a given implementation.

Claims

1. 1. An apparatus, comprising: a near field communication (NFC) interface; A network interface; a memory for storing instructions; a processing circuit coupled to the memory, the NFC interface, and the network interface, the processing circuit being operable to execute the instructions, the instructions, when executed, causing the processing circuit to: establishing a communications link with a transaction card via said NFC interface; sending, via the NFC interface of the communication link, an indication of an attempt to execute an applet on the transaction card, the applet being stored in memory on the transaction card; receiving, via the NFC interface of the communication link, a counter value associated with the applet; sending a first message to a server via the network interface, the first message including the counter value and an identifier for identifying the applet; receiving a second message from the server via the network interface, the second message including instructions to allow the attempt to execute the applet or instructions to deny the attempt to execute the applet; permitting the attempt to execute the applet based on the instructions to permit received in the second message or denying the attempt to execute the applet based on the instructions to deny received in the second message; A device that performs the following.

2. 2. The device of claim 1, wherein instructions for contactlessly executing an applet include the identifier that identifies the applet, and wherein the processing circuitry transmits the instruction of the attempt to execute the applet in an applet selection message via the NFC interface of the communication link.

3. 2. The device of claim 1, wherein the processing circuitry receives the counter value associated with the applet along with a message authentication code (MAC) cryptogram via the NFC interface of the communications link, the MAC cryptogram including a shared secret concatenated with random data.

4. The apparatus of claim 3 , wherein the MAC ciphertext and random number are encrypted with a session key that includes the counter value and are received in a Near Field Data Exchange (NDEF) message format.

5. The apparatus of claim 3 , wherein the MAC cryptogram further includes a uniform resource indicator associated with the applet, the uniform resource indicator causing an action by the processing circuit when the applet is allowed to execute.

6. 6. The apparatus of claim 5, wherein the action includes causing the processing circuitry to perform at least one of launching a website in a web browser, launching an application for execution by the processing circuitry, and causing communication with another device.

7. 2. The device of claim 1, wherein the instruction to allow the attempt to execute the applet is based on the counter value matching or being less than another counter value, the other counter value being stored on the server.

8. 2. The apparatus of claim 1, wherein the instruction to stop the attempt to execute the applet is based on one of the counter value not matching the other counter value, the other counter value being equal to a NULL value, and the other counter value being greater than the counter value.

9. 1. An apparatus, comprising: A network interface; memory for storing instructions and a processing circuit coupled to the memory and the network interface and operable to execute the instructions, which, when executed, cause the processing circuit to: receiving a first message from a client device via the network interface, the first message including a counter value and an identifier for identifying an applet, the counter value being associated with the applet, and the counter value and the applet being stored in a memory of a transaction card; determining another counter value stored in storage, the other counter value being associated with the transaction card; and comparing the counter value with the other counter value to determine whether to allow or deny an attempt to execute the applet on the transaction card; determining whether to allow or deny the attempt to execute the applet on the transaction card based on the comparison of the counter value with the other counter value; communicating a second message to the client device that includes instructions to allow the attempt to execute the applet or instructions to deny the attempt to execute the applet; A device that performs the following.

10. 10. The apparatus of claim 9, wherein the processing circuit determines, based on the comparison, that the counter value matches the other counter value and communicates the second message to the client device indicating to continue attempting to execute the applet.

11. 10. The apparatus of claim 9, wherein the processing circuit determines, based on the comparison, that the counter value is less than the other counter value and communicates the second message to the client device indicating to continue attempting to execute the applet.

12. 10. The apparatus of claim 9, wherein the processing circuit determines, based on the comparison, that the counter value does not match the other counter value and communicates the second message indicating to the client device to stop the attempt to execute the applet.

13. 10. The apparatus of claim 9, wherein the processing circuit determines that the other counter value associated with the applet is set to a NULL value and communicates the second message indicating to the client device to stop the attempt to execute the applet.

14. The device comprises: storage for storing a data store containing one or more counter values; 10. The apparatus of claim 9, further comprising: the processing circuitry for performing a lookup in the data store based on the identifier to determine the other counter value associated with the applet; and retrieving the other counter value from the one or more counter values ​​stored in the data store based on the lookup.

15. The processing circuitry receiving instructions to disable the applet on the transaction card, the instructions including the identifier for identifying the applet and the counter value stored on the transaction card and associated with the applet, the instructions being received from one of the client device, an automated teller machine (ATM), and a web-based application on a personal computer; 10. The apparatus of claim 9, further comprising: setting the other counter value associated with the applet to a value in a data store storing one or more counter values ​​for the transaction card, the value indicating that the applet is disabled.

16. 16. The apparatus of claim 15, wherein the value set for the other counter value is less than the counter value received in the instruction to disable the applet.

17. The apparatus of claim 15 , wherein the value of the other counter value is set to a NULL value to disable the applet.

18. The processing circuitry receiving instructions to enable the applet on the transaction card, the instructions including the identifier for identifying the applet and the counter value stored on the transaction card and associated with the applet, the instructions being received from one of the client device, an automated teller machine (ATM), and a web-based application on a personal computer; 10. The apparatus of claim 9, further comprising: setting the other counter value associated with the applet to the counter value received in the instruction for validation in a data store storing one or more counter values ​​of the transaction card, the value indicating that the applet is valid.

Images