KR20190110337A - Multi smart card and method for providing it - Google Patents

Abstract

The present invention relates to a multi-smart card and a providing method thereof. The multi-smart card comprises: a first memory storing at least one of hardware, a card operating system (COS), virtual machine, and an application programming interface (API); and a second memory storing at least one applet driven in accordance with the COS and the virtual machine. The second memory includes one or more heap spaces independently operated from each other. Each of the heap spaces stores applet data having a unique application identifier (AID) and activates the applets of the heap space selected by selection of a user.

Description

MULTI SMART CARD AND METHOD FOR PROVIDING IT}

The present invention relates to a multi-smart card and a multi-smart card providing method for integrating multiple smart cards into a single card, and more particularly, to a multi-smart card for storing a plurality of smart card applets by dividing a memory space; The present invention relates to a multi smart card providing method.

A smart card is equipped with a microprocessor, card operating system, security module, memory management module, input / output module, etc., and has a built-in integrated circuit chip, the size of a credit card that can store and process information by itself. Say plastic card. Initially, smart cards provided a card platform capable of mounting only a single application program on an operating system. However, smart cards, which are being developed recently, implement a card platform having an open structure so that various applications can be loaded. In the smart card platform, an operating system (Card Operating System), a virtual machine (Virtual Machine), an application programming interface (API), and the like are provided on the hardware, and various applications are operated thereon.

A smart card has a file hierarchy such as DF and EF in a master file (MF), and an application identifier (AID), which is a dedicated file (DF) identifier, has a unique AID for each brand of a card company. In addition, the smart card activates the corresponding application function when the DF is selected. Recently, there is a case of issuing several brand payment cards in one card, which is possible because the relevant policies are prepared through consultation between card companies. However, in addition to such a negotiated policy, only one cash IC application may be issued to one card for a cash IC function and a transportation card function, and thus there is a problem in that the use is limited.

US Patent No. 6,760,815 (July 6, 2004 registration)

The present invention is designed to overcome the limitations of existing smart cards and to reflect consumer desire to integrate and hold multiple smart cards into a single card, and to provide a method for providing a multi smart card and a multi smart card. .

The present invention relates to a multi-smart card and a method of providing the same, and the multi-smart card according to an embodiment of the present invention comprises at least one of a hardware, a card operating system (COS), a virtual machine, and an API. 1 memory; And a second memory configured to store at least one applet running according to the card operating system and the virtual machine, wherein the second memory divides a heap space of the memory into two or more, Sub-heap space, the sub-heap section operates independently of each other, each sub-heap space stores applets with a unique Application Identifier (AID) Only applets in heap space can be implemented to be active.

Optionally, the first memory may not be changed, and the second memory may be implemented to be able to change the address value. In addition, the applets may each store a value for implementing at least one of a payment card function, a transportation card function, and a cash IC function. Applets can be stored in different memory addresses, and other applets can be designed so that they do not overlap with the stored memory addresses. At the user's option, when one heap space is activated, the remaining heap space remains inactive. At this time, the user's selection may be implemented through a selection button or MCU operation on the smart card or the connection between the smart card and the user mobile terminal.

In another embodiment, a method for providing a multi smart card according to the present invention may include: allocating a space of a memory capable of changing an address value for storing an applet among memories of a multi smart card; Dividing a heap space of the allocated memory into two or more to generate a plurality of sub heap spaces; And storing, in each of the sub heap spaces, applets having a unique Applicationi Identifier (AID), wherein at least two heap spaces operate independently of each other, and only applets in the selected heap space are activated according to the user's choice. You can do that.

The multi-smart card of the present invention is designed such that duplication of AID does not occur regardless of the policy of the card company or the issuer, so that a plurality of payment cards and functions can be mounted on a single smart card. In addition, by providing a multi-smart card containing a plurality of card information, without changing the existing infrastructure, it is possible to reduce the cost of new product development and commercialization.

1 is a view for explaining the structure of a smart card according to the prior art.
2 is a view for explaining a memory storage method of a smart card according to the prior art.
3 is a diagram illustrating an applet storage space of a smart card according to an embodiment of the present invention.
4 is a view for explaining an applet storage method of a smart card according to an embodiment of the present invention.
5 is a diagram illustrating an applet storage space of a smart card according to another embodiment of the present invention.
Like reference symbols in the various drawings indicate like elements.

Specific structural or functional descriptions of the embodiments according to the inventive concept disclosed herein are provided only for the purpose of describing the embodiments according to the inventive concept. It may be embodied in various forms and is not limited to the embodiments described herein.

Embodiments according to the inventive concept may be variously modified and have various forms, so embodiments are illustrated in the drawings and described in detail herein. However, this is not intended to limit the embodiments in accordance with the concept of the invention to the specific forms disclosed, it includes all changes, equivalents, or substitutes included in the spirit and scope of the present invention.

Terms such as first or second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another, for example without departing from the scope of the rights according to the inventive concept, and the first component may be called a second component and similarly the second component. The component may also be referred to as the first component.

When a component is said to be "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may exist in the middle. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that no other component exists in the middle. Other expressions describing the relationship between components, such as "between" and "immediately between" or "neighboring to" and "directly neighboring", should be interpreted as well.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprise" or "have" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof described herein, but one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, parts, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and are not construed in ideal or excessively formal meanings unless expressly defined herein. Do not.

1 is a view for explaining the structure of a smart card according to the prior art. Smart cards are designed to have a card operating system (COS) on the hardware and to run various applications on software such as virtual machines and APIs. Such software is stored in a memory mounted on a card. Generally, the operating system 130, the virtual machine 170, the API 150, and the like are stored in a read only memory (ROM) 110, and various applets 140, 160 and 180 are stored in the EEPROM 120. That is, the code of the COS is mainly stored in the ROM 110 by chip manufacturers, and the data used in the COS is stored in the EEPROM 120.

2 is a view for explaining a memory storage method of a smart card according to the prior art, it shows a memory address. As described in FIG. 1, unlike the operating system, the applets 210 are stored in an EEPROM, and thus are stored in a changeable data form, while the operating system 220 is stored in a ROM and cannot be changed. That is, in case of general PC, the operating system (OS) is installed in the disk space when the program is installed, whereas in the case of a smart card, a separate space (0x200000 ~ ~) separated from the operating system (220, 0x100000 ~ 0x15FFFF) even if a new applet is installed 0x49FFFF). Therefore, in the memory address, the change does not occur in the 0x100000 to 0x15FFFF areas, but only in the spaces of the 0x200000 to 0x49FFFF areas. According to such characteristics, ROM may be used for the 0x100000 to 0x15FFFF areas, and EEPROM may be used for the 0x200000 to 0x49FFFF areas.

Here, the space where the new applet is installed is called heap space. For example, in the case of Java programs, the Java Virtual Machine (JVM) is assigned memory usage rights from the operating system, and calls and executes the Java program. In other words, the virtual machine acts as a relay between the operating system and the applet (program) and performs memory management functions. At this time, the virtual machine divides and manages memory for various purposes. The memory is a class for storing class information, method information, variable information, etc., a stack created when a method is called, and a stack for storing values used for a method ( stack, objects, and heaps that store information and arrays of applets. As described above, the applets of the smart card can be stored using the space of the heap space.

3 is a view for explaining the applet storage space of the smart card according to an embodiment of the present invention, Figure 4 is a view for explaining the applet storage method. In the smart card according to the embodiments described in FIGS. 3 and 4, the heap space of the memory is divided into a plurality of regions to generate a sub-heap space, and an applet in each sub-heap space. To store them. As described in FIG. 1, the smart card is designed such that a card OS (COS) 130 exists on the hardware 190, and various applications are driven on software such as a virtual machine 170, an API 150, and the like. have. The card OS 130, the virtual machine 170, the API 150, and the like are stored in a ROM (Read Only Memory) as an immutable value, and the applets 300 containing the respective card information are stored in the EEPROM 120. Can be. In the present embodiment, the ROM and the EEPROM have been described as examples, but this is only an example and other types of storage spaces may be used. Hereinafter, an OS code and an applet code are stored in a first area having a large storage capacity, and OS setting values, initial key values, and applet data are stored in a second area having a relatively small storage capacity. I will explain. For example, the first space may have a capacity of 300 Kbytes to 400 Kbytes, and the second space may have a capacity of 16 K to 80 Kbytes.

However, the present invention is not limited thereto, and in the case of a storage space such as a flash memory, a ROM region fixedly used as a ROM may be used as the first region, and the other variable region may be used as the second region.

In the present embodiment, the card operating system 130, the virtual machine 170, and the API 150 are stored in the first area in the same form as the existing one, but the heap space 300 included in the second area is two or more. Can hold multiple card information separately. 3 and 4 illustrate an embodiment in which three cards (Card 1, Card 2, and Card 3) are included, but is not limited thereto. The heap space is divided into two or three areas. Can be designed to

As shown in FIG. 3, the heap space 300 stored in the second area includes a first sub heap space 310 for the first card Card 1 and a second sub heap for the second card Card 2. The space 320 may be divided into a third sub heap space 330 for the third card 3. Here, the partitioning of the heap space 300 may have an effect of partitioning the space as the address value allocated to the heap space is adjusted during design. Each divided sub heap space may store applets corresponding to a credit card, a debit card, a transportation card, a cash IC (cash in and out of an ATM device), and the like. At this time, the divided regions operate independently of other heap spaces. As an embodiment, the user may select and use a sub heap space to be used by using a physical selection device of the smart card (for example, a push button or a touch button) or an MCU. As another example, the user may select an area to use through a connection between the smart card and the smart phone (eg, pairing using short-range wireless communication such as NFC or Bluetooth). That is, the smart card may receive a command for selecting a card or select a service heap space to be used through authentication.

When one sub heap space (eg, Card 1) is selected, the selected sub heap space (Card 1) is activated, and applets stored in the space are activated. On the other hand, the remaining sub-heap spaces (Card 2, 3) is inactive, as if operating only as a card (Card 1) stored in the selected sub-heap space has the effect of operating as one card.

The divided sub heap spaces 310, 320, and 330 may store applets corresponding to credit cards, cash cards, transportation cards, ATM functions, and the like. For example, the existing smart card is equipped with one transportation card function and one cash IC function in one payment card, which issues one application DF (Dedicated File) per brand to one card. This is because it has a unique application identifier (AID) corresponding to the name of the DF. In other words, if you have Applet 1 for VISA card, Applet 2 for traffic card, and Applet 3 for ATM function, you will have unique AIDs corresponding to VISA, traffic card, and cash IC. Will be. In the case of a multi-card recently commercialized by using multiple payment cards, when multiple cards of the same brand (VISA or Master) are used, some AID ending points may be added or set differently according to related policies through agreement between card companies. Use a way to avoid it. However, the portion corresponding to the transportation card and the cash IC function cannot be issued by multiple brands on a single card since the AID of the cash IC cannot be distinguished by banks unless there is a policy consultation. That is, there is a limitation that only one transportation card function and a cash IC function can be mounted on one smart card.

Smart card according to an embodiment of the present invention, in order to solve this limitation, reflect the consumer desire to integrate and hold multiple smart cards in one card, the heap space itself for storing several applets itself By dividing into multiple pieces and storing each function in the sub-heap space, it is possible to implement a smart card capable of mounting a plurality of transportation card and cash IC functions other than a credit card.

As shown in FIG. 4, by subdividing the heap space where the applet data is stored and using the sub-heap spaces, the limitation of the existing multi-smart card is overcome, and multiple payment card information and various transportation cards in one smart card Function, cash IC (cash in and out) function can be mounted.

Referring to FIG. 4, in the case of Card 1, payment card information (eg, H company's credit card information) may be stored by assigning an address of 0x200000 to 0x20FFFF to Applet 1 (310). The Applet 2 can be equipped with T's transportation card function (0x210000 to 0x21FFFF) and the Applet N can be equipped with the A bank cash IC function (0x2N0000 to 0x2NFFFF). In the case of Card 2, payment card information (eg, check card information of S company) may be stored by assigning an address of 0x300000 to 0x30FFFF to Applet 1 (320). The Applet 2 can be equipped with C's transportation card function (0x310000 to 0x31FFFF) and the Applet N can be equipped with the B-bank cash IC function (0x3N0000 to 0x3NFFFF). As described above, the Card 3 330 may be equipped with various payment card information, a transportation card function, a cash IC function, and the like.

As such, when the sub-heap spaces 310, 320, and 330 are divided and used, each space is driven independently and selectively. When one space is selected, only the corresponding space is activated, and thus, AID for applets There is no case where the duplicates.

When the user selects a sub heap space or a card (eg, one of the first card 310 to the third card 330) to be activated by using a smart card selection device (eg, a selection button) or through the MCU, Applets stored on the card can be implemented to be activated. If any one of the first card to the third card is selected, the applets stored in the sub heap space of the card are activated. Each area is selectively activated, and applets corresponding to payment cards, transportation functions, or cash IC functions are stored in the corresponding areas, and activated according to selection.

The multi-smart card using the heap space partitioning is designed such that duplication of AID does not occur regardless of the policy of the card company or the issuer, so that a plurality of payment cards and functions can be mounted on a single smart card. In addition, by providing a multi-smart card containing a plurality of card information, without changing the existing infrastructure, it is possible to reduce the cost of new product development and commercialization.

5 is a diagram illustrating an applet storage space of a smart card according to another embodiment of the present invention. Unlike the memory structure of FIG. 3, in the embodiment of FIG. 5, a memory space may be divided for each operating system to use a multi booting or memory space separation technique.

As shown in FIG. 5, in addition to heap space partitioning, operating system (OS) spaces for operating the heap spaces 512, 522, and 532 may also be divided to be used individually. When operating system space is also separated, one operating system can be designed to be inaccessible to other spaces. For example, a user can select a space or function to use via a smart card, and depending on the selection, the OS can be booted and implemented to activate the sub heap space. If the user selects the operating system 1 514, the OS 1 may be activated to activate the heap space 512 for the card 1 to use the applets stored in the card 1.

Although the present invention has been described with reference to one embodiment shown in the drawings, this is merely exemplary, and those skilled in the art will understand that various modifications and equivalent other embodiments are possible therefrom. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

110: ROM 120: EEPROM
130: Operating System (OS) 140, 160, 180: Applet
150: API 310: first region
320: second region 330: third region

Claims (11)

A first memory configured to store at least one of hardware, a card OS, a virtual machine, and an API; And
A second memory configured to store at least one applet running according to the card OS and the virtual machine,
The second memory divides a heap space of the memory into two or more to generate a plurality of sub heap spaces,
The sub-heap section operates independently of each other, and each sub-heap space stores applets having a unique application identifier (AID), and only applet data of the selected sub-heap space is selected by the user. Multi-smart card, which is activated.
The method of claim 1,
The first memory cannot change an address value,
The second memory is a multi-smart card, characterized in that implemented to enable the change of the address value.
The method of claim 1,
And the applet data each store a value for implementing at least one of a payment card function, a transportation card function, and a cash IC function.
The method of claim 1,
The applet data is stored in different memory addresses, and the multi-smart card, characterized in that the other applet data is not duplicated with the stored memory address.
The method of claim 1,
According to the user's selection, if one sub heap space is activated, the remaining sub heap space is maintained in an inactive state.
The method of claim 1,
The selection of the user, multi-smart card, characterized in that implemented via the selection button on the smart card or MCU operation, or the connection of the smart card and the user mobile terminal.
Allocating a space of a memory capable of changing an address value to store at least one applet data among memories of the multi smart card;
Dividing the heap space of the allocated memory into two or more to generate a plurality of sub heap spaces; And
Storing applet data having a unique Application Identifier (AID) in each of the sub-heap spaces;
And the at least two heap spaces operate independently of each other, and only applet data of the selected heap space is activated according to a user's selection.
The method of claim 7, wherein
And wherein the applet data stores a value for implementing at least one of a payment card function, a transportation card function, and a cash IC function.
The method of claim 7, wherein
The applet data is stored in different memory addresses, and different applets are not duplicated with the stored memory address. The method of claim 7, wherein
According to the user's selection, when one sub heap space is activated, the remaining sub heap space is maintained in an inactive state.
The method of claim 7, wherein
The user's selection is implemented through a selection button on the smart card or MCU operation, or the connection between the smart card and the user mobile terminal.

Images