KR101466963B1 - Tag storing multi NDEF data and updating method of the Tag - Google Patents

Abstract

A tag is provided that includes a tag platform that provides a file system. The file system includes a plurality of tag data files in which NDEF tag data is stored, an NDEF file including interworking information indicating at least one of the plurality of tag data files, and an NDEF file called by the NDEF file, And a CC file for acquiring NDEF data stored in the tag data file indicated by the tag data file. The tag can store, update, and manage a plurality of NDEFs in one tag.

Description

[0001] The present invention relates to a method and apparatus for storing multiple NDEF data,

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a wireless tag, and more particularly, to a configuration method and a data management / update method of an NFC tag capable of storing and selectively outputting a plurality of data.

An RFID (Radio Frequency Identification) technology is a type of short-range communication method in which information is obtained by performing data communication between an IC chip and a terminal provided in an object using radio waves (RF).

The electronic tag can be classified as having a memory element only and a CPU element having computing ability. Such electronic tags are generally used as a substitute for a transportation card, an ID card for identification, an electronic payment card, a library card, and a barcode used for distribution distribution management, and the use range thereof is gradually expanding. have.

The electronic tag records data information in the built-in IC chip device or reads the recorded data information. The electronic tag can be an active type or an inductively coupled type, a passive type, Type or an electromagnetic wave type.

 Such a passive type uses a coil antenna and receives radio waves of the terminal and processes the received radio waves to use as a power source for operation. The communication distance is short, and the active type is a built-in power source such as a battery And the communication distance can reach several tens of meters.

 Near Field Communication (NFC) technology has evolved from this electronic tag technology, and has been internationally standardized by the NFC forum. The NFC technique uses a frequency of the 13.56 MHz band to communicate data at close range in the range of about 5 Cm to 10 Cm.

In the case of the NDEF Type4 tag, which is implemented in the form of an applet on the smart card, various types of application services are possible due to the characteristics of the smart card providing high-level hardware and platform. The NDEF tag specification defined in the NFC Forum stores and manages a set of NDEF tag data. Consideration should be given to methods and devices for extending and applying the specification so that the smart card-based NDEF Type 4 tag application provides a function to store / manage multiple NDEF tag data.

An object of the present invention is to provide an NFC tag capable of storing a plurality of data.

Another object of the present invention is to provide a file structure of an NFC tag storing a plurality of data, and to provide a method and an apparatus for determining / updating data to be provided to a reader.

In one aspect of the present invention, a file system provided by a tag platform in a tag including a tag platform according to an embodiment of the present invention includes a plurality of tag data files storing NDEF tag data, An NDEF file including interworking information indicating at least one of the NDEF files, and a CC file that obtains NDEF data stored in the tag data file indicated by the interworking information of the NDEF file by calling the NDEF file.

Different NDEF data may be stored in each of the plurality of tag data files.

The interworking information may include an index number or an identifier of the plurality of tag data files.

The CC file may have an NDEF file control TLV field including management information and control information for the NDEF file.

In another aspect of the present invention, a method for changing NDEF data provided by a tag storing multiple NDEF data according to an embodiment of the present invention includes selecting a tag platform of the tag, And updating the interworking information set in the NDEF file of the NDEF file.

The interworking information may be information indicating at least one of a plurality of tag data files in which NDEF data included in the tag platform is stored.

Different NDEF data may be stored in each of the plurality of tag data files.

The tag may be implemented in a smart card or USIM.

According to another aspect of the present invention, there is provided a method of changing NDEF data provided by a tag storing multiple NDEF data, comprising the steps of: selecting a tag platform of the tag; Obtaining NDEF file control information and management information set in the TLV block, and updating NDEF data stored in the tag data file indicated by the NDEF file based on the NDEF file control information and management information.

The NFC tag provides a file structure of an NDEF Type 4 based NFC tag in which a plurality of data can be stored, thereby storing a plurality of data in one tag. It is possible to store a plurality of data in one tag and determine data to be provided to the tag reader as needed, thereby reducing the number of tags required for storing information.

In implementing the NDEF Type4 tag function for a high performance smart card (including all kinds of smartcard-based card, credit card, membership card, etc.), it is possible to standardize the method of supporting multiple tag data and diversify NFC-based services.

Figure 1 illustrates the structure of an NDEF tag application stored within a Type 4 tag platform.
2 is a block diagram showing the data structure of the CC file.
3 shows an example of a file system of a tag platform according to an embodiment of the present invention.
4 shows a specific embodiment of a tag for storing multiple NDEF data according to an embodiment of the present invention.
FIGS. 5 and 6 illustrate a data change setting procedure between a terminal and a tag for storing multiple NDEF data according to an embodiment of the present invention.
7 and 8 illustrate a data update procedure between a terminal and a tag that stores multiple NDEF data according to an embodiment of the present invention.
FIGS. 9 and 10 illustrate a procedure for updating data between a terminal and a tag storing multiple NDEF data and changing and providing data according to an embodiment of the present invention.
11 shows a C-APDU format defined by the NFC Forum.

While the present invention has been described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the invention. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. In addition, numerals (e.g., first, second, etc.) used in the description of the present invention are merely an identifier for distinguishing one component from another.

Also, in this specification, when an element is referred to as being "connected" or "connected" with another element, the element may be directly connected or directly connected to the other element, It should be understood that, unless an opposite description is present, it may be connected or connected via another element in the middle.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In order to facilitate a thorough understanding of the present invention, the same reference numerals are used for the same means regardless of the number of the drawings.

Figure 1 illustrates an NFC Data Exchange Format (NDEF) tag application stored within a Type 4 tag platform.

The NFC Forum defines three technology groups: NFC-A, NFC-B, and NFC-F. The three technology groups use the same 13.56 MHz radio carrier and each technology group can use the same protocol and instruction set, although each modulation scheme, bit-level coding and frame format can be used .

The Type 4 Tag Platform is a platform that supports NFC-A or NFC-B, including anticollision.

The Type 4 tag platform may include at least one NDEF tag application. An NDEF tag application may include an NDEF message of a type 4 tag platform. The Type 4 tag platform provides a file system consisting of at least two elementary files (EF) - Capability Container (CC or EFCC) files and NDEF files (EFNDEF).

2 is a block diagram showing the data structure of the CC file.

The CC file contains administrative data and is stored in a read-only EF file. More specifically, the CC file includes a CCLEN field, a Mapping Version field, a MLe field, an MLc field, an NDEF file control TLV field, and may further include a TLV Block field as needed.

Briefly describing the function of each field constituting the CC file, the CCLEN field is set to a value indicating the size of the CC file. The Mapping Version field is set to a value indicating a version of a mapping document applied to the Type 4 tag platform. The MLe field is set to a value indicating a maximum R-APDU (Response-Application Protocol Data Unit) data size, and the MLc field is set to a value indicating a maximum C-APDU (Command-Application Protocol Data Unit) data size. The NDEF file control TLV field is always present in the CC file and provides control information regarding the EF file containing the NDEF message. The NDEF file control TLV field may include file identifier (file identifier) information indicating a valid NDEF file, maximum size information of the NDEF file, and read / write access permission information to the NDEF file.

The NDEF file (EFNDEF), which is one of the EF files, contains NDEF data which is the actual tag data. An NDEF file can consist of an NLEN field and an NDEF message field. The NLEN field is set to a value indicating the size of data (NDEF message) stored in the NDEF file, and the NDEF message field stores data (NDEF message).

The file system of the conventional type 4 tag platform illustrated in FIG. 1 is composed of one CC file and one NDEF file. That is, one tag platform includes one NDEF file, and as a result, one data (NDEF message) is stored in one tag platform.

In order to provide a plurality of different data to a tag reader, such a file system requires as many tags as the number of data, and the limit of the tag which can store / supply only one information is limited to the use area of the tag . The present invention provides a tag platform file system capable of storing a plurality of different data in one tag and selectively providing stored data to the tag reader and selecting / updating data to be provided to the tag reader Provide procedures.

3 shows an example of a file system of a tag platform according to an embodiment of the present invention.

The file system of the tag platform according to the embodiment of the present invention includes a CC file, an NDEF file, and a plurality of tag data files. The example of FIG. 3 is an example including n tag data files, and each of the tag data files may store different NDEF tag data.

In the file system of FIG. 3, the NDEF file Control TLV field of the CC file and the CC file may be configured as the CC file of the conventional type 4 tag platform described with FIG. 1 and the NDEF file Control TLV field.

The NDEF tag application obtains control information from the NDEF file control TLV field in the CC file to access the NDEF file. At this time, the NDEF file according to the embodiment of the present invention does not record specific data (NDEF message) and provides a function to interoperate with the tag data file. That is, the NDEF file according to the embodiment of the present invention can be dynamically linked with another tag data file, and provides a function of changing the link file through a specific interface (API) provided by the type 4 NDEF applet.

A plurality of tag data files may exist, and each tag data file may include NDEF data (NDEF message 0 to NDEF message n-1). The tag data files can be linked with the NDEF file, and the tag data file linked with the NDF file can operate as the NDEF file of the conventional file system illustrated in FIG.

The file system of Fig. 3 includes a plurality of tag data files, and the NDEF file is interlocked with at least one of the plurality of tag data files. The NDEF file provides the tag data associated with the call to the CC file. Therefore, different tag data can be selectively provided as the tag data file indicated by the NDEF file (linked with the NDEF file) is updated.

4 shows a specific embodiment of a tag for storing multiple NDEF data according to an embodiment of the present invention.

In the example of FIG. 4, the mobile terminal is an example of a terminal that reads information stored in a tag or a terminal that updates / changes data provided by the tag. According to the embodiment, data update / change can be provided by an application installed in the terminal.

The tag shown in FIG. 4 is a tag for storing multiple NDEF data according to an embodiment of the present invention and is implemented in a smart card or USIM. Hereinafter, a tag for storing multiple NDEF data according to an embodiment of the present invention implemented in a mobile terminal supporting near field wireless communication and a smart card or a wake card will be described as an example, The terminal for changing / updating data may be a fixed type terminal in a specific place, and a function as a tag reader may be added according to the embodiment. Likewise, the tag for storing the multiple NDEF data according to the embodiment of the present invention is not limited to the form in which the smart card, the wisdom card, and the like are implemented.

In the example of FIG. 4, the NDEF file is interlocked with the tag data file 0, and when the tag reader requests the data, it can provide the NDEF message 0 stored in the tag data file 0 to the tag reader.

FIGS. 5 and 6 illustrate a data change setting procedure between a terminal and a tag for storing multiple NDEF data according to an embodiment of the present invention.

In the flowchart of FIG. 5, the 'SELECT' command is an instruction to select an application or a file, and the 'READBINARY' command is a command to read data from a file. The command may be transmitted to the tag in the C-APDU (Command APDU) format among APDUs (Application Protocol Data Units).

In order to change the NDEF tag data file to a specific file (tag data file 0 → tag data file 1), the terminal can use an instruction defined in the NFC forum, for example, the SET NDEF FILE command.

Select the NDEF tag application you want to change via the 'SELECT' command. The 'SELECT' command may include an indicator (for example, an application ID) indicating a tag application to be selected.

Then, the tag data file indicated by the NDEF file is set in the NDEF tag application selected through the SET command. The 'SET' command includes an indicator that indicates the tag data to be associated with the NDEF file. The NDEF tag application according to the embodiment of the present invention checks the validity of the parameter when the corresponding command is called and performs a procedure of changing the link of the NDEF File to the specified file (tag data file 0 → tag data file 1) do. 5 and 6 show an example of changing the previously set tag data 0 to the tag data 1.

In the example of FIG. 5, NDEF data (NDEF message 1 stored in the tag data 1) is received in response to the transmission of the READBINARY command and the response thereto in accordance with the following embodiment. The process is an example of the verification process.

7 and 8 illustrate a data update procedure between a terminal and a tag that stores multiple NDEF data according to an embodiment of the present invention.

7 and 8 are procedures for replacing the data itself stored in the tag. In the embodiment of Figs. 5 and 6, in which the data provided by the tag is changed (change of the data linked to the NDEF file) .

Select the NDEF tag application that you want to update data with the 'SELECT' command. The 'SELECT' command may include an indicator (for example, an application ID) indicating a tag application to be selected.

'READBINARY' command, and receives the data of the CC file provided by the tag in response thereto. At this time, the information that the UE acquires may be the value of the control information NDEF file Control TLV field of the CC file.

The UPDATEBINARY command is sent to erase the NDEF message stored in the replacement tag data file and write new data.

After that, it sends a READBINARY command and in response, acquires a replacement NDEF message provided by the tag to check whether it is updated.

FIG. 8 shows an example in which the existing NDEF message is deleted from the tag data file 1 and a new NDEF message is recorded in a state where the tag data file 1 is linked to the NDEF file.

FIGS. 9 and 10 illustrate a procedure for updating data between a terminal and a tag storing multiple NDEF data and changing and providing data according to an embodiment of the present invention.

Select the NDEF tag application that you want to update data with the 'SELECT' command. The 'SELECT' command may include an indicator (for example, an application ID) indicating a tag application to be selected.

The UPDATEBINARY command is sent to erase the NDEF message stored in the replacement tag data file and write new data.

After that, it sends a READBINARY command and in response, acquires a replacement NDEF message provided by the tag to check whether it is updated.

Then, the tag data file indicated by the NDEF file is set in the NDEF tag application selected through the SET command. The 'SET' command includes an indicator that indicates the tag data to be associated with the NDEF file. The NDEF tag application according to the embodiment of the present invention checks the validity of the parameter when the corresponding command is called and performs a procedure of changing the link of the NDEF File to the specified file (tag data file 1 → tag data file 2) do.

In the examples of FIGS. 9 and 10, the NDEF data (the NDEF message 2 stored in the tag data 2) is transmitted in response to the transmission of the READBINARY command and the response thereto, Is an example of a confirmation process.

11 shows a C-APDU format defined by the NFC Forum. For more details on the function of each field in the C-APDU format, refer to 'Type 4 Tag Operation Specification, NFC Forum-TS-Type-4-Tag_2.0' published by NFC Forum on June 28, 2011 .

Table 1 shows an example of values set in each field of a C-APDU to which a SET command can be applied, which can be applied to various embodiments of the present invention.

Code Value CLA '00' INS 'EC' P1 Index number of extended file (eg '01', '02')
or
'00' P2 '00' Lc '00': P1 is not '00'
or
'02': When P1 is '00' Data Empty: P1 is not '00'
or
Proprietary file ID: If P1 is '00' Le Empty Response Empty

The above-described embodiments include examples of various aspects. While it is not possible to describe every possible combination for expressing various aspects, one of ordinary skill in the art will recognize that other combinations are possible. Accordingly, it is intended that the invention include all alternatives, modifications and variations that fall within the scope of the following claims.

Claims (11)

10. A tag comprising a tag platform providing a file system, the file system comprising:
A plurality of tag data files for storing NDEF tag data;
An NDEF file including interworking information indicating at least one of the plurality of tag data files; And
And a CC file for calling the NDEF file and acquiring NDEF data stored in the tag data file indicated by the interworking information of the NDEF file
A tag that stores multiple NDEF data.
The method of claim 1, wherein
Wherein each of the plurality of tag data files stores multiple NDEF data in which different NDEF data are stored.
The method according to claim 1,
Wherein the interworking information stores multiple NDEF data including an index number or an identifier of any one of the plurality of tag data files.
The method according to claim 1,
Wherein the CC file stores multiple NDEF data including an NDEF file control TLV field including management information and control information for the NDEF file.
A Universal Subscriber Identity Module (USIM) comprising a tag for storing the multiple NDEF data of claim 1.
A smart card comprising a tag for storing the multiple NDEF data of claim 1.
A method for changing NDEF data provided by a tag storing multiple NDEF data,
Selecting a tag platform of the tag; And
Updating the interworking information set in the NDEF file of the file system provided by the tag platform,
The interworking information is information indicating at least one of a plurality of tag data files in which NDEF data included in the tag platform is stored
Way.
delete 8. The method of claim 7,
Wherein different NDEF data are stored in each of the plurality of tag data files.
8. The method of claim 7,
Wherein the tag is implemented in a smart card or a USIM.
A method for changing NDEF data provided by a tag storing multiple NDEF data,
Selecting a tag platform of the tag;
Obtaining NDEF file control information and management information set in an NDEF file control TLV block in a CC file of a file system provided by the tag platform; And
Updating the NDEF data stored in the tag data file indicated by the NDEF file based on the NDEF file control information and the management information
≪ / RTI >

Images