JP2011198298A - Ic card and computer program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an IC card, operating an application without changing the application even when specifications of API of a platform type OS are changed.SOLUTION: The IC card 1 includes: a wrapper API 330 for making OSAPI 310 provided by a platform OS 31 public to an application 32, wherein a software hierarchy 3 of the IC card 1 contains a wrapper module 33, which conducts the processing of transforming a format of argument delivered from the application 32 to a format of OSAPI 310 corresponding to the called wrapper API 330, and calling OSAPI 310 when one of the wrapper API 330 is called by the application 32, and transforming a return value received from the platform OS 31 to a data format of the called wrapper API 330 and delivering the same to the application 32.

Description

  The present invention relates to an IC card on which an operating system (OS) is mounted, and more specifically, an invention for enabling the same application to be used even if there are some differences in the operating system. is there.

  The type of operating system mounted on an IC card includes a native OS developed for a specific system and an electrically rewritable memory (for example, as described in “Background of the Invention” in Patent Document 1) , EEPROM) can be broadly divided into platform type OSs that can load a plurality of applications.

  Many platform-type OSs are realized by mounting virtual machines such as Java (registered trademark) and MULTIS (registered trademark) on the card OS that provides the basic functions of the IC card. The running application is mounted in a rewritable memory such as an EEPROM in an intermediate language format corresponding to the virtual machine of the platform type OS on which the application runs.

  An application that runs on a platform type OS operates using an API (API: Application Program Interface) for calling a function provided by the virtual machine of the platform type OS. , API versions provided in virtual machines may differ depending on the platform OS version.

  In addition, a card manager that operates on a virtual machine such as Java (registered trademark) is installed in an IC card of a financial institution, and the card manager manages locks of applications, card locks, and card locks. Although invalidation processing is performed, even if the version of the platform OS is the same, if the card manager is different, there is a difference in the API specifications provided by the card manager.

  In this way, even if the platform OS virtual machine is the same, if the API specifications called by the application are different, an application that matches the API specifications is created, as in the invention disclosed in Patent Document 1. The application is managed on the side that issues the IC card, and the application is issued according to the IC card to be issued.

Special table 2001-527474 gazette

  Certainly, if an issuing system such as the invention disclosed in Patent Document 1 is used, applications can be managed for each API specification of the platform type OS. Every time the API specification is changed, the application must be recreated, which is very troublesome.

  Accordingly, the present invention provides an IC card that can operate an application on the platform OS without changing the application even if the API specification of the platform OS is changed, and a computer program mounted on the IC card. The purpose is to do.

  A first invention for solving the above-described problem is an IC card on which a platform type OS (OS: Operating System) is mounted, and a wrapper API for exposing an OS_API provided by the platform type OS to an application. And when one of the wrapper APIs is called by the application, the argument format passed from the application is converted into the OS_API format corresponding to the called wrapper API, and the OS_API is called. When the return value received from the platform type OS is converted into the data format of the called wrapper API and delivered to the application, and when the OS_API corresponding to the wrapper API is used, the wrapper A It is an IC card, characterized in that application that operates by calling I are mounted.

  Further, the second invention is characterized in that the OS_API supported by the wrapper API includes an API provided by a card manager constructed on a virtual machine of the platform type OS. The IC card according to claim 1.

  Furthermore, a computer program for causing an IC card to function as the wrapper module according to any one of the first to second inventions.

  According to the present invention described above, an IC card that can operate an application on the platform type OS without changing the application even if the API specification of the platform type OS is changed, and a computer program mounted on the IC card Can provide.

The figure which showed the external appearance of the IC card which concerns on this embodiment. The block diagram of the IC chip mounted in an IC card. The figure explaining the software hierarchy of an IC card. The flowchart explaining operation | movement of a wrapper module. 2 is a diagram for explaining a software hierarchy in Embodiment 1. FIG. The figure explaining the software hierarchy of the IC card based on Open Platform and Global Platform. The figure explaining an example of wrapper API.

  From here, embodiments of the present invention will be described to the extent that those skilled in the art of the present invention can understand and implement the contents of the present invention.

  FIG. 1 is a view showing an appearance of an IC card 1 according to the present embodiment. The IC card 1 shown in FIG. 1 is a plastic card having the same size as a cash card or a credit card, and is mounted on the IC card 1. An IC chip 2 on which a platform type operating system (OS) and an application are mounted is molded on the IC module 2a.

  In FIG. 1, the IC card 1 according to this embodiment is a contact IC type card that performs data communication with a terminal (not shown) in a contact type, but the present invention does not depend on the IC card type and is wireless. It may be a non-contact IC card for data communication or a dual interface IC card having two communication functions of contact data communication and non-contact data communication.

  In addition, regardless of the shape of the IC card 1, the IC card 1 is not the same shape as the cash card, but has a shape in which the vicinity of the IC module 2a is cut into a rectangular shape, and is incorporated into a mobile phone or a smartphone (SIM) Identity Module).

  FIG. 2 is a block diagram of the IC chip 2 mounted on the IC card 1. As shown in FIG. 2, the IC chip 2 includes a CPU 20 (CPU: Central Processing Unit) having a calculation function, a random access memory 21 (RAM: Random Access Memory) as a volatile memory, and a read-only nonvolatile memory. 23 (ROM: Read Only Memory), EEPROM 22 (EEPROM: Electrically Erasable Programmable Read-Only Memory) as an electrically rewritable nonvolatile memory, and a clock received from the terminal in addition to the UART 24 for data communication with the terminal A timer 25 or the like having a function of measuring time using the BUS 26 is connected to the BUS 26.

  FIG. 3 is a diagram for explaining the software hierarchy 3 of the IC card 1 in the present embodiment. As shown in FIG. 2, the software layer 3 of the IC card 1 has three layers, and the hardware 30 (here, the IC chip 2), the platform OS 31, and the application 32 are arranged in order from the lowest layer.

  The platform OS 31 in FIG. 3 is an operating system created to provide basic functions of the IC card 1 such as data communication and read / write to memory, and to be able to add and delete applications. The OS_API 310 is a set of instructions and functions that provide basic functions of the IC card 1, and the program code of the platform type OS 31 is mounted in the ROM 23 of the IC chip 2.

  The application 32 operates on the platform OS 31 and is software for executing processing corresponding to the system in which the IC card 1 is used. The program code of the application 32 is mounted on the EEPROM 22 of the IC chip 2.

  The OS_API 310 provided by the platform type OS 31 is fixed depending on the type of the platform type OS 31, but the specification of the OS_API 310 may be changed as the platform type OS 31 is upgraded. In such a case, the specification of the old OS_API 310 is used. The application 32 created based on the above will not operate on the new version of the platform OS 31, and some kind of response is required.

  As a countermeasure when the specification of the OS_API 310 is changed, it may be possible to recreate the application 32. However, if the application 32 is recreated, all the tests related to the application 32 must be retested. 2, a wrapper module 33 (Wrapper Module) is mounted on the platform type OS 31, and the application 32 calls the OS_API 310 via the wrapper module 33, so that the difference of the OS_API 310 is obtained as a wrapper module. 33 so that it can be absorbed.

  The wrapper module 33 has a wrapper API 330 that is an API shared by the wrapper module 33. When the wrapper module 33 is called from the application 32, the format of the argument delivered from the application 32 corresponds to the wrapper API 330. This is a module that executes the process of converting the format of the returned OS_API 310 to the OS_API 310 and converting the format of the return value from the OS_API 310 to the data format of the wrapper API 330 and passing it to the application 32. Program code of the wrapper module 33 Are mounted on the EEPROM 22 of the IC chip 2. Note that the wrapper module 33 only needs to be associated with the OS_API 310 whose specifications may be changed, and the wrapper module 33 need not be associated with all the OS_API 310.

  FIG. 4 is a flowchart for explaining the operation of the wrapper module 33. When one of the wrapper APIs 330 of the wrapper module 33 is called from the application 32 (S1), the wrapper module 33 converts the argument delivered from the application 32 into an OS_API 310 format corresponding to the called wrapper API 330 (S2). ), And calls the OS_API 310 using the converted argument (S3).

  When the processing related to the OS_API 310 called by the wrapper module 33 is finished (S4) and the return value is delivered from the platform OS 31 to the wrapper module 33 (S5), the wrapper module 33 receives the return value delivered from the platform OS 31. The format is converted into the format of the wrapper API 330 called from the application 32 (S6), the return value converted into the format of the wrapper API 330 is delivered to the application 32 (S7), and the procedure of FIG. 3 ends.

  From here, an example when the IC card 1 is a Java (registered trademark) Card (hereinafter abbreviated as “JC”) will be described. FIG. 5 is a diagram for explaining the software hierarchy 4 in the first embodiment.

  As illustrated in FIG. 5, the software hierarchy 4 in JC includes hardware 40, a card OS 41, a JC virtual machine 42, a card manager 43, and an application 44 that operates on the JC virtual machine 42.

  The hardware 40 of the software hierarchy 4 illustrated in FIG. 5 corresponds to the IC chip 2, and the card OS 41 is software for controlling a circuit (for example, UART 24) and a memory (for example, EEPROM 22) provided in the hardware 40. It is.

  In the case of JC, a JC virtual machine 42 is mounted on the card OS 41, and the JC virtual machine 42 includes a virtual machine API 420 for providing the application 44 with a function (for example, reading / writing of a data object) of the JC virtual machine 42. Have.

  The card manager 43 provides a card manager API 430 that provides the application 44 with a function for locking the IC card 1 and a function for invalidating the IC card 1 in addition to loading / installing the application 44 operating on the JC virtual machine 42. At least.

  In the case of JC, even if the JC virtual machine 42 is the same, there are several types of card managers 43. As specifications of the card manager 43 of JC, Open Platform and Global Platform are well known. Since the card manager 43 has a difference in specifications with the card manager API 430, the wrapper module 45 described so far can be used so as to absorb the difference in the specifications of the card manager API 430.

  FIG. 6 is a diagram for explaining the software hierarchy of an IC card compliant with Open Platform and Global Platform. In FIG. 6, the IC card and software hierarchy 4a compliant with Open Platform, and the software hierarchy 4b of an IC card compliant with Global Platform. Is illustrated.

  In the software hierarchy 4a of the IC card compliant with the Open Platform, a card manager 43a conforming to the Open Platform specification and a wrapper module 45a conforming to the Open Platform specification are mounted. The card manager 43a has a card manager API 430a. The wrapper module 45a has a wrapper API 450a.

  In addition, a card manager 43b conforming to the Global Platform specification and a wrapper module 45b conforming to the Global Platform specification are mounted in the software hierarchy 4b of the IC card conforming to the Global Platform. The card manager 43b includes a card manager API 430b. The wrapper module 45b has a wrapper API 450b.

  The contents other than those described above are not different from the software hierarchy 4a shown in FIG. 4 in the software hierarchy 4a of the IC card compliant with the Open Platform and the software hierarchy 4b of the IC card compliant with the Global Platform.

  When one of the wrapper APIs 450a is called from the application 44, the wrapper module 45a included in the software hierarchy 4a of the IC card compliant with the Open Platform takes the argument passed from the application 44 as the format of the card manager API 430a corresponding to the wrapper API 450a. The card manager API 430a is called, and the return value delivered from the card manager 43a is converted into the format of the wrapper API 450a and delivered to the application 44.

  When one of the wrapper APIs 450b is called from the application 44, the wrapper module 45b included in the software hierarchy 4b of the IC card conforming to the Global Platform takes the argument passed from the application 44 as the format of the card manager API 430b corresponding to the wrapper API 450b. The card manager API 430b is called, and the return value delivered from the card manager 43b is converted into the format of the wrapper API 450b and delivered to the application 44.

  If the call name of each wrapper API 450a, b is made common and the application 44 is created so as to use this call name, the IC card conforming to the Open Platform can be used without changing the application 44. The application 44 can be operated even with an IC card compliant with Platform.

  FIG. 7 is a diagram for explaining an example of the wrapper API. In FIG. 7, the call name of the wrapper API 430 that invalidates the function of the card manager 43 is “boolean lockCardManager ()”, the call name of the wrapper API 430 that invalidates the IC card 1 is “boolean terminateCard ()”, and each wrapper API 430 is called. The name is common to the wrapper APIs 450a and 450b.

  According to FIG. 7, the IC card wrapper module 45a corresponding to the Open Platform disables the function of the card manager 43a with one of the card manager APIs 430a when the wrapper API 450a whose call name is boolean lockCardManager () is called. Static boolean openplatform.OPSystem.lockCardManager () is called, the return value from the card manager 43a is returned, and when the wrapper API 450a whose call name is boolean terminateCard () is called, one of the card manager APIs 430a , Invalidates the IC card 1, calls static boolean openplatform.OPSystem.terminateCard (), and returns the return value from the card manager 43a.

  The IC card wrapper module 45b corresponding to the Global Platform is one of the card manager APIs 430b and disables the function of the card manager 43b when the wrapper API 450b whose call name is boolean lockCardManager () is called. .OPSystem.lockCardManager () is called to return the return value from the card manager 43b. When the wrapper API 450b whose call name is boolean terminateCard () is called, the IC card 1 is one of the card manager APIs 430b. The static boolean openplatform.OPSystem. TerminateCard () is called, and the return value from the card manager 43b is returned.

  The case where there is a difference in the specifications of the card manager API 430 in FIG. 5 has been described so far, but the same applies to the case where there is a difference in the specifications of the virtual machine API 420 in FIG. When there is a specification difference between both the card manager API 430 and the virtual machine API 420, a wrapper API 43 corresponding to each specification difference is mounted on the IC card 1.

1 IC card 2 IC chip 3 Software layer 30 Hardware 31 Platform type OS
32 application 33 wrapper module 330 wrapper API

Claims (3)

  An IC card in which a platform operating system (OS) is mounted, and has a wrapper API for exposing an OS_API provided by the platform OS to an application, and one of the wrapper APIs is called by the application Then, the argument format passed from the application is converted into the OS_API format corresponding to the called wrapper API, the OS_API is called, and the return value received from the platform type OS is called. In addition, when using the wrapper module that executes the process of converting to the data format of the wrapper API and passing the data to the application, and the OS_API corresponding to the wrapper API, the wrapper API is called and operated. IC card application characterized in that it is implemented.   2. The IC card according to claim 1, wherein the OS_API supported by the wrapper API includes an API provided by a card manager built on a virtual machine of the platform OS. . A computer program for causing an IC card to function as the wrapper module according to any one of claims 1 to 2.

Images