Type 4 NFC tag as protocol interface

Abstract

NFC terminal devices and corresponding integrated circuit cards (ICCs) use NFC Type 4 tags as a protocol interface for complex or encrypted communication protocols not natively supported by the NFC terminal device. Smartphones acting as NFC terminals can block applications and / or protocols other than NFC Data Exchange Formatted (NDEF) messages. ICC applets supporting advanced functionality use designated memory locations for transmitting commands typically supported at the application level. Both the terminal and the ICC applet can check for updated data in these designated memory locations without protocol-level message control.

Description

Background Art

[0001] The background description provided herein is intended to generally present the context of the present disclosure. To the extent described in this background section, the work of the presently named inventors and aspects of the description that may not have otherwise qualified as prior art at the time of filing are not admitted, either explicitly or implicitly, to be prior art against the present disclosure.

[0002] Many NFC contactless readers, including most cell phones used as NFC readers or terminals, limit communication with the target to the NFC Data Exchange Format (NDEF). The target can be an integrated circuit card (ICC), such as a smart card. Communication with other application types, including payment applications, is blocked or ignored, preventing the operation of many complex applications. Summary of the Invention

[0003] In an embodiment, the terminal application and the corresponding card applet communicate complex application commands using simple memory write and memory read commands containing command and response application protocol data units (APDUs). The lack of full communication protocol support is addressed by checking changes to designated read and write memory locations against known data previously placed in the designated memory locations. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The figures depict the preferred embodiment for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods shown herein may be used without departing from the principles described herein.

[0005] Figure 1 is a diagram depicting an environment using a Type 4 NFC tag as a protocol interface according to the present disclosure;

[0006] Figure 2 is a block diagram of a terminal-side device according to the present disclosure;

[0007] Figure 3 is a block diagram of a chip used in a wireless integrated circuit card according to the present disclosure;

[0008] Figure 4 is a flow chart illustrating a method performed on a terminal-side device that supports a Type 4 NFC tag using a serial number as a protocol interface;

[0009] Figure 5 is a flow chart illustrating a method performed on a terminal-side device that supports a Type 4 NFC tag using a temporary number as a protocol interface;

[0010] Figure 6is a flow chart illustrating a method performed on a chip supporting ICC of Type 4 NFC tags as a protocol interface;

[0011] Figure 7 is a decision tree showing the steps of a card-side applet supporting Type 4 NFC tags as a protocol interface. DETAILED DESCRIPTION

[0012] Using a smartphone as a wireless payment device is common, as it holds payment credentials such as a credit card token. Applications such as Google Pay and Apple Pay use payment protocols like the Near Field Communication Environment (PPSE) to wirelessly interact with terminals via a Near Field Communication (NFC) radio. Similarly, some financial / payment smart cards, typically integrated chip cards (ICCs), now support direct wireless interaction with payment terminals using protocols similar to PPSE via applets running on the card.

[0013] However, even if both the smartphone and the wireless ICC are theoretically capable of supporting high-level protocol interactions, some smartphone manufacturers limit the protocols that can be used for interactions between the smartphone and the wireless ICC. In these cases, the smartphone may limit communications to a simple and limited NFC data exchange format (NDEF) and / or block non-NDEF communications. Without support for high-level communication protocols, many applications, including many cryptographic and financial products, simply cannot operate between the phone and the ICC. However, in an increasing number of environments, such as small retailers, the seller's smartphone may be the only available payment tool. If the seller or potential buyer does not use common person-to-person payment applications and the smartphone technology blocks the use of common payment cards, the opportunity for interaction is lost.

[0014] In order to overcome the technical deficiencies of such smartphones, a technical solution is disclosed that allows complex applications to be used through the simple NDEF protocol supported by smartphones. Figure 1 The technical environment supporting Type 4 NFC tags as a protocol interface is shown. Smartphone 10 can communicate wirelessly with ICC 12. ICC 12 may not only have a smart chip 14 supporting wireless communication such as ISO / IEC 14443, but also a secure element with protected memory and a cryptographic processor, as discussed below.

[0015] Figure 21 shows a smartphone 10 in simplified and exemplary form. A processor 15 can communicate with various components, including a memory 17 and a secure element (SE) 18, via a data bus 16. The SE 18 can protect stored data, such as cryptographic keys, and perform cryptographic functions, such as key generation, random number (nonce) generation, encryption / decryption, and signing. A biometric authentication unit 20 can examine a user's physiological characteristics, such as fingerprints or facial features, to confirm their identity. A user interface 22 can be or include a touchscreen capable of presenting information and receiving input via voice or keystrokes. A near-field communication (NFC) radio 24 can support limited-range communication with another device. In some embodiments, the NFC radio can provide a sufficient electric field to power up the smart chip 14 on the wireless ICC 12. Of course, other functional components are present on a typical smartphone 10, including multiple radios for local and wide-area communications, a power supply and battery, switches, and so on. These are not depicted for simplicity and clarity of this disclosure.

[0016] The memory 17 may contain several programs not depicted, such as an operating system and various applications. An application related to the present disclosure may be a payment application 26. The payment application 26 may contain an NDEF wrapper 28 sub-application. Figure 2 , NDEF wrapper 28 is shown as a separate callable application or module from payment application 26, but in other embodiments, NDEF wrapper 28 may be part of payment application 26. The roles and functions of payment application 26 and NDEF wrapper 28 are discussed in more detail below.

[0017] Figure 3 A block diagram of an exemplary smart chip 14 embedded in an ICC 12 is shown in FIG. Smart chip 14 may include a processor 30 coupled to various functional elements, including a power storage element 32. Power storage element 32 may couple electric field energy from a nearby terminal via an antenna to a power storage device, such as a capacitor. The stored power may be used to operate smart chip 14 for the duration of a communication session with the terminal.

[0018] Smart chip 14 may also include a secure element 34 that is the same as or similar to SE 18 of smartphone 10 and is capable of performing the same functions, such as secure data storage and cryptographic functions. An NFC radio 36 may support wireless communication with smartphone 10 or another terminal, such as a point-of-sale terminal in a retail store or an access control reader at a secure gate. In some embodiments, the NFC radio supports the ISO / IEC 14443 protocol, but other protocols may also be supported.

[0019] The memory 38 may include several programs or modules that are not depicted for the sake of clarity, such as an operating system such as JavaCard and other utilities. The memory 38 may include an NDEF application 40, which includes a first memory location 42 specified by the specification for storing a single command application protocol data unit (C-APDU) and a second memory location 44 specified by the specification for storing a single response application data unit (R-APDU). The payment applet 46 may support interaction with the payment application, including authentication, transaction signing, and token exchange with the corresponding terminal-side payment application. In some embodiments, the payment application may comply with the contactless payment standard. Payment specifications.

[0020] Figure 4 6 is a flow chart of an exemplary method 60 for terminal-side communication between a terminal and a card 12 using sequence numbers when the terminal does not support or actively blocks communication functions other than simple memory writes and memory reads (i.e., NDEF Type 4 tags). At block 62, the payment application 26 on the smartphone 10 acting as the terminal may attempt to initialize a session with the ICC 12, for example, by sending a Proximity Payment System Environment (PPSE) request. If the protocol request is blocked by the phone operating system, an alternative communication protocol using the NDEF wrapper 28 may be invoked.

[0021] At block 64, as part of the initialization, the NDEF application 40 may generate a sequence number, for example, by requesting a base number from the SE 34. The sequence number may be included in the first C-APDU command written to the ICC. The ICC will use this initial sequence number as a base number and may increment the sequence number to include each subsequent response. The sequence number may be continuous, i.e., incremented from the initial number through each subsequent message sent during the transaction. The sequence number helps determine when a new message is available and also helps determine that no messages have been lost. In this embodiment, the tag memory location 48 may not be used. With respect to Figure 5 Tagging memory locations is discussed in more detail.

[0022] At block 66, the payment application 26 may write a C-APDU having a first sequence number to the first memory location 42 using the NDEF 'write memory' command. Figure 6 The response at the card 12 is discussed, but briefly, the card operating system (not depicted) may initialize the NDEF application in response to card power-up or in response to data being written to the first memory location 42. The NDEF application 40 may be programmed to recognize the first memory location and instantiate the payment applet 46.

[0023] Once the payment applet 46 is active, the first memory location 42 may be read, interpreted, and processed, causing the R-APDU to be written to the second memory location 44. After writing the C-APDU to the first memory location 42, at block 68, the payment application 26 may begin reading data from the second memory location 44.

[0024] Because there is no higher-level protocol communication between the payment application 26 and the payment applet 46, there is no signaling indicating whether a response to the C-APDU has been generated. To address this messaging flaw, at block 70, the payment application 26 may determine whether the sequence number in the R-APDU has been incremented compared to the previous message. If not, the payment applet 46 has not yet responded to the C-APDU, and the "no" branch may be taken back to block 68. If the sequence number has been incremented, the payment applet 46 has responded, and execution may follow the "yes" branch to block 72. Here, the value of the second memory location 44 may be processed as a response to the original C-APDU. The payment application 26 may generate a subsequent C-APDU, and at block 74, the payment application, via the NDEF wrapper 28, may write the C-APDU to the first memory location 42 on the smart chip 14.

[0025] At block 76, the payment application 26 can read the second memory location 44 and, as described above, at block 78, determine whether the sequence number has been incremented, thereby indicating a response to the most recent C-APDU. If the content has not changed, execution returns to block 76 to continue. If the content has changed, execution can continue at block 80, where the R-APDU can be processed and, if necessary, another C-APDU can be generated. Execution can continue at block 114 until all communications required to complete the requested function are achieved. Using this technique, the smartphone 10 can simulate an actual contactless payment transaction without any direct communication between the payment application 26 on the smartphone 10 and the payment applet 46 on the ICC 12.

[0026] Figure 5 1 is a flow chart of an exemplary method 100 for terminal-side communication between a terminal and a card 12 using a temporary number when the terminal does not support or actively blocks communication functions other than simple memory writes and memory reads (i.e., NDEF Type 4 tags). At block 102, the payment application 26 on the smartphone 10 acting as the terminal may attempt to initialize a session with the ICC 12, for example, by sending a Proximity Payment System Environment (PPSE) request. If the protocol request is blocked by the phone operating system, an alternative communication protocol using the NDEF wrapper 28 may be invoked.

[0027] At block 104, as part of the initialization, the NDEF application 40 may generate a nonce or random number from the SE 34. The nonce may be written to the tag memory location 48 on the smart chip 14. The nonce may be written to the tag memory location 48 before any other activity so that the payment application 26 can identify whether the payment applet 46 on the ICC 12 has updated the second memory with a new response by comparing the nonce to the previous nonce. This can help prevent data left over from a previous session from being interpreted as a valid response to a subsequent C-APDU sent by the payment application 26.

[0028] At block 106, the payment application 26 may write the C-APDU to the first memory location 42 using the NDEF 'write memory' command. Figure 5 The response at the card 12 is discussed, but briefly, the card operating system (not depicted) may initialize the NDEF application in response to card power-up or in response to data being written to the first memory location 42. The NDEF application 40 may be programmed to recognize the first memory location and instantiate the payment applet 46.

[0029] Once the payment applet 46 is active, the first memory location 42 may be read, interpreted, and processed, causing the R-APDU to be written to the second memory location 44. After writing the C-APDU to the first memory location 42, at block 108, the payment application 26 may begin reading data from the tag memory location 48.

[0030] Because there is no higher-level protocol communication between the payment application 26 and the payment applet 46, there is no signaling indicating whether a response to the C-APDU has been generated. To address this messaging flaw at the start of a transaction, at block 110, the payment application 26 may determine whether the tag memory location 48 contains an updated nonce compared to the previous message. If not, the payment applet 46 has not yet responded to the C-APDU, and the "yes" branch may be taken back to block 108. If the nonce has been overwritten, the payment applet 46 has already responded to the first payment transaction command, and execution may follow the "no" branch to block 112. Here, the value of the second memory location 44 may be interpreted as a response to the original C-APDU. The payment application 26 may generate a subsequent C-APDU, and at block 114, the payment application, via the NDEF wrapper 28, may write the C-APDU to the first memory location 42 on the smart chip 14.

[0031] At box 116, the payment application 26 can read the second memory location 44 and, as described above, determine at box 118 whether the content has changed, thereby indicating a response to the most recent C-APDU. If the content has not changed, execution returns to box 116 to continue. If the content has changed, execution can continue at box 120, where the R-APDU can be processed and, if necessary, another C-APDU can be generated. In an embodiment, a temporary number in the tag memory location 48 can be updated for each R-APDU written by the ICC. Execution can continue at box 114 until all communications required to complete the requested function are achieved. Using this technology, the smartphone 10 can simulate an actual contactless payment transaction without any direct communication between the payment application 26 on the smartphone 10 and the payment applet 46 on the ICC 12.

[0032] Figure 6 1 is a flow chart illustrating an exemplary method 140 of activities associated with using a Type 4 NFC tag as a protocol interface for the smartphone payment application 26 and the ICC payment applet 46 at the ICC 12. At block 142, the NDEF application 40 may be activated due to a triggering event. The triggering event may be powering on the card 12, writing to the first or second memory location, or other activity. In embodiments using a nonce rather than a sequence number, initialization may include generating and writing the nonce to the tag memory location 48, as described above.

[0033] At block 144, the payment applet 46 may compare the contents of the first memory location 42 with the previous value of the first memory location 42, or may otherwise evaluate the memory to determine whether an update has occurred. If the memory has been updated with new data, the contents may be read and evaluated by the payment applet 46 as a C-APDU. If the C-APDU is a select-pay APDU, the 'yes' branch may be taken to block 150. If the C-APDU is not a select-pay APDU, the 'no' branch may be taken and another C-APDU may be read at block 146. Block 148 may evaluate whether the C-APDU is a select-pay command. If not, execution may return to below block 142. If yes, execution may continue at block 150.

[0034] At block 150, processing the C-APDU may involve reading and parsing the C-APDU and preparing a response R-APDU. Preparing the response may involve any number of procedures, including but not limited to following, for example, The R-APDU may be written to the second memory location 44 along with the sequence number using a conventional payment protocol of the wireless payment protocol. After the R-APDU payload is prepared, the R-APDU may be written to the second memory location 44 along with the sequence number. As discussed above, the sequence number may start with a base number (e.g., 1) and increment for each message transmitted between two endpoints, which in this case are the terminal and the card 12.

[0035] Similar to the loop at block 144, the payment applet 46 may then begin reading the first memory location 42 at block 152 to determine whether the terminal has written a new C-APDU. If not, the first memory location 42 may be read after a time delay. If so, execution may continue at block 154, where the new C-APDU may be evaluated and, if present, a response prepared. The process of waiting for a new C-APDU may continue until the current operation is processed. Using this technique, the payment applet 46 is able to complete complex operations in the absence of any signaling between the payment application 26 and the payment applet 46.

[0036] Figure 7 is an exemplary illustration of a processing flow 200 for the payment applet 46. This processing flow 200 assumes that the NDEF application 40 is managing the interaction with the corresponding NDEF application / wrapper 28 on the smartphone 10 / terminal.

[0037] At block 202, the payment applet 46 looks for a select command. If present, execution continues at block 204 where the application identifier (AID) is parsed. If, at block 206, the AID is PPSE, the PPSE module may be activated to retrieve a C-APDU from the first memory location 42 at block 222. At block 226, the C-APDU may be processed, and at block 228, a responsive R-APDU with a sequence number may be written to the second memory location 44.

[0038] If the AID is not a PPSE at block 206, then at block 208, the AID may be evaluated to determine if it is a payment application AID. If so, the corresponding payment application may be activated and the C-APDU may be retrieved from the first memory location 42. Execution may then continue at block 226 as described above.

[0039] If the AID is not a payment application at block 208, execution may continue at block 210 to determine whether the AID exists. If so, the corresponding application may be instantiated, and from block 224 onward, the application may retrieve and process the C-APDU. If the AID does not exist at block 210, the 'no' branch may be followed, and an appropriate error status word may be written to the second memory location 44.

[0040] Returning to block 202, when the C-APDU is not a select command, at block 214, the C-APDU may be evaluated to determine if it is a 'Go Process Option' (GPO) command. If so, processing may continue at block 218 to determine if a payment application has been selected. If so, processing may continue at block 224, as described above, causing a new R-APDU to be written to the second memory location 44. If at block 214, the C-APDU is not a GPO command, execution may continue at block 216, where a determination may be made as to whether the C-APDU is a read record command. If so, execution may continue at block 218. If not, an error may be written via block 220. Returning to block 218, if a payment application has not been selected, the 'no' branch may be followed to block 220, and an error word may be written to the second memory location 44.

[0041] A technical problem arises when devices such as smartphones 10 block protocols required for certain applications to communicate. The systems and methods of the present disclosure provide a technical solution to this problem by employing a polling process over a minimalist file read / write protocol to allow communication between two modified endpoint applications. The modifications on each endpoint support falling back to a lower-level protocol while still supporting higher-level protocols when available.

[0042] The systems and methods of the present disclosure benefit smartphone users, payment card users, and payment card issuers. Smartphone users are no longer prevented from using their devices as payment terminals for complex NFC transactions, for example, allowing the acceptance of NFC-enabled payment cards to complete financial transactions. Cardholders benefit from having their cards accepted at additional merchants, while card issuers see their brand value enhanced by this additional usage capability.

[0043] The figures depict the preferred embodiment for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods shown herein may be used without departing from the principles described herein.

[0044] After reading this disclosure, those skilled in the art will understand additional alternative structural and functional designs for the systems and methods described herein using the principles disclosed herein. Thus, while specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the precise configurations and components disclosed herein. It will be apparent to those skilled in the art that various modifications, changes, and variations may be made to the arrangement, operation, and details of the systems and methods disclosed herein without departing from the spirit and scope of any of the appended claims.

Claims

1. A method for transferring application data between an NFC terminal and an integrated circuit card (ICC), the method comprising: specifying a first memory location on the ICC and specifying a second memory location on the ICC, the first memory location being designated for storing a command application data unit (C-APDU) and the second memory location being designated for storing a response application data unit (R-APDU); Writing a first C-APDU to the first memory location through an application on the NFC terminal, where the first C-APDU includes a first sequence number; Reading, by an application on the NFC terminal, a first R-APDU from the second memory location, wherein the first R-APDU includes a second sequence number, and the second sequence number is greater than the first sequence number; In response to the second sequence number in the R-APDU being greater than the first sequence number, processing the R-APDU at an application of the NFC terminal; Generate a subsequent C-APDU by the application on the NFC terminal; Writing the subsequent C-APDU to the first memory location on the ICC via an application on the NFC terminal; After writing a subsequent C-APDU to the first memory location on the ICC, reading the second memory location on the ICC by an application on the NFC terminal; comparing the content of the second memory location with the first R-APDU; as well as Repeating the steps of reading the content of the second memory location on the ICC and comparing the content of the second memory with the first R-APDU until the content of the second memory is different from the first R-APDU; Processing the content of the second memory into a second R-APDU; as well as Communication between an application on the NFC terminal and an applet on the ICC is accomplished using successive data transmissions through the first memory location for C-APDU data sent from the NFC terminal to the ICC and the second memory location for R-APDU data read from the ICC. 2 . The method according to claim 1 , further comprising generating, at the NFC terminal, the first sequence number before generating the first C-APDU to be sent to the ICC.

3. The method according to claim 1, further comprising: reading data at the first memory location through the applet on the ICC; evaluating said data into a C-APDU as part of a payment process; processing the R-APDU in response to a request associated with the C-APDU; as well as The R-APDU is written to the second memory location, thereby overwriting any existing data in the second memory location.

4. The method according to claim 1, further comprising: Before writing the first C-APDU to the first memory location, the first C-APDU is encrypted. 5 . The method of claim 1 , wherein writing the first C-APDU to the first memory location by an application on the NFC terminal comprises writing the first C-APDU using an NFC Type 4 Tag Write Memory command. 6 . The method of claim 1 , wherein reading the first R-APDU by an application on the NFC terminal comprises reading the first R-APDU using an NFC Type 4 Tag Read Memory command.

7. A system for transmitting application session data during an application session between an NFC terminal and an integrated circuit card (ICC), comprising: a first memory location on the ICC storing data available to both the ICC and the NFC terminal, the first memory location being configured to store a Command Application Data Unit (C-APDU); a second memory location on the ICC storing data available to both the ICC and the NFC terminal, the second memory location being configured to store a response application data unit (R-APDU); The NFC terminal executes an application, and the application performs the following steps: generating a unique number associated with the application session; Generate the first C-APDU; Writing the first C-APDU to the first memory location; reading the second memory location; determining that the second memory location contains an R-APDU; and Processing the R-APDU, and The applet on the ICC performs the following steps: checking the first memory location for a change from a previous value; responsive to the new value at the first memory location, processing the contents of the first memory location as a C-APDU; In response to the C-APDU, generate an R-APDU; as well as The R-APDU is written to the second memory location on the ICC, overwriting any previous data in the second memory location.

8. A system according to claim 7, wherein the applet contains a payment function and an NDEF function, the NDEF function responds to a trigger event caused by data being written to the first memory location, and the payment function performs transaction-related processing in response to a C-APDU associated with the payment request.

9. The system of claim 7, further comprising launching the applet on the ICC in response to an NFC Data Exchange Format (NDEF) message being written to the first memory.

10. The system of claim 7, wherein the unique number is a nonce, further comprising writing a tag memory location with the nonce, wherein determining that the second memory location contains an R-APDU comprises determining that the tag memory has a new nonce.

11. The system of claim 7, wherein the unique number is a sequence number that is incremented for each message transmission, the sequence number being included in the C-APDU.

12. The system of claim 7, wherein the unique number is a sequence number that is incremented for each message transmission, the sequence number being included in the R-APDU.

13. The system of claim 7, wherein the R-APDU contains a personal account number associated with the ICC, the ICC being a bank payment card.

14. A method for transmitting application protocol data between an NFC terminal and an integrated circuit card (ICC), the method comprising: reserving a first memory location on the ICC for receiving data from the NFC terminal; reserving a second memory location on the ICC for sending data to the NFC terminal; activating a payment applet on the ICC in response to data being written to the first memory location, wherein activating the payment applet on the ICC comprises setting a flag on the first memory location to activate the payment applet in response to receiving data at the first memory location; i) in response to determining that the contents of the first memory location are different from the previous contents of the first memory location, parsing the memory contents of the first memory location into a command application protocol data unit (C-APDU); ii) processing the C-APDU by the payment applet to generate a response application protocol data unit (R-APDU); as well as The R-APDU is written to the second memory location, wherein steps i and ii are repeated until the programming of the applet and the data processing function of the NFC terminal is completed.

15. The method of claim 14, wherein the ICC is a payment card.

16. The method of claim 14, wherein the protocol used to read and write data to the first and second memory locations is the NFC Data Exchange (NDEF) protocol.

17. The method of claim 14, wherein the R-APDU is an error message in response to the C-APDU being unparseable.

Images