Patent Description:
Conventionally, for example, following Patent Document <NUM> discloses a method of reusing identification data from an identification module in user equipment by a peripheral device.

Further previously proposed arrangements are disclosed in <CIT>, <CIT>, and <CIT>.

For example, an identifier for uniquely identifying a secure element is required for quality control and defect analysis in a market. However, in order to generate a unique identifier, there is a problem that labor and cost are required. Moreover, when the secure element performs contactless communication prescribed in ISO <NUM>, ISO <NUM> and the like with the outside, if a unique identifier regarding the communication is separately provided, labor and cost for generating the identifier are problematically doubled. Furthermore, in a case where the secure element employs a plurality of communication systems and uses a unique identifier for each system, it takes labor and cost for each system.

Therefore, it has been required to suppress the labor and cost for generating the unique identifier.

The present invention is defined by the independent claims, with various optional features being set out in the dependent claims.

A preferred embodiment of the present disclosure is hereinafter described in detail with reference to the accompanying drawings. Note that, in this specification and the drawings, the components having substantially the same functional configuration are assigned with the same reference sign and the description thereof is not repeated.

Note that, the description is given in the following order.

The present disclosure is preferably applied to, for example, a secure element (SE: hereinafter referred to as SE) that holds a parameter required for contactless communication. In order to perform the contactless communication prescribed in ISO <NUM>, ISO <NUM> and the like, an identifier for uniquely identifying the SE is required. In this embodiment, by applying the identifier to a plurality of communication protocols, labor and cost for generating a unique identifier are reduced. Specifically, in this embodiment, a part of a UID prescribed in ISO <NUM> is reused as a part of an IDm prescribed in ISO <NUM>.

The secure element is included in an information processing device that communicates with a reader/writer in a contactless manner. As the information processing device, a mobile terminal, a card, a wearable device, a television, and a personal computer are assumed. Furthermore, as the card, for example, a card having a contactless function such as a transportation card or an electronic money card is assumed. As the wearable device, a device having a clock function or a device used for a locker key and the like are assumed. When the reader/writer communicates with the information processing device, the reader/writer sends a polling command to the information processing device, and the information processing device returns a polling response to the reader/writer.

The unique identifier (UID) prescribed in ISO <NUM> is identification information unique to the information processing device. As a length of the UID, a single UID (specifically has a length of four bytes), a double UID (specifically has a length of seven bytes), and a triple UID (specifically has a length of ten bytes) are prescribed, and there is a room for extension if a numerical range becomes insufficient due to future extendability. The UID is prescribed as any one of a unique value set in advance, a random number dynamically generated by the information processing device (allowed only for the single UID), and a non-unique fixed number (allowed only for the single UID). In this embodiment, a case of the double UID in the example of the unique value set in advance is described as an example.

<FIG> is a schematic diagram illustrating a byte sequence of the UID. As illustrated in <FIG>, in a case of the double UID, the UID includes seven bytes from UID0 to UID6. According to ISO <NUM>, a first byte UID0 is assigned for each manufacturer, and is prescribed as ensuring uniqueness of the manufacturer. Furthermore, each manufacturer sets a unique value by taking uniqueness of other byte values (UID1 to UID6). By configuring the UID in this manner, each UID has uniqueness.

<FIG> is a schematic diagram illustrating a byte sequence of the IDm. The IDm being an ID for the reader/writer to identify the information processing device with which this communicates is a byte sequence including eight bytes continuous from a next byte of a response code of the polling response returned by the information processing device that receives the polling command, and is a number numbered by a business operator that manufactures the secure element included in the information processing device. By setting the IDm in a parameter of the command, the reader/writer may specify the information processing device of the same IDm and perform communication. In other words, the IDm has a function of an identifier for identifying the information processing device in a communication protocol.

Values of upper two bytes of the IDm are referred to as a manufacturer code being an identification number for identifying the manufacturer, and following six bytes are referred to as a card identification number being an identification number for uniquely identifying the card. Furthermore, in a case where there is a plurality of systems (in a case of emulating a specific service by each applet to be described later, corresponding to the number of applets) in the card, the IDm is set for each system. In this case, upper four bits of the manufacturer code indicate an in-card system number. Note that, although a case where the information processing device is the card is herein described as an example, the same applies to a case of the portable terminal and a case of the wearable device.

<FIG> is a schematic diagram illustrating a configuration of the manufacturer code. For the manufacturer code in which a lower one byte is FEh, a system of the card identification number is prescribed. A system vendor numbers other values for a card manufacturer (that assigns the IDm), and the card manufacturer assigns the card identification number to each card according to the system prescribed by the card manufacturer. Therefore, each IDm has uniqueness.

A system code (SC) is a two-byte value included in the polling command for specifying the system, and is assigned for each business operator and each purpose of use. For example, the system code specifies services such as a fare prepaid service in a transportation business and electronic money used in a usage fee prepaid service in a convenience store or a supermarket. Note that although a case where consideration is paid in advance as the electronic money is described, the present invention is also applicable to a wide variety of services such as a service such as a credit card to be settled later, and a payment service using a point or electronic information usable as consideration immediately managed by a server via a network, and is not limited to a specific service. The reader/writer specifies the system code in the parameter of the polling command, and a card with the same system code returns the polling response. In other words, when the reader/writer sends the polling command, this sends the system code in order to determine whether or not the card has a specific system. Only the card having the specific system defined by the system code returns the IDm. As is described later, the polling response includes the IDm, SC, and PMm.

<FIG> is a schematic diagram illustrating an example of conversion from the UID to the IDm according to this embodiment. In general, chip vendors pay a lot of effort for uniquely numbering the UID. Depending on the system, there is a method of collectively delivering the UIDs and reconfirming whether the values are appropriately set, or a method of preventing overlapping by including physical wafer position information or a wafer number in the UID. There are various numbering methods depending on how the chip vendor generates the UID, but any method requires labor to generate a unique value. Similarly, it takes labor to uniquely generate the IDm.

In an upper diagram in <FIG>, a method for uniquely numbering six bytes of the UID (UID1 to UID6) is illustrated. <FIG> illustrates an example of preventing the overlapping with physical position information from the center of the secure element in the wafer device (bytes <NUM> and <NUM>), the wafer number (byte <NUM>), a wafer manufacturing device number (byte <NUM>), and values indicating a wafer manufacture date as numerical values (bytes <NUM> and <NUM>). Chips numbered in this manner have different UIDs. Note that, the method herein illustrated is an example, and six bytes of the UID ensure the uniqueness by various methods.

As for the IDm, similarly, since uniqueness is basically required for the chip vendor, if the uniqueness is required for both the UID and the IDm by a similar method, twice the man-hour is required.

Therefore, in this embodiment, as illustrated in <FIG>, by applying information of UID1 to UID6 to D2 to D7 in an IDm format, respectively, IDm values may ensure the uniqueness without change.

As described above, UID0 is the ID indicating a specific manufacturer, and ensure identity of the manufacturer. Furthermore, the IDm values D0 and D1 serve as the manufacturer code, and ensure the identity of the manufacturer. Therefore, by switching UID0 to D0 and D1, identity of a product may be ensured in a number system assigned by the same manufacturer.

As described above, in this embodiment, when converting from the UID to the IDm, UID0 that is the ID of the manufacturer is removed from the UID, and the manufacturer code D0 and D1 of the IDm values is newly added. In contrast, the information of UID1 to UID6 is applied to D2 to D7 in the IDm format, respectively, without change. Therefore, it becomes possible to convert from the UID to the IDm by simple processing.

As described above, each manufacturer ensures the uniqueness of other byte values (UID1 to UID6) except UID0. Therefore, by applying UID1 to UID6 to D2 to D7 in the IDm format, respectively, the uniqueness of the IDm may be ensured.

<FIG> are schematic diagrams illustrating variations of a connection configuration of the secure element. <FIG> illustrate the secure element wirelessly connected to a reader/writer <NUM>. More specifically, in <FIG>, the configurations other than the reader/writer <NUM> is formed in the information processing device.

In <FIG>, a contactless frontend (CLF) <NUM> is a chip having a wireless function. The contactless frontend (CLF) <NUM> collectively performs RF side processing such as A/D conversion. A UICC <NUM> being the secure element is configured by a SIM card. The UICC <NUM> ensures a communication function with a base station and performs authentication.

<FIG> illustrates a configuration example obtained by removing the communication function from the UICC <NUM> in <FIG>. A configuration of a secure element (SE) <NUM> is obtained by removing the communication function from the UICC <NUM>. Other configurations in <FIG> are similar to those in <FIG>.

<FIG> is a configuration example in which the CLF <NUM> and the UICC <NUM> in <FIG> are integrated. <FIG> is a schematic diagram illustrating an example in which the CLF <NUM> and the SE <NUM> in <FIG> are integrated. <FIG> is a schematic diagram illustrating an example in which the CLF <NUM> is configured alone without the SE <NUM> in <FIG> provided.

As illustrated in <FIG>, the method according to this embodiment is also applicable to firmware or a kernel deployed on the CLF in addition to the SE. Furthermore, a program corresponding to an applet <NUM> does not need to be separated from an operating system (JavaCard OS <NUM> to be described later) such as a program on the firmware and kernel, and may be included as the program in the operating system. For example, in a case of a configuration including a mobile terminal (DH) that performs host card emulation (HCE) and the CLF, there is no SE, but the IDm for ISO <NUM> may be generated from the UID held by the CLF. In contrast, uniqueness in a tamper resistant device such as especially the SE is linked to a global mechanism such as social ID management and passport, and social responsibility is heavy in a case where value overlapping occurs. Therefore, it is assumed that double check or triple check is performed for preventing the overlapping, and that a cost is higher than that in general numbering in examinations. Therefore, especially in the SE, by converting from the UID to the IDm by the method of this embodiment, it is possible to ensure that there is no overlapping and to suppress the cost required for numbering.

Furthermore, in <FIG>, a DH <NUM> is a device host and has a function of a mobile terminal. The DH <NUM> is connected to the SE by ISO <NUM> or SPI.

<FIG> is a schematic diagram illustrating a software configuration (configuration of the secure element) of an information processing device <NUM> according to this embodiment. As illustrated in <FIG>, hardware (H/W) <NUM>, kernel <NUM>, the JavaCard OS <NUM>, a JavaCard API <NUM>, and the applet <NUM> are layered in this order from a lower layer. The hardware <NUM> includes a CPU, a memory and the like, and has a configuration in which they are connected to each other via a bus. The applet <NUM> is an application (program) downloadable as appropriate, the program that operates in an intermediate language of a JavaCard. The JavaCard OS <NUM> serves as software, that is, an operating system (OS), and the applet <NUM> is layered thereon via the JavaCard API <NUM>. Note that the operating system is an example of software, and the software may be the firmware or kernel. "Downloadable" in <FIG> indicates that other applets are downloadable.

<FIG> is a schematic diagram illustrating the configuration of the information processing device <NUM> according to this embodiment in further detail. In detail, the JavaCard OS <NUM> includes a JavaCard runtime environment (RE) and a JavaCard vitual machine (VM), and the JavaCard RE is provided with a contactless registry service (CRS (open extension)) 104a as a configuration that ensures a management function. Furthermore, the JavaCard API <NUM> is provided with a CRS API 106a.

The CRS 104a manages information of the applet <NUM>, and extends the management function indicated as "OPEN" in <FIG> while specializing the same in a parameter management function used for the contactless communication with the reader/writer. Note that the management function (OPEN) of the JavaCard OS <NUM> is prescribed by an organization called as GlobalPlatform. The management function (OPEN) mainly manages information regarding the applet <NUM>, and the information managed by the management function (OPEN) includes an application identifier (ID), presence or absence of the contactless function, key information, an occupied memory size, package information and the like.

The CRS API 106a is the API for the applet <NUM> to make contact with the CRS 104a. The applet <NUM> may set data in the CRS 104a for communicating with the outside through the contactless frontend (CLF) <NUM> via the API 106a.

The CLF <NUM> for wirelessly connecting to the outside is connected to the DH <NUM> having a function of a mobile terminal. Note that the UICC (not illustrated in <FIG>) is responsible for a call function.

When the command is received from the external reader/writer <NUM>, the CLF <NUM> interprets the same and transfers data to the UICC <NUM> or the SE <NUM>. Note that the SE <NUM> is connected to the DH <NUM> by another communication protocol (ISO <NUM>, SPI, or UART).

<FIG> is a schematic diagram illustrating a procedure for generating the IDm from the UID. A serial number <NUM> including the UID is stored in the JavaCard OS <NUM> being the operating system. The serial number <NUM> is obtained by the applet <NUM> via the API <NUM>. Therefore, the applet <NUM> obtains the UID included in the serial number <NUM>. As described above, the UID is set as the unique value in the information processing device.

The applet <NUM> generates the IDm by removing the first byte UID0 from the UID, and adding the manufacturer code. As described above, by applying the information of UID1 to UID6 to D2 to D7 in the IDm format, respectively, the IDm value may ensure the uniqueness.

Furthermore, the applet <NUM> adds the system code (SC) and PMm to the IDm and sends the same to the CRS 104a of the JavaCard OS <NUM> via the API <NUM>. PMm is data for setting a standby time at the time of the polling response. These IDm, SC, and PMm are set as contactless parameters in the CRS 104a.

In this manner, the CRS 104a may generate response data to be returned when the polling command is sent via the CLF <NUM>. When the polling command is sent to the secure element via the CLF <NUM>, the CRS 104a returns the IDm, SC, and PMm as the polling response.

As an example to which the UID and the serial number of this embodiment are applied, there is card production life cycle (CPLC) data defined in a public "Open Platform Card Specification Version <NUM>. Furthermore, similarly applicable identifiers include Card Serial Number (CSN), Card Image Number (CIN), Integrated Circuit Card Identification (ICCID) and the like. These pieces of information include individually delivered information, information written at once at shipment time and data writing time, vendor identification information, information for identifying the chip and OS and the like. Furthermore, depending on companies, a part of the data serves as the UID. This embodiment is widely applicable to these identifiers.

Regarding management of the serial number, in a case of the secure element illustrated in <FIG>, there are a case where the serial number is incorporated in an IC chip which is the hardware <NUM>, a case where the serial number is managed by the kernel <NUM>, and a case where the serial number is managed by the JavaCard OS <NUM>. In a case of requiring the uniqueness, it is more convenient to incorporate the serial number in the IC chip because the serial number is fixed. Alternatively, in a case where the serial number is dynamically changed for each phase, there is a case where the serial number may be more flexibly changed by managing the same in an upper layer. In <FIG>, a layer for managing the serial number is denoted by "SN".

Furthermore, <FIG> is a schematic diagram illustrating a configuration of the CLF <NUM> and corresponds to the example illustrated in <FIG>. As illustrated in <FIG>, in the CLF <NUM>, hardware (H/W) <NUM>, an interface protocol <NUM>, and CLF firmware <NUM> are layered in this order from a lower layer. The hardware <NUM> includes a CPU, a memory and the like, and has a configuration in which they are connected to each other via a bus. There are a case where the serial number is incorporated in an IC chip which is the hardware <NUM> and a case where the interface protocol <NUM> holds the serial number as information required for RF protocol. As in a case of the SE, in a case of requiring the uniqueness, it is more convenient to incorporate the serial number in the IC chip because the serial number is fixed. Alternatively, in a case where the serial number is dynamically changed for each phase, there is a case where the serial number may be more flexibly changed by managing the same in a protocol layer. Also in <FIG>, the layer for managing the serial number is denoted by "SN".

In the example described above, the information set in the secure element in the form of the serial number is applicable to the UID used in a communication protocol referred to as Type A, and when the applet <NUM> may obtain the serial number, the applet <NUM> converts the serial number and sets the same in the CRS 104a as a contactless parameter for Type F. Therefore, the polling command from the CLF <NUM> may be included in the polling response to be returned.

In the example described above, an example of generating the IDm using the value of the UID included in the serial number is described; however, the value of the UID may be used without change to be used as data for generating the IDm.

Specifically, by using the serial number as an input of original data of key generation to which a cryptographic algorithm (AES CMAC and the like) is applied as a key derivation function (KDF) or a hash function, it is possible to ensure the uniqueness without directly using the value of the serial number. KDF is defined in NIST SP <NUM>-<NUM>, and HMAC or CMAC is described in Chapter <NUM> Pseudorandom Function (PRF) as an example. Regarding the hash function, there is one capable of generating data of <NUM> bytes such as MD5 and SHA1, and one that generates data of <NUM> bytes such as SHA256. Alternatively, the serial number may be used as a seed for random number generation. By using a setSeed method of the JavaCard API to set the serial number as the seed, it is possible to generate a random number that is less likely to be overlapped by utilizing the uniqueness. By performing the above-described calculation on the applet <NUM> side, the IDm may be changed as appropriate.

Furthermore, since there is an identifier called as a Pseudo-Unique PICC Identifier (PUPI) also in Type B, this may be similarly applied.

Furthermore, although ISO <NUM> is described above, it is also possible to divert to an identifier that requires uniqueness at the time of communication such as ISO <NUM> Type V (wireless RF), ultra wideband (UWB), Bluetooth (registered trademark) Low Energy (BLE), and Transfer Jet. As an example of ISO <NUM> Type V (wireless RF), ubiquitous ID <NUM>-bit (<NUM>-byte) fixed value
(http://www. jp/seisakutokatsu/jiritsu/siyousho/<NUM><NUM>/990_J003. pdf) may be mentioned.

Claim 1:
An information processing device (<NUM>) comprising:
software configured to register first identification information therein; and
an application configured to:
obtain the first identification information from the software,
convert the first identification information into second identification information for communication by removing a part of information from the first identification information and newly assigning another code prescribed in a format of the second identification information; wherein information remained after removing the part of information is information for ensuring uniqueness under a specific environment, and is identification information numbered to implement uniqueness by incorporating at least any one of a specific law, a physical law, a physical phenomenon, position information, and time information, and
register the second identification information in the software;
wherein the first identification information and the second identification information are for uniquely identifying a secure element of the information processing device.