JP7287079B2 - CONVERSION PROGRAM, CONVERSION APPARATUS AND CONVERSION METHOD - Google Patents

Description

The present invention relates to technical fields such as programs related to data conversion between information processing terminals and communication modules.

An IC card, which includes an integrated circuit (IC), provides various services to users by executing application programs (“applications”).

On the other hand, users can enjoy various services such as e-mail and video distribution using a web browser of a personal computer connected to the Internet. In other words, users can use these services from any computer that is connected to the Internet and has a web browser installed.

On the other hand, it is important to use a web browser on a computer with security measures, as there is a possibility that private accounts may be used illegally or personal information and private data may be stolen. Security can also be enhanced through the use of IC cards that can securely store user credentials and can be used as an integral component of the login process to provide two-factor authentication. Under such circumstances, Patent Literature 1 discloses a technique for performing user authentication using an IC card when enjoying a service with a web browser.

JP 2016-144111 A

By the way, an IC card generally provides services by communicating with a reader/writer (R/W (Reader/Writer)) connected to an information processing terminal. A communication method between the application of the information processing terminal and the IC card at this time will be described with reference to FIG. An application installed in the information processing terminal provides services to the user through command/response exchange (“transaction”) with the IC card. PC/SC (Personal Computer/Smart Card) is a standard API (Application Programming Interface) for using an IC card in a Windows (registered trademark) environment. R/W reads and writes data to the IC card. An application is also installed in the IC card, executes processing according to the command, and returns a response to the source of the command.

An IC card to which the international standard ISO/IEC7816 is applied receives a C-APDU (Command-APDU), which is an APDU (Application Protocol Data Unit) containing a command from an application of an information processing terminal, and responds to the command. Processing is executed by an application installed in the IC card. Then, the IC card transmits (responses) an R-APDU (Response-APDU), which is an APDU including a 2-byte SW (Status Word) corresponding to the execution result of the process, to the application of the information processing terminal. In this manner, services are provided to the user through transactions in which commands and responses are exchanged between the application of the information processing terminal and the IC card. Specifically, as shown in FIG. 2(A), the C-APDU is transmitted from the application of the information processing terminal and reaches the IC card via the PC/SC and R/W. On the other hand, the R-APDU is transmitted from the IC card and reaches the application of the information processing terminal via the R/W and PC/SC.

On the other hand, IC cards are also used as SIMs (Subscriber Identity Modules) for communication carriers to identify subscribers. The SIM is used by carriers and IoT servers to authenticate IoT devices when they communicate with IoT servers. Here, the communication method between the application of the IoT device and the SIM will be described with reference to FIG. 1(B). An application installed in the IoT device executes command/response exchanges (transactions) with the SIM. The LTE communication module (LTE modem) communicates with the SIM and performs processing related to communication with a telecommunications carrier (not shown). An application is also installed in the SIM, and the application executes processing according to the command and returns a response to the source of the command.

SIM, which is a type of IC card, is subject to ISO/IEC7816, so it receives C-APDU from the IoT device (application), executes processing according to the command, and sends R-APDU to the IoT device (application). Send (reply). However, when an IoT device application transmits/receives C-APDUs and R-APDUs to/from an LTE communication module, it is necessary to follow the format of AT commands (Devices that need to communicate according to AT commands, such as LTE communication is sometimes referred to as an "AT command device"). Specifically, as shown in FIG. 2B, the application installed in the IoT device transmits a C-APDU to which an AT command header and footer are added to the LTE communication module. The LTE communication module that has received this transmits the C-APDU, excluding the AT command header and footer, to the SIM. On the other hand, the SIM executes processing according to the command and transmits R-APDU to the LTE communication module. The LTE communication module that has received this adds an AT command header and footer and transmits the R-APDU to the application. That is, data to which the AT command header and footer are added is transmitted and received between the application and the LTE communication module.

That is, when the destination of the C-APDU is the PC/SC from the viewpoint of the application of the IoT device, the AT command header and footer are not added and the C-APDU is transmitted as it is (Fig. 2(A)). If is an AT command device, the AT command header and footer are added and transmitted (FIG. 2(B)). Similarly, when receiving an R-APDU from the perspective of an IoT device application, if the sender is a PC/SC, the AT command header and footer need not be deleted, while if the sender is an AT command device, deletes the AT command header and footer. Therefore, an application developer must develop an application depending on whether the direct partner for sending and receiving APDUs is a PC/SC or an AT command device, which poses a problem of being a heavy burden. .

Therefore, in the present invention, even when an application communicates APDU with an IC card connected to an AT command device, the direct partner with which the application exchanges APDU is the PC/SC. It is an object of the present invention to provide a conversion program or the like that enables a developer to develop an application without being conscious of AT commands.

In order to solve the above-mentioned problems, the invention according to claim 1 provides a computer comprising: first receiving means for receiving an input of a C-APDU; and a first output means for outputting a C-APDU to which the AT command header and footer are added.

The invention according to claim 2 is the conversion program according to claim 1, wherein the computer is a second receiving means for receiving an input of R-APDU to which an AT command header and footer are added; Deleting means for deleting the AT command header and footer from the R-APDU to which the AT command header and footer are added and which is received by the receiving means; It is characterized by further functioning as output means.

The invention according to claim 3 is the conversion program according to claim 1, wherein when the destination of the C-APDU received by the first receiving means is a communication module, the C -adding an AT command header and footer to the APDU, wherein the first output means outputs the C-APDU to which the AT command header and footer are added to the communication module;

The invention according to claim 4 is the conversion program according to claim 2, wherein the deletion means transmits the R-APDU to which the header and footer of the AT command received by the second reception means are added. When the original is a communication module, the AT command header and footer are deleted from the R -APDU, and the second output means outputs the R-APDU from which the AT command header and footer are deleted to the C-APDU. is output to the input source of

The invention according to claim 5 is the conversion program according to claim 4, wherein the first byte of SW included in the R-APDU received by the second receiving means is "0x61". holding means for holding data received together with the SW, and the [GET RESPONSE] command when the first byte of SW included in the R-APDU received by the second receiving means is "0x61" adding an AT command header and footer to the C-APDU and further functioning as third output means for outputting to the communication module, wherein the AT command header and footer received as a response to the [GET RESPONSE] command are If the SW included in the added R-APDU is "0x9000", the deletion means deletes the AT command header and footer from the R-APDU to which the AT command header and footer are added, The second output means adds the data held by the holding means to the R-APDU from which the header and footer of the AT command have been deleted, and sends the data to the transmission source of the C-APDU accepted by the first accepting means. It is characterized by outputting.

According to a sixth aspect of the present invention, there is provided: first receiving means for receiving an input of a C-APDU; adding means for adding an AT command header and footer to the C-APDU received by the first receiving means; and a first output means for outputting a C-APDU to which the header and footer of the header and footer are added.

According to a seventh aspect of the present invention, there is provided a conversion method using a conversion device, comprising: a first receiving step of receiving an input of a C-APDU; and a first outputting step of outputting a C-APDU to which the AT command header and footer are added.

According to the present invention, by inputting a C-APDU, the AT command header and footer are added and output. The AT command device can receive the C-APDU received by the AT command device. Therefore, even when an application communicates APDU with an IC card connected to an AT command device, the direct partner with which the application exchanges APDU can be the PC/SC. Applications can be developed without being conscious of AT commands.

(A) is a diagram showing an example of a communication method between an application of an information processing terminal and an IC card, and (B) is a diagram showing an example of a communication method between an application of an information processing terminal and a SIM. (A) is a diagram showing an example of APDU transmission/reception between an application of an information processing terminal and an IC card, and (B) is a diagram showing an example of APDU transmission/reception between an application of an information processing terminal and a SIM. . 1 is a diagram showing a schematic configuration example of an IoT communication system S according to this embodiment; FIG. 1 is a block diagram showing a schematic configuration example of a microcomputer 11 according to this embodiment; FIG. 1 is a diagram showing an example of a communication method between an application of a microcomputer 11 and a SIM according to this embodiment; FIG. 4 is a diagram showing an example of APDU transmission/reception between an application of the microcomputer 11 and a SIM according to the present embodiment; FIG. 4 is a flowchart showing an example of conversion processing by the CPU 111 based on the conversion program according to the embodiment; 4 is a sequence diagram showing an operation example of the IoT communication system S according to this embodiment; FIG. 4 is a sequence diagram showing an operation example of the IoT communication system S according to this embodiment; FIG. FIG. 10 is a diagram showing an example of transmission and reception of APDUs between an application of the microcomputer 11 and a SIM according to a modification; 10 is a flowchart showing an example of conversion processing by a CPU 111 based on a conversion program according to a modification;

First, an embodiment of the present invention will be described. The present embodiment is an example in which the present invention is applied to a conversion program in the microcomputer 11 of the IoT device 1. FIG.

[1. Configuration of IoT system S]
The configuration and functional overview of the IoT communication system S will be described with reference to FIG. FIG. 3 is a block diagram showing a schematic configuration example of the IoT communication system S according to this embodiment. The IoT communication system S includes an IoT device 1 and an IoT server 2, and the IoT device 1 and the IoT server 2 can mutually transmit and receive data via the network NW. Note that the network NW is constructed by, for example, a LAN (Local Area Network), the Internet, a mobile communication network (including base stations and the like), a gateway, and the like.

The IoT device 1 includes a temperature sensor (not shown) and records temperature data obtained by measuring the ambient temperature. The IoT server 2 manages temperature data transmitted from the IoT device 1 and updates programs, information, etc. stored in the IoT device 1 . In order to ensure security, data transmitted and received between the IoT device 1 and the IoT server 2 is encrypted by key data managed by each before being communicated.

[2. Configuration of IoT device 1]
The IoT device 1 includes an LTE communication module 10 (an example of a “communication module”) that performs processing related to communication of the IoT device 1, a microcomputer 11 that controls the entire IoT device 1, and a SIM 12 connected to the LTE communication module 10. composed of

The LTE communication module 10 communicates with the SIM 12 and performs processing related to communication with a telecommunications carrier. The LTE communication module 10 transmits and receives data according to AT commands. In other words, when transmitting data such as C-APDU to the LTE communication module 10, it is necessary to add the header and footer of the AT command. On the other hand, when receiving data such as R-APDU transmitted from the LTE communication module 10, it is necessary to delete the header and footer of the AT command and handle the data.

The SIM 12 stores subscriber information (such as IMSI) used by the carrier to authenticate the SIM 12 and a key for encrypting/decrypting communication data communicated between the IoT server 2 and the IoT device 1 . The SIM 12 also stores a key for encrypting/decrypting information and data used by the IoT server 2 to authenticate the IoT device 1 . Note that the application of the microcomputer 11 of the IoT device 1 is in charge of the command response by APDU with the SIM 12 when the telecommunications carrier or the IoT server 2 performs authentication.

[3. Configuration of microcomputer 11]
FIG. 4 is a block diagram showing a schematic configuration example of the microcomputer 11 according to this embodiment. As shown in FIG. 4, the microcomputer 11 includes a CPU (Central Processing Unit) 111, a RAM (Random Access Memory) 112, a ROM (Read Only Memory) 113, an I/O section 114 and a non-volatile memory 115. , controls the entire IoT device 1 .

The RAM 112 stores, for example, data temporarily required for the OS (Operating System) and various applications to function. A flash memory or an "electrically erasable programmable read-only memory" can be applied to the nonvolatile memory 115, for example. The ROM 113 and the nonvolatile memory 115 store an OS, various applications, conversion programs to be described later, and the like. The I/O unit 114 serves as a communication interface with the LTE communication module 10 .

[4. conversion program]
Next, the communication method between the application installed in the microcomputer 11 and the SIM 12 and the conversion program will be described with reference to FIGS. 5 to 7. FIG. As shown in FIG. 5, APDU is transferred between the application 301 installed in the microcomputer 11 and the SIM 12 via the PC/SC 302, the conversion program 303, and the LTE communication module 10 (an example of an "AT command device"). . Note that the conversion program 303 functions as a device driver between the OS 300 and the LTE communication module 10 by being executed by the CPU 111 of the microcomputer 11 .

A specific description will be given below with reference to FIG. First, the application 301 delivers C-APDU to the PC/SC 302 (step S1). The PC/SC 302 then inputs the C-APDU to the conversion program 303 (step S2). When the conversion program 303 receives the input of the C-APDU, it performs header/footer addition processing for adding the header and footer of the AT command (step S3), and transmits the C-APDU to which the header and footer of the AT command are added through LTE communication. Output to the module 10 (step S4). Upon receiving this, the LTE communication module 10 interprets the header and footer of the AT command, and passes the C-APDU to the SIM 12 (step S5).

The application installed in the SIM 12 executes processing according to the command included in the C-APDU, and transfers the R-APDU including the response to the LTE communication module 10 (step S6). Upon receiving this, the LTE communication module 10 adds the AT command header and footer to the R-APDU and transfers it to the conversion program 303 (step S7). When the conversion program 303 receives the input of the R-APDU to which the AT command header and footer are added by the LTE communication module 10, it performs header/footer deletion processing for deleting the header and footer of the AT command (step S8), The R-APDU is output to PC/SC 302 (step S9). When the PC/SC 302 receives the R-APDU from the conversion program 303, it transfers it to the application 301 (step S10).

That is, when the conversion program 303 receives the C-APDU input from the PC/SC 302 , it adds the AT command header and footer to the C-APDU and outputs the C-APDU to the LTE communication module 10 . Further, when the conversion program 303 receives the input of the R-APDU to which the AT command header and footer are added from the LTE communication module 10, the conversion program 303 deletes the AT command header and footer and converts the R-APDU to the PC/ Output to SC302.

Here, conversion processing by the CPU 111 of the microcomputer 11 based on the conversion program 303 will be described with reference to FIG. FIG. 7 is a flowchart showing an example of conversion processing by the microcomputer 111. As shown in FIG.

First, the CPU 111 of the microcomputer 11 determines whether or not input of data (for example, C-APDU) has been received from the PC/SC 302 (step S101). When the CPU 111 determines that data has been received from the PC/SC 302 (step S101: YES), the CPU 111 adds an AT command header and footer to the received data to generate transmission data (step S102).

Specifically, the CPU 111 generates an AT command (Generic UICC logical channel access +CGLA) as transmission data. For example, the AT command (AT+CGLA) is
<sessionid>,<length>,<command><CR>
Consists of The CPU 111 describes in <sessionid> an integer value obtained as a response to an AT command (Open logical channel +CCHO) sent at the start of a session, in <length> describes the length of the C-APDU, and in <command>. describes the C-APDU. <CR> is a line feed code.

note that,
<sessionid>,<length>,<command><CR>
in
before <command>
<sessionid>,<length>
is the header of the AT command, and
after <command>
<CR>
is the footer of the AT command.

Next, the CPU 111 outputs the transmission data generated in the process of step S102 to the LTE communication module 10 (step S103), and proceeds to the process of step S101.

On the other hand, when the CPU 111 determines that data has not been received from the PC/SC 302 (step S101: NO), it then determines whether input of data (for example, R-APDU) has been received from the LTE communication module 10. Determine (step S104). When the CPU 111 determines that data has been received from the LTE communication module 10 (step S104: YES), the CPU 111 deletes the AT command header and footer from the received data to generate transmission data (step S105).

For example, the CPU 111, as a response corresponding to the AT command (AT+CGLA),
<CR><LF>+CGLA: <length>,<response><CR><LF>
<CR><LF>OK<CR><LF>
accept.
<length> describes the length of <response>. <response> describes the R-APDU. <LF> is a line feed code. The CPU 111 deletes the header and footer of the AT command when receiving the response. In other words, the CPU 111 leaves the <response> portion and deletes the other portions.

note that,
<length>,<response><CR><LF>
<CR><LF>OK<CR><LF>
in
before <response>
<length>
is the header of the AT command, and
after <response>
<CR><LF>
<CR><LF>OK<CR><LF>
is the footer of the AT command.

Next, the CPU 111 outputs the transmission data generated in the process of step S105 to the PC/SC 302 (step S106), and proceeds to the process of step S101. On the other hand, when the CPU 111 determines that data has not been received from the LTE communication module 10 (step S104: NO), the process proceeds to step S101.

It should be noted that step S104 is deleted, and in the process of step S101, it is determined whether or not the AT command header and footer are added to the input data. It is also possible to move to the process of S105 and, if "NO", move to the process of step S102. The conversion program 303 is a program that can execute both addition processing and deletion processing for the header and footer of the AT command. The addition program may be executed when the header and footer of the AT command should be added, and the deletion program may be executed when the header and footer of the AT command should be deleted.

[5. Communication of IoT system S]
Next, an example of communication in the IoT system S will be described with reference to FIGS. 8 and 9. FIG.

First, an example of communication when the application 301 installed in the microcomputer 11 transmits transmission data to the IoT server 2 will be described with reference to FIG.

As shown in FIG. 8, the CPU 111 (application 301) of the microcomputer 11 passes transmission data (for example, temperature data) to be transmitted to the IoT server 2 to the SIM 12 (step S201). Specifically, the CPU 111 (application 301) selects an encryption/decryption application installed in the SIM 12, and transmits C-APDU containing transmission data and a command to cause the application to encrypt the transmission data. Send.

Upon receiving the transmission data, SIM 12 encrypts the transmission data with an encryption key based on the selected application (step S202). The SIM 12 then delivers the encrypted transmission data to the microcomputer 11 (application 301) (step S203). Specifically, the SIM 12 transmits an R-APDU containing encrypted transmission data and a response composed of SW indicating the processing result of encryption processing.

Between the CPU 111 (application 301) and the SIM 12, transmission data (APDU) is transmitted and received via the PC/SC 302, the conversion program 303 and the LTE communication module 10, as described with reference to FIG.

When receiving the encrypted transmission data, the CPU 111 (application 301) of the microcomputer 11 transmits it to the IoT server 2 (step S204).

When the IoT server 2 receives the encrypted transmission data, it decrypts it using the decryption key (step S205).

Next, an example of communication when the IoT server 2 transmits transmission data to the application 301 installed in the microcomputer 11 will be described with reference to FIG.

As shown in FIG. 9, the IoT server 2 encrypts data to be transmitted to the IoT device 1 (for example, data for changing the setting of the temperature sensor) using an encryption key (step S251). The IoT server 2 then transmits the encrypted transmission data to the IoT device 1 (step S252).

The CPU 111 (application 301) of the microcomputer 11 delivers the received encrypted transmission data to the SIM 12 (step S253). Specifically, the CPU 111 (application 301) selects an encryption/decryption application installed in the SIM 12, and then decrypts the encrypted transmission data and the application decrypts the encrypted transmission data. send a C-APDU containing the command to

Upon receiving the encrypted transmission data, SIM 12 decrypts it with the decryption key based on the selected application (step S254). The SIM 12 then delivers the decoded transmission data to the microcomputer 11 (application 301) (step S255). Specifically, the SIM 12 transmits an R-APDU containing a response consisting of decoded transmission data and an SW indicating the processing result of the decoding process.

Between the CPU 111 (application 301) and the SIM 12, transmission data (APDU) is transmitted and received via the PC/SC 302, the conversion program 303 and the LTE communication module 10, as described with reference to FIG.

Thereby, the CPU 111 (application 301) of the microcomputer 11 receives the decoded transmission data.

As described above, the CPU 111 (an example of the “first receiving means”, the “addition means”, and the “first output means”) of the present embodiment receives input of C-APDU based on the conversion program 303, The AT command header and footer are added to the received C-APDU, and the C-APDU with the AT command header and footer added is output.

Therefore, according to the conversion program 303 of this embodiment, since the AT command header and footer are added and output by inputting the C-APDU, it is operated between the PC / SC and the LTE communication module 10 This allows the LTE communication module 10 to receive the C-APDU output by the PC/SC 302 . Therefore, even when the application 301 communicates APDU with a SIM (an example of an “IC card”) connected to the LTE communication module 10, the direct partner with which the application 301 exchanges APDU is the PC/SC 302. A developer of the application 301 can develop the application 301 without being aware of AT commands.

In addition, the CPU 111 of the present embodiment (an example of the “second receiving means”, the “deleting means”, and the “second outputting means”) uses the conversion program 303 to convert the R- An input of an APDU is accepted, the AT command header and footer are deleted from the received R-APDU to which the AT command header and footer are added, and the R-APDU with the AT command header and footer deleted is output.

Therefore, according to the conversion program 303 of this embodiment, by inputting the R-APDU to which the AT command header and footer are added, the AT command header and footer are deleted and output. is operated between the PC/SC 302 and the LTE communication module 10, and when the R-APDU to which the AT command header and footer output by the LTE communication module 10 is added, the AT command header and footer are deleted. PC/SC 302 can receive the received R-APDU. Therefore, even when the application 301 communicates APDU with a SIM (an example of an “IC card”) connected to the LTE communication module 10, the direct partner with which the application 301 exchanges APDU is the PC/SC 302. A developer of the application 301 can develop the application 301 without being aware of AT commands.

[6. Modification]
In some cases, the application 301 of the microcomputer 11 sends a command to the SIM 12 to send data, and the SIM 12 sends data as a response to the command to the application 301 . At this time, if the data to be transmitted cannot be transmitted in one response, the SIM 12 transmits part of the data to be transmitted and a specific SW to the application 301 as a response. At this time, "0x61" is set to SW1 (first byte of SW) in a specific SW, and a value indicating the remaining data size is set to SW2 (second byte of SW). When the application 301 receives a response in which SW1 is "0x61", it transmits a [GET RESPONSE] command for instructing transmission of the remaining data to SIM12, and SIM12 responds to the command by transmitting the remaining data and SW Send a response containing At this time, if the data to be transmitted cannot be transmitted in one response to the [GET RESPONSE] command, the data to be transmitted from the SIM 12 to the application 301 can be divided and transmitted by repeating these processes. can be done.

Therefore, the conversion program 303 in this modified example does not send the response to the PC/SC 302 (application 301) when the response from the SIM 12 includes a SW whose SW1 is "0x61". RESPONSE] command to SIM 12, SIM 12 receives all data to be transmitted to application 301, and collectively transmits data to be transmitted to PC/SC 302 (application 301). 10 and 11, the communication method between the application 301 installed in the microcomputer 11 and the SIM 12 and the conversion processing based on the conversion program 303 in this modified example will be described below.

Since steps S31 to S35 in FIG. 10 are the same as steps S1 to S5 in FIG. 6, description thereof will be omitted. However, it is assumed that the command transmitted from the microcomputer 11 (application 301) is a command for instructing the SIM 12 to transmit some data. On the other hand, if the data to be transmitted to the microcomputer 11 (application 301) cannot be transmitted at once, the SIM 12 divides it into R-Data1 and R-Data2 and transmits it (here, it divides into two data Although the case of transmission will be described, it is also possible to divide the data into N pieces of R-Data1 to R-DataN and then divide the data into N pieces for transmission). Specifically, the SIM 12 first passes an R-APDU containing a response composed of SW with R-Data1 and SW1 of "0x61" to the LTE communication module 10 (step S36). Upon receiving this, the LTE communication module 10 adds the AT command header and footer to the R-APDU and transfers it to the conversion program 303 (step S37).

On the other hand, when the conversion program 303 determines that the SW1 included in the R-APDU to which the header and footer of the AT command received from the LTE communication module 10 are added is "0x61", it temporarily holds the R-Data1. At the same time, it generates a [GET RESPONSE] command, adds an AT command header and footer to it, and executes an automatic transmission process to transmit it to the LTE communication module 10 (steps 38 and S39). Upon receiving this, the LTE communication module 10 deletes the AT command header and footer and passes the C-APDU to the SIM 12 (step S40). In response to this, the SIM 12 passes an R-APDU containing a response consisting of R-Data2 and SW "0x9000" (indicating normal termination) to the LTE communication module 10 (step S41). Upon receiving this, the LTE communication module 10 adds the AT command header and footer to the R-APDU and transfers it to the conversion program 303 (step S42).

When the conversion program 303 receives the input of the R-APDU to which the header and footer of the AT command are added from the LTE communication module 10 as a response to the [GET RESPONSE] command transmitted in step S39, the SW included therein is " 0x9000", and deletes the header/footer (step S43). In the header/footer deletion process, the header and footer of the AT command added to the R-APDU are deleted, and the R-APDU (that is, , R-Data1, R-Data12 and SW “0x9000”). The conversion program 303 then outputs the R-APDU to the PC/SC 302 (step S44). When the PC/SC 302 receives the R-APDU from the conversion program 303, it transfers it to the application 301 (step S45).

That is, when the conversion program 303 receives the input of the R-APDU including the SW whose SW1 is "0x61" from the SIM 12 via the LTE communication module 10, the R-APDU including the SW whose SW is "0x9000" is received. Until the input of APDU is accepted, transmission of C-APDU including [GET RESPONSE] command and temporary holding of divided data contained in R-APDU which is a response to this are repeated. Then, when the input of R-APDU (R-DataN) including SW whose SW is "0x9000" is received, all divided data (R-Data1 to R-DataN-1) temporarily held in this are received. It outputs the added R-APDU to PC/SC 302 .

Next, conversion processing by the CPU 111 of the microcomputer 11 based on the conversion program 303 in the modified example will be described with reference to FIG. FIG. 11 is a flow chart showing an example of conversion processing by the microcomputer 111 in the modified example. In FIG. 11, processing from step S151 to step S158 is added between the processing of step S104 and the processing of step S105 in FIG. 7, and the added portion will be mainly described here.

First, in step S104 of FIG. 11, when the CPU 111 of the microcomputer 11 determines that data has not been received from the LTE communication module 10 (step S104: NO), the process proceeds to step S101. On the other hand, when the CPU 111 determines that data has been received from the LTE communication module 10 (step S104: YES), the SW included in the received data R-APDU is "0x61XX" (that is, SW1 is "0x61XX"). ”) (step S151).

When the CPU 111 determines that the SW is "0x61XX" (step S151: YES), the divided R-Data (n is a natural number from 1 to N−1) included in the R-APDU is stored in the nonvolatile memory. 115 or RAM 112 (step S152). Next, the CPU 111 prepares a C-APDU containing the [GET RESPONSE] command, adds an AT command header and footer thereto, and generates transmission data (step S153). Next, the CPU 111 outputs the transmission data generated in the process of step S153 to the LTE communication module 10 (step S154), sets the temporary holding flag to ON (step S155), and proceeds to the process of step S101. The temporary hold flag is set to ON when the conversion program 303 temporarily holds the R-Data contained in the R-APDU including the SW "0x61XX".

On the other hand, when the CPU 111 determines that the SW is not "0x61XX" (for example, it is "0x9000") (step S151: NO), it then determines whether the temporary holding flag is on ( step S156). When the CPU 111 determines that the temporary hold flag is not ON (step S156: NO), the process proceeds to step S105.

On the other hand, when the CPU 111 determines that the temporary holding flag is ON (step S156: YES), the CPU 111 extracts the AT command header and footer from the received data (R-APDU including R-DataN and SW "0x9000"). is deleted, all the data (R-Data1 to R-Data (N −1)) is added ((R-APDU including R-Data1 to R-DataN and SW “0x9000”) as transmission data (step S157). It is set to OFF (step S158), and the process proceeds to step S106.

As described above, the CPU 111 (an example of the “holding means” and the “third output means”) of this modification, based on the conversion program 303, the first byte of SW included in the received R-APDU is “ 0x61”, the R-Data received together with the SW is retained, and the transmission data in which the AT command is added to the C-APDU including the [GET RESPONSE] command is output to the LTE communication module 10, and the [GET RESPONSE ] When the SW included in the R-APDU to which the header and footer of the AT command received as a command response is "0x9000", the R-APDU to which the header and footer of the AT command is added is sent to the AT The header and footer of the command are deleted, and the previously held R-Data is added to the R-APDU from which the header and footer of the AT command have been deleted, and then output to the transmission source of the C-APDU.

That is, when an R-APDU containing a response including SW "0x61XX" is transmitted from SIM 12, conversion program 303 does not return the R-APDU to microcomputer 11 (application 301), and SIM 12 does not return the R-APDU to microcomputer 11 (application 301), and then collectively transmit it to the microcomputer 11 (application 301). As a result, the number of communications between the microcomputer 11 (application 301) and the conversion program 303 can be reduced, and the processing time for transactions can be shortened.

1 IoT device 10 LTE communication module 11 microcomputer 111 CPU
112 RAMs
113 ROMs
114 I/O unit 115 nonvolatile memory 12 SIM
2 IoT server 300 OS
301 Application 302 PC/SC
303 conversion program

Claims (7)

the computer,
first receiving means for receiving input of C-APDU;
adding means for adding an AT command header and footer to the C-APDU received by the first receiving means;
a first output means for outputting a C-APDU to which the AT command header and footer are added;
A conversion program characterized by functioning as The conversion program according to claim 1,
said computer,
a second receiving means for receiving an input of an R-APDU to which an AT command header and footer are added;
Deletion means for deleting the AT command header and footer from the R-APDU to which the AT command header and footer are added and which is received by the second receiving means;
a second output means for outputting an R-APDU from which the header and footer of the AT command are deleted;
A conversion program characterized by further functioning as The conversion program according to claim 1,
When the destination of the C-APDU received by the first receiving means is a communication module, the adding means adds an AT command header and footer to the C-APDU;
The conversion program, wherein the first output means outputs a C-APDU to which the header and footer of the AT command are added to the communication module. The conversion program according to claim 2,
The deleting means deletes the AT command header and footer from the R-APDU when the transmission source of the R -APDU to which the AT command header and footer are added and received by the second receiving means is a communication module. delete and
The conversion program, wherein the second output means outputs the R-APDU from which the header and footer of the AT command are deleted to the input source of the C-APDU. The conversion program according to claim 4,
said computer,
holding means for holding data received together with the SW when the first byte of the SW included in the R-APDU received by the second receiving means is "0x61";
When the first byte of SW included in the R-APDU received by the second receiving means is "0x61", adding the AT command header and footer to the C-APDU containing the [GET RESPONSE] command, third output means for outputting to the communication module;
further function as
When the SW included in the R-APDU to which the header and footer of the AT command received as a response to the [GET RESPONSE] command is added is "0x9000",
The deletion means deletes the header and footer of the AT command from the R-APDU to which the header and footer of the AT command are added,
The second output means adds the data held by the holding means to the R-APDU from which the header and footer of the AT command have been deleted, and sends the data to the transmission source of the C-APDU accepted by the first accepting means. A conversion program characterized by outputting. a first receiving means for receiving an input of C-APDU;
adding means for adding an AT command header and footer to the C-APDU received by the first receiving means;
a first output means for outputting a C-APDU to which the AT command header and footer are added;
A conversion device comprising: A conversion method using a conversion device,
a first receiving step of receiving input of C-APDU;
an adding step of adding an AT command header and footer to the C-APDU received by the first receiving step;
a first output step of outputting a C-APDU to which the AT command header and footer are added;
A conversion method comprising:

Images