Technique for controlling contactless card applets

Abstract

Various embodiments are generally directed to techniques for providing and controlling applets for transaction cards. More specifically, the embodiments discussed herein include allowing or denying applets on a transaction card based on whether they are enabled or disabled. Embodiments may also include enabling and disabling applets on a transaction card.

Description

[Technical field]

[0001] Related Applications This application claims priority to U.S. patent application Ser. No. 16 / 731,009, entitled "TECHNIQUES FOR CONTROLLING APPLETS FOR CONTACTLESS CARD APPLETS," filed Dec. 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 and new features. However, one drawback of current card technology is that it cannot be easily upgraded in a secure manner. Thus, when there is a problem with a card or 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 waiting for the new card. Summary of the Invention

[0003] Various embodiments described herein may include a device, system, apparatus, etc. including 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, an instruction to execute an applet on the transaction card, the applet being stored in a memory of the transaction card, and receiving, via the NFC interface of the communications link, a counter value associated with the applet. When the processing circuit executes the instructions, it sends a first message to the server via the network interface, the first message including the counter value and an identifier identifying 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 with the memory and the network interface. The processing circuit is operable to execute instructions, which 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 the transaction card, determine other counter values ​​stored in storage, other counter values ​​associated with the transaction card, compare the counter value to the other counters, and determine whether to allow or deny execution of the applet of the transaction card. Further, based on the comparison of the counter value to the other counter values, the processing circuit determines whether to allow or deny an attempt to execute the applet of the transaction card. The processing circuit may also communicate a second message to the client device including instructions to allow an attempt to execute the applet or instructions to deny an attempt to execute the applet. [Brief description 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. 2 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. [Diagram 3] 1 is an example of a system according to embodiments discussed herein. [Figure 4] 1 shows an example of a first flow diagram. [Diagram 5] 1 shows an example of a second flow diagram. [Figure 6] 13 shows an example of a third flow diagram. [Figure 7] 1 illustrates an example computing architecture. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[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, etc., 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 data, information which may include a counter value associated with the applet, which may be stored on the transaction card.

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

[0009] In an embodiment, the server can send data including an instruction to permit an attempt to execute the applet or an instruction to reject an attempt to execute the applet based on the result of the comparison, for example, permitting execution of the applet if it is valid and rejecting execution if it is invalid, and the device can receive the data. The embodiment is not limited in this way.

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

[0011] In an embodiment, the device may send data including the counter value and an identifier of the applet to the bank system or its server. The server may utilize 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 an 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] FIG 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] The system 100 may include one or more transaction cards 105, which are described further below with reference to Figures 2A-2B. In some embodiments, the transaction cards 105 may communicate with devices, such as the 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 an embodiment, 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 so limited 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 an input device. 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 touch screen display, and the like. The input device 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 touch screen display, a keyboard, a mouse, a cursor control device, a touch screen, a microphone, a digital camera, a video recorder or camcorder, and the like. 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, e.g., enable or disable.

[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 a cellular frequency band, e.g., a 700 megahertz (MHz) frequency range, an 800 megahertz (MHz) frequency range, an 850 MHz frequency range, a 1700 MHz frequency range, a 1900 MHz frequency range, a 2100 MHz frequency range, a 2300 MHz frequency range, a 2500 MHz frequency range, a 2600 MHz frequency range, etc. The transceiver itself may include components and circuits for performing transmit and receive operations. The components and circuits include analog-to-digital converters, digital-to-analog converters, modulators, amplifiers, etc. In an embodiment, the transceiver may be coupled with one or more antennas to perform communication. 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), and the like. 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), and the like. The embodiments are not so limited.

[0019] In an embodiment, the client device 110 may include additional I / O devices 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 applications 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 operate as an initiator, and the transaction card 105 may operate 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, operating as an initiator, is powered and provides a carrier field to the transaction card 105, operating as a 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 an 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 including 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 embodiment is not limited in this manner.

[0021] In an embodiment, 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, the client device 110 of the system 100 may also communicate with other components of the system 100, including one or more servers 120. For example, the client device 110 may communicate with one or more servers 120 over one or more networks 115 and may operate as a respective front-end to back-end pair with the server 120. The client device 110 may send one or more requests to the server 120, for example, from an application or code executed on the client device 110. The one or more requests may be associated with retrieving data from and providing data to the server 120. For example, the server 120 may receive one or more requests from the client device 110. Based on the one or more requests from the client device 110, the server 120 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, the server 120 may be configured to transmit the received data to the client device 110, the received data being responsive to the one or more requests.

[0023] In some embodiments, the server 120 may be coupled with a data store to store data and information regarding applets of the transaction card 105. The data store may be any type of data store, such as one or more databases stored in local and / or remote storage systems, cloud-based data store systems, etc. In some cases, the client device 110 may communicate with the server 120 to determine whether execution of one or more applets of 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 whether the applet is enabled or disabled for the transaction card based on the information in the data store. The data received from the client device 110 may include information regarding the applet, such as an identifier of the applet 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 of 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 an embodiment, the one or more servers 120 may have additional components, such as one or more processors coupled to a memory. The server 120 may be configured as a central system, server, or platform for controlling and calling various data at different times to perform multiple workflow actions. The server 120 may be configured to connect to one or more databases. The server 120 may also be connected to at least one client device 110. The embodiments are not limited to these components, and the 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 networks 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 networks 115 may include one or more of a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplex based system, a code division multiple access based system, a 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, and the like.

[0027] Additionally, network 115 may include, but is not limited to, telephone lines, optical fiber, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Additionally, 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 the network devices from other protocols. Although 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, for example, the Internet, a service provider's network, a cable television network, an enterprise network such as a credit card association network, and a home network.

[0028] 1B illustrates an example 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 includes, for purposes of simplicity, 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 embodiments discussed herein.

[0029] At step 152, the client device 110 may detect an attempt to execute an applet of 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 of the transaction card 105, which 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., 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 an embodiment, the applet may be a Near Field Wireless Data Exchange (NDEF) generated applet, and the applet selection message may be transmitted according to an 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, may include a Uniform Resource Indicator (URI) for causing one or more operations to be performed on the client device 110, may include a code snippet (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 processing circuitry of the client device 110 to at least one of launch a website in a web browser (pointed to by a URI), launch an application for execution by the processing circuitry (a code snippet), and cause communication with other devices (pointed to by a URI), such as sending rewards data to a server identified in the URI and / or sending a message to the server including instructions for updating 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 function file", "read function file", and "select NDEF file". In some embodiments, the applet may also be identified in an 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, via the NFC interface of the communications link, a counter value associated with the applet. In an embodiment, 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 "selection of NDEF file" (applet ID or application ID). In an embodiment, the transaction card 105 may store one or more counter values ​​in memory, each of which may be associated with a particular applet and may be populated by the circuitry of the transaction card 105 using the identifier. In an embodiment, the counter value of an applet may be incremented with each message exchanged between the client device 110 and the transaction card 105 of the associated applet. As will be 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 to communicate 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 the 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 and encoded as ASCII hexadecimal and returned to the client device in NDEF message format (response to a "Read NDEF file" message) along with the counter value. 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 the executable code.

[0037] In an embodiment, 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, 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 an 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. The embodiments are not so limited.

[0038] In an embodiment, the client device 110 may communicate additional information with the counter value and the 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 with an encryption key, which may be a session key of 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 securely transmitted between the client device 110 and the server 120.

[0039] At step 162, the 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, the server 120 may receive a message from the client device 110 and determine other corresponding counter values ​​for the applet. More specifically, the server 120 may perform a lookup based on the identifier received in the message from the client device 110 to determine the corresponding counter value associated with the applet and stored in a data store. In some cases, the server 120 may use additional information, such as a user identification (username), an account identification (account number), a transaction card identification (card number), etc. As previously mentioned, the data store may be a locally or remotely stored database and / or a cloud-based database. However, the embodiments are not limited in this manner.

[0040] In an embodiment, the server 120 compares the counter values ​​received in messages from the client device 110 and the transaction card 105 to 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 to allow or deny the transaction card 105's attempt to execute the applet.

[0041] In one example, the server 120 may determine that the applet is valid for the 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 an embodiment, 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, e.g., the counter value on the transaction card 105 may be incremented without the knowledge of the server 120. Thus, the value on the transaction card 105 may be greater than the counter value on the server 120 and still be valid. However, the counter value on the server 120 should not be greater than the counter value on the transaction card 105 unless the applet is disabled. 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 other particular value to disable the applet.

[0042] In an embodiment, 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 that includes a message that includes 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 that includes instructions to deny an attempt to execute the applet on the transaction card 105. The instructions 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. Additionally, 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 of a communication flow 170 that may occur to enable or disable an applet. In an embodiment, one or more applets may be enabled or disabled by a user, an administrator, a computing system, automatically based on one or more settings, etc. 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 an instruction 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 touch screen with the user interacting with one or more GUIs associated with an application 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, the client device 110 may obtain a counter value associated with the applet from the transaction card 105 to ensure that the stored counter value of the server 120 is set appropriately by the server 120. At step 174, the client device 110 may establish a communications link with the transaction card 105. As above, the transaction card 105 and the client device 110 may be brought sufficiently close to each other to transmit data via NFC communications. To establish the communications link, the client device 110 and the transaction card 105 may perform one or more verification and authentication processes.

[0046] At step 176, the client device 110 may communicate an identifier of the applet to the transaction card 110. In an embodiment, the identifier may be an applet ID sent in an applet selection message, or an application ID sent in a "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 of the transaction card 105. However, in some cases, embodiments include a less detailed approach, where the transaction card 105 may only have a single counter value, and each applet of 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 of 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, the server 120 activates the applet on the transaction card 105. For example, the server 120 may determine a counter value associated with the applet in a data store communicatively coupled to the server 120, which may be local, remote, cloud-based, etc. In an embodiment, the server 120 may determine the associated counter value based on an identifier of the applet and one or more user identification information (username), account identification information (account number), card identification information (card number), etc. The server 120 may set the associated counter value to the counter value received from the client device 110. In some cases, the server 120 may set the associated counter value to a value less than the received counter value. At step 184, the server 120 may send a confirmation message to the client device 110 indicating whether the applet was successfully activated or whether the 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 touch screen 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, for example, 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"), at step 182. At 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 a person authorized to access a user's financial information, may enable and / or disable applets on a transaction card 105. For example, an 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 card users who are 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 fraud attempts. Server 120 may receive an indication from the fraud detection system indicating that a breach and / or fraud attempt may have occurred. The indication may include information to identify an account affected by the breach or fraud. Server 120 may utilize the identification 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, which may determine to enable one or more applets for the first time. In this example, server 120 may set the associated counter value to a start value (one or zero). The start value may be the same as the start value set on the transaction card at the time of manufacture. In other words, the transaction card may be configured with the applets disabled and available for use by the user at a later time. The embodiments are not so limited.

[0054] FIG. 2A illustrates an example configuration of a transaction card 200 that 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 include, but is not limited to, an identification card unrelated to a payment card. In some examples, the transaction card may include a dual interface contactless payment card, a rewards card, and the like. The transaction card 200 may include a substrate 210 that may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl 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 that conform to the ID-1 format of the ISO / IEC 7816 standard, or the transaction card may otherwise conform to the ISO / IEC 14443 standard. However, it will be understood that transaction cards 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] The transaction card 200 may also include identification information 215 displayed on the front and / or back of the card, and a contact pad 220. The contact pad 220 may include one or more pads and is 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 the EMV protocol. The 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 the contact pad 220 or elsewhere on the substrate 210, for example, within a different layer of the substrate 210. The transaction card 200 may also include a magnetic strip or tape that may be located on the back of the card (not shown in FIG. 2A). The transaction card 210 may also include an NFC device coupled with an antenna capable of communicating via an NFC protocol. The embodiments are not so limited.

[0056] As shown in FIG. 2B, the contact pad 220 may include or be coupled to an integrated chip 225 for storing and processing information, including a microprocessor 230 including processing circuitry and a memory 235. It is understood that the 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 necessary to perform the functions described herein. Although shown as part of or behind the contact pad 220, the embodiments are not so limited. In some cases, the integrated may be located in a different location on the transaction card 200 and coupled to the 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, e.g., 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 memories. 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 may be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory, and may 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, but may instead be any software application operable on a transaction card or other device having 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 circuitry, and communicate with other devices (pointed to by a URI), e.g., send rewards data to a server identified in 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 numerical counter sufficient to store an integer number. In an embodiment, 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 an embodiment, 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 that may be used to control and make available 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 an applet, or a matching value to enable an applet.

[0060] The customer identifier 250 may include a unique alphanumeric identifier assigned to a user of the transaction card 200, which may distinguish the user of the transaction card from other users of transaction cards. In some examples, the customer identifier 250 may identify both a customer and an account assigned to the customer, and may further identify a transaction card associated with the customer's account. In some cases, the 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 data for applets during a session.

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

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

[0064] In one embodiment, the antenna 255 including the coil of the transaction card 200 may act as the secondary of an air core transformer. For example, an ATM may communicate with the transaction card 200 by interrupting the power or amplitude modulation. The transaction card 200 may infer data transmitted from the ATM using a gap in the transaction card's power connection, which may be kept functional 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 at the terminal's coil by interference.

[0065] 3 illustrates a system 300 including a client device 310, such as a mobile device, that can perform operations to maintain applets on a transaction card 305. The system 300 illustrates the client device 310 having several components that can couple to and communicate with the transaction card 305 and other servers 310. The components of the client device 310 include a display 311, a processor 312, and an NFC device 313. In embodiments, the client device 310 may include additional components not shown, such as an EMV device, one or more interfaces, memory, etc., and the 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 a request 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, operation to perform, etc.

[0067] In some cases, the client device 310 may communicate information to determine whether the 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 the information from the client device 310 to determine a counter value associated with the applet and stored in the database 335. As previously described, the server 320 may utilize an identifier of the applet and one or other identifiers, such as a user identification, an account identification, a card identification, a unique customer identifier, etc., to determine a counter value in the database. Based on the results of the 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 an embodiment, the client device 310 may include a processor 312 that may be coupled with other components including memory. The processor 312 may be any type of processor, including circuits, caches, control units, logic, registers, clocks, buses, etc. Additionally, the memory may be any type of memory. In an embodiment, the memory may store one or more applications or software that include 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 an embodiment, 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). As should be noted, those skilled in the art will understand that a distance of less than 20 centimeters is consistent with an NFC range. When the transaction card 305 is in close 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 the card's NFC device, authenticating the card, polling the card for the status of the applet, and receiving the status. In some cases, as previously described, 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 represent 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 a 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 indication of an attempt to execute the applet for the transaction card, where the applet is stored in memory of the transaction card. In an embodiment, the indication 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 an approximate 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 the 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 a user identification information, an account identification information, a 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's 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, the logic flow 400 includes receiving, by the client device, a second message from the server, where the second message may include instructions to allow an attempt to execute the applet or instructions to deny an attempt to execute the applet. Further, at block 460, the logic flow 440 includes allowing, by the client device, the attempt to execute the applet based on the indication of permission received in the second message, or denying, by the client device, the attempt to execute 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 represent 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 an embodiment, the message includes a counter value and an identifier for identifying the applet, where the counter value is 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 the information received from the client device to obtain the other counter values ​​from a data store, for example, performing a lookup in a database.

[0080] At block 530, the logic flow 500 includes comparing the counter value from the client device to other counter values ​​retrieved from the data store to determine whether to allow or deny an attempt to execute the applet of the transaction card. 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, the logic flow 500 includes determining whether to allow or deny an attempt to execute the applet of the transaction card 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 other invalid value, 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 execute the applet or instructions to deny the attempt to execute the applet.

[0082] 6 shows an example process 600 illustrating key derivation according to one example. Initially, the sender, e.g., a transaction card, and the 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 can be encrypted by the sender using the data encryption master key to generate a data encryption derived session key, and the counter value can also be encrypted by the sender using the data integrity master key to generate a data integrity derived session key, e.g., a session key. In some examples, the entire counter value or a portion of the counter value can be used during both encryptions.

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

[0085] At block 630, the data to be protected is processed by an encryption MAC operation by the sender using the data integrity session key and an encryption MC algorithm. The protected data including the plaintext and the shared secret can 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 can be encrypted by the sender using the data encryption derived session key in combination with a symmetric encryption algorithm. In some examples, the MAC ciphertext is combined with, e.g., an equal amount of random data of each 8 - byte length and encrypted using a second session key (DEK - Session - Key).

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

[0088] At block 660, the receiver independently derives two derived session keys from the two master keys using the received counter value 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 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 proper. 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., the sending device) and the receiver (e.g., the receiving device), the contactless card that created the MAC and encrypted the MAC may be trusted to be in fact genuine. Additionally, 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) at 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] The terms "system" and "component" as used in this application are intended to refer to any computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 700. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. As an 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 a component may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to one another by various types of communication media to coordinate operations. 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 an assignment, each message is a signal. However, further embodiments may use data messages as an alternative. 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, the computing architecture 700 includes a processing unit 704, a system memory 706, and a system bus 708. The 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, (Enhanced) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Enhanced) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0098] Computing architecture 700 may include or be embodied in various articles of manufacture. The articles of manufacture may include a computer-readable storage medium 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 re-writable memory, and the like. Examples of logic may include executable computer program instructions implemented 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, 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.

[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 drive (SSD)), 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 a HDD interface 724, a FDD interface 726, and an optical drive interface 728, respectively. The HDD interface 724 for an external drive implementation 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 include, 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, grab, graphic tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), track ball, 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 can 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 an intranet. All of these may connect 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 technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth wireless technologies, and the like. Thus, communication can be a predefined structure, as with traditional networks, 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, and to wired networks (using IEEE 702.3 related media and functions).

[0108] The various elements of the devices described above with reference to Figures 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 speeds, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints desired for a given implementation.

Claims

1. A network interface; A memory for storing instructions; an apparatus comprising: a processing circuit coupled to the memory and the network interface, the processing circuit operable to execute the instructions, the instructions, when executed, cause the processing circuitry to perform a predetermined operation; The predetermined operation is receiving a first message from a client device associated with a transaction card via a network interface to determine whether an applet is valid or invalid for the transaction card, the first message including a counter value and an applet identifier for identifying an applet, the counter value being associated with the applet, the counter value being one of a plurality of counter values, each of the plurality of counter values ​​being associated with a different one of the plurality of applets; determining a second counter value stored in storage, comparing the counter value to the second counter value to determine whether the applet is valid or invalid for the transaction card; determining that the applet is valid for the transaction card based on a comparison of the counter value to the second counter value; communicating a second message indicating that the applet is valid for the transaction card; receiving, at the transaction card, a second instruction from the client device to disable the applet, the second instruction to disable the applet including an applet identifier for identifying the applet and a counter value stored on the transaction card and associated with the applet; setting a second counter value associated with the applet to a value in a data store storing one or more counter values ​​of the transaction card, the value in the data store being a value indicating that the applet is disabled; An apparatus comprising:

2. the processing circuitry determines that the counter value matches the second counter value based on the comparison and communicates the second message to the client device.

2. The apparatus of claim 1.

3. the processing circuitry determines that the counter value is less than the second counter value based on the comparison and communicates the second message to the client device.

2. The apparatus of claim 1.

4. a storage for storing a data store including one or more counter values; a processing circuit for determining a second counter value associated with the applet by performing a lookup in the data store based on the identifier, and retrieving the second counter value from one or more counter values ​​stored in the data store based on the lookup; The apparatus of claim 1 .

5. the second instruction is received from one of the client device, an automated teller machine (ATM), or a web-based application on a personal computer; 2. The apparatus of claim 1.

6. a value set for the second counter value that is less than the counter value received in the second instruction to disable the applet.

2. The apparatus of claim 1.

7. the value of the data store is set to a null value to disable the applet.

2. The apparatus of claim 1.

8. The processing circuitry includes: enabling the applet on the transaction card by receiving third instructions, the third instructions including an applet identifier for identifying the applet and a counter value stored on the transaction card and associated with the applet, the third instructions being received from the client device; The processing circuitry includes: enabling the applet in a data store storing one or more counter values ​​of the transaction card by setting a second counter value associated with the applet to the counter value received in the third instruction, the value in the data store indicating that the applet is enabled.

2. The apparatus of claim 1.

9. a banking system determining whether an applet is valid or invalid for a transaction card by receiving a first message from a client device associated with the transaction card, the first message including a counter value and an applet identifier for identifying the applet, the counter value being associated with an applet, the counter value being one of a plurality of counter values, each of the plurality of counter values ​​being associated with a different one of a plurality of applets; determining a second counter value stored in a storage; the banking system determining whether the applet is valid or invalid for the transaction card by comparing the counter value with the second counter value; determining that the applet is valid for the transaction card based on a comparison between the counter value and the second counter value; the banking system communicating a second message indicating that the applet is valid for the transaction card; and receiving, by the banking system, a second instruction from the client device to disable the applet on the transaction card, the second instruction to disable the applet including an applet identifier for identifying the applet and a counter value stored on the transaction card and associated with the applet; the banking system setting a second counter value associated with the applet to a value in a data store storing one or more counter values; 23. A computer-implemented method comprising:

10. The method of claim 1, further comprising: determining whether the applet is valid or invalid for the transaction card; determining, based on the comparison, that the counter value matches the second counter value and communicating the second message to the client device.

10. The computer-implemented method of claim 9.

11. Determining whether the applet is valid or invalid for the transaction card comprises: determining that the counter value is less than a second counter value based on the comparison and communicating the second message to the client device.

10. The computer-implemented method of claim 9.

12. Setting the second counter value to a value in the data store comprises: storing in a storage a data store including one or more counter values; determining a second counter value associated with the applet by performing a lookup in the data store based on the identifier, and obtaining the second counter value from one or more counter values ​​stored in the data store based on the lookup; 10. The computer-implemented method of claim 9, comprising:

13. the second instruction is received from one of the client device, an automated teller machine (ATM), or a web-based application on a personal computer; 10. The computer-implemented method of claim 9.

14. a value set for the second counter value that is less than the counter value received in the second instruction to disable the applet.

10. The computer-implemented method of claim 9.

15. the value of the data store is set to a null value to disable the applet; 10. The computer-implemented method of claim 9.

16. The computer-implemented method further comprising: after setting the second counter value to a value in the data store, the banking system enabling an applet on the transaction card by receiving third instructions, the third instructions including an applet identifier for identifying an applet and a counter value stored on the transaction card and associated with the applet, the third instructions being received from the client device; the banking system setting a second counter value associated with the applet to the counter value received in the third instruction and enabling the applet in a data store storing one or more counter values ​​of the transaction card, the value in the data store being a value indicating that the applet is enabled; 10. The computer-implemented method of claim 9, comprising:

17. A non-transitory computer-readable storage medium having stored thereon computer-readable program code that enables a processor to execute a predetermined operation, The predetermined operation is determining whether an applet is valid or invalid for a transaction card by processing a first message from a client device associated with the transaction card, the first message including a counter value and an applet identifier for identifying an applet, the counter value being associated with the applet, the counter value being one of a plurality of counter values, each of the plurality of counter values ​​being associated with a different one of a plurality of applets; determining a second counter value stored in storage, comparing the counter value to the second counter value to determine whether the applet is valid or invalid for the transaction card; determining that the applet is valid for the transaction card based on a comparison of the counter value to the second counter value; communicating a second message indicating that the applet is valid for the transaction card; Disabling the applet on the transaction card by receiving second instructions from the client device, the second instructions for disabling the applet including an applet identifier for identifying the applet and a counter value stored on the transaction card and associated with the applet; setting the second counter value associated with the applet to a value in a data store storing one or more counter values ​​of the transaction card, the value in the data store being a value indicating that the applet is disabled; 1. A non-transitory computer readable storage medium comprising:

18. The non-transitory computer-readable storage medium storing computer-readable program code executable by a processor to determine that the counter value matches the second counter value based on the comparison and to communicate a second message to the client device.

20. The non-transitory computer-readable storage medium of claim 17.

19. the non-transitory computer-readable storage medium storing computer-readable program code executable by a processor to determine that the counter value is less than the second counter value based on the comparison and to communicate a second message to the client device.

20. The non-transitory computer-readable storage medium of claim 17.

20. a value set for the second counter value that is less than the counter value received in the second instruction to disable the applet; 20. The non-transitory computer-readable storage medium of claim 17.

Images