BACKGROUND ART A smart card is a chip or a credit card containing a circuit capable of simple computation and data storage, for performing various functions by interfacing with a point-of-sale (POS) system, an ATM machine, or a device having a card reader such as a telephone, a vending machine or a computer. The convenience of the smart card has made it very popular.

A check card and a credit card are examples of the smart card. The smart cart is also used as a points card for depositing points provided by a company or a shop, or for storing information of a user.

As described above, the smart card has been implemented to suit various application fields. For implementing the smart card in an application field, an application program must be installed in the smart card.

However, the application program is integrated with an operation system of the smart card. Thus, an application provider cannot directly install an application program in the smart card.

To overcome this problem, an open platform technology for smart cards has been introduced. This allows the application provider to directly install an application program in the smart card only if granted an authentication from the card issuer.

According to the open platform technology, one or more application programs can be installed in single smart card after the smart card is issued.

FIG. 1 is a block diagram of an open platform smart card according to the prior art.

The open platform smart card 100 includes a card manager 103 having an issuer

security domain 101 and an open platform environment 102; a card issuer application 130; an application provider security domain 110; and an application provider application 120.

The open platform smart card 100 also includes a runtime environment (not shown) and an open platform application program interface (not shown) for driving the card manager 103.

The issuer security domain 101 is a domain allocated to the issuer of the smart card for storing a key set provided to the card issuer, and also performs loading, installing or removing card contents of the card issuer or an application provider.

Other than that, the issuer security domain 101 performs the same functions as the application provider security domain 110.

The open platform environment 102 provides an application program interface to the installed application for using functions of the card manager 103. The open platform environment 102 manages the card contents.

The card manager 103 is a representative module of the card issuer. The card manager 103 includes the issuer security domain 101, the open platform environment 103 and cardholder verification methods.

The application provider security domain 110 is a representative module of the application provider, and stores the key set of the application provider. The application provider also manages keys, encodes data, decodes data, generates a signature and verifies the signature.

The card issuer application 103 is an application program installed in the smart card by the card issuer. The application provider application 120 is an application installed in the smart card by the application provider after being granted permission by the card issuer. That is, the application provider is granted the permission from the card issuer through delegated management.

FIG. 2 is a flowchart of a method for installing an application program of an application provider in an open platform smart card according to the prior art.

Referring to FIG. 2, the application provider transmits a target application program to a card issuer in operation 201. The target application program is an application program that the application provider wants to install in the open platform smart card.

The card issuer inspects the target application program to determine whether the

target application program is suitable for the card issuer's smart card, and whether the target application program includes any viruses, in operation 202. Then, the card issuer generates a token permitting the installation of the target application program, by the delegated management. The generated token further includes a loading command and an installing command. Also, the card issuer generates a data authentication pattern (DAP) by encoding the generated token and the target application program by using the card issuer's key based on a hash function for guaranteeing the integrity of the permitted application program. The generated token and the generated DAP are transmitted to the application provider in operation 203.

The application provider encodes the target application program and the data authentication pattern (DAP) by using a key of the application provider based on a symmetric key encoding method or an asymmetric key encoding method, and downloads the encoded target application program and the encoded DAP to the open platform smart card 100 using a predetermined card recognition device in operation 204.

An application provider security domain 110 decodes the data coded by the application provider using the key of the application provider stored in the open platform smart card 100, and transmits the DAP, the token and the target application program to the issuer security domain 101 of the card manager 103 in operation 205.

The issuer security domain 101 generates the DAP again by using the key of the card issuer stored in the smart card 100. After generating the DAP, the issuer security domain 101 compares the generated DAP and the received DAP and if they are identical confirms that the application downloaded from the application provider is authenticated by the card issuer in operation 206.

If the downloaded application is authenticated by the card issuer, the downloaded application is loaded and installed based on information of the received token in operation 207.

After installation, a receipt representing completion of installation is generated, and the receipt is transmitted to the application provider, in operation 208.

As mentioned above, the application provider installs the target application program in the open platform smart card 100 based on the delegated management, without bringing the smart card 100 to the card issuer. However, this method for installing the application program in the smart card is still inconvenient for the

application provider, because complicated preparation is needed before installing the target application in the smart card. For example, the card issuer must grant the authentication to the application provider before the target application program can be installed.

If the application provider is a bank or a card firm having the ability to manufacture smart cards, they may avoid installing additional application programs in an issued smart card. It is more convenient to issue new cards with the additional application program to all customers than to install the application program in all the issued smart cards after being granted authentication from the card issuer.

However, it is uneconomic to issue new smart cards to all customers whenever additional application programs are required for the issued smart cards, because of the cost of manufacturing the smart cards.

Also, when multiple card issuers need to be included in the smart card, multiple chips are included in single smart card as shown in FIG. 1. Therefore, the number of the card issuers is limited by the size of the smart card. Furthermore, additional card issuers cannot be added to the prior art smart card after issue.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of a open platform smart card according to the prior art ; FIG. 2 is a flowchart of a method for installing an application program of an application provider in an open platform smart card according to the prior art; FIG. 3 is a block diagram of a smart card according to a preferred embodiment of the present invention; FIG. 4 is a flowchart of a method for installing multiple issuer security domains in a smart card after issuing the smart card, according to a preferred embodiment of the present invention; FIG. 5 is a flowchart of a method for removing an issuer security domain stored in a smart card, according to a preferred embodiment of the present invention; and FIG. 6 is a flowchart of a method for selecting an issuer security domain in a smart card, according to a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Technical Goal of the Invention The present invention provides a smart card containing multiple card issuer security domains.

The present invention also provides a method for adding and deleting one or more card issuer security domains in a smart card.

Disclosure of the Invention According to an aspect of the present invention, there is provided an open platform smart card for containing multiple issuer security domains, the open platform smart card comprising: a key package database unit for storing key packages used according to card issuers; an issuer security domain unit for managing the operations of loading, installing and deleting an application for one of the card issuers; and a key package managing unit for selecting a key package of a predetermined card issuer from the key package database unit and providing the selected key package to the issuer security domain, wherein the issuer security domain performs operations as an issuer security domain of the predetermined card issuer by using the provided key package by the key package managing unit.

The application installed in the open platform smart card includes identification information of an issuer security domain of a card issuer to which the application belongs, and wherein the open platform smart card further includes a firewall for preventing access to the application through a security domain of a card issuer to which the application does not belong, by using the identification information included in the application.

According to another aspect of the present invention, there is provided a method for installing multiple issuer security domains in a smart card including a key package database unit for storing key packages used according to card issuers; a virtual issuer security domain unit for receiving a selected key package of a predetermined card issuer from among the key packages stored in the key package database unit and performing operations as an issuer security domain of the predetermined card issuer by using the selected key package, the method including: determining whether a user is allowed to register in the smart card as a card issuer; receiving information including a key package used in an issuer security domain of the user for installing an issuer security domain when the user is allowed ; and storing the key package in the key

package database.

The determining whether the user is allowed is performed by using a key which is stored in the smart card by a card issuer registered in the smart card.

Determining whether the user is allowed is performed by using a combination key which is generated by combining keys which are stored in the smart card by all card issuers registered in the smart card.

The method for installing multiple issuer security domains further includes : storing a key for authenticating installation of an issuer security domain of a second user who wants to install an issuer security domain, after installing the issuer security domain of the user.

The method for installing multiple issuer security domains further includes : receiving a selection of an issuer security domain for managing installation of the user's issuer security domain; and detecting a key package used for the selected issuer security domain from the key package database unit and providing the detected key package to the virtual issuer security domain.

According to another aspect of the present invention, there is provided a method for selecting an issuer security domains in a smart card in which multiple issuer security domain can be installed, including a key package database unit for storing key packages used according to card issuers; a virtual issuer security domain unit for receiving a selected key package of a predetermined card issuer among the key packages stored in the key package database unit and performing operations as an issuer security domain of the predetermined card issuer by using the selected key package, the method including: receiving a card issuer identification information of an issuer security domain; extracting a key package of the received identification information from the key package database; and providing the extracted key package to the virtual issuer security domain unit for the virtual issuer security domain unit to perform operations as the issuer security domain.

According to another aspect of the present invention, there is provided a computer readable recording medium for embodying the above mentioned methods of the present invention.

Effect of the Invention According to present invention, multiple card issuers can install multiple issuer

security domains in single smart card. Therefore, each of the card issuers may not independently issue smart cards.

BEST MODE FOR CARRYING OUT THE INVENTION In the present invention, a smart card is not limited to a plastic card such as a credit card. The smart card may be any object which can perform the functions of the smart card according to the present invention. An integrated chip installed in a mobile phone may be one implementation example of the present invention.

Also,"an application"represents an application program programmed according to the purpose of the smart card, such as depositing points, verifying a cardholder, or electronic money. The application is not only a program provided from an application provider, but also a program of a security domain. Also, in the present invention, the terms"application"and"application program"are used interchangeably.

FIG. 3 is a block diagram of a smart card according to a preferred embodiment of the present invention.

As shown in FIG. 3, the smart card 300 includes a key package manager 380, a key package database 390 and a virtual issuer security domain 301. The smart card 300 is divided into two regions, each of which belongs to each card issuer. The smart card 300 includes card issuer applications 330 and 360, application provider security domains 310 and 340 and application provider applications 320 and 350, according to the card issuers. Also, the two regions of the smart card 300 are separated by a firewall 370 for blocking the exchange of data between the two regions.

Also, the smart card 300 further includes fundamental elements such as an open platform environment, a card manager, a runtime environment and an open platform application program interface, which are identical to the open platform environment 102, the card manager 103, the runtime environment (not shown) and the open platform application program interface (not shown) in FIG. 1. Since the fundamental elements of the smart card 300 perform identical functions to those already explained with reference to FIG. 1, their detailed explanation is omitted.

The key package database 390 stores key packages of multiple card issuers.

Each of the key packages includes a generated token for delegated management, a key for generating a receipt representing the completion of a command, a key for data authentication pattern (DAP) verification, a key for maintaining

communication security between a card and a terminal, a key used in an application of the card issuer, and a key used for a predetermined purpose of other card issuers.

The key package manager 380 determines the target card issuer of a received command, extracts a key package of the target card issuer, and provides the extracted key package to the virtual issuer security domain 301.

The virtual issuer security domain 301 is identical to the issuer security domain 101 in FIG. 1. That is, the virtual issuer security domain 301 loads, installs or removes card contents of a card issuer or an application provider, and performs various functions such as encoding, decoding, signature generation and signature verification.

The difference of the virtual issuer security domain 301 from the issuer security domain 101 is that the virtual issuer security domain 301 receives a key package of the card issuer from the key package manager 380. That is, the virtual issuer security domain 301 does not store the keys of a card issuer.

In terms of structure, there is only one issuer security domain in the smart card 300. However, the virtual issuer security domain 301 provides same result as multiple issuer security domains, since the virtual issuer security domain 301 uses key packages stored in the key package manager 380 according to a card issuer. For example, in the case of using a key package of a first card issuer, the virtual issuer security domain 301 becomes an issuer security domain of the first card issuer. Also, in the case of using a key package of a second card issuer, the virtual issuer security domain 301 becomes an issuer security domain of the second card issuer.

In the FIG. 3, the application provider security domain 310, the application provider application 320 and the first card issuer application 330 are applications installed by the first card issuer or an application provider granted authentication from the first card issuer through delegated management. The application provider security domain 340, the application provider application 350 and the second card issuer application 360 are applications installed by the second issuer or an application provider granted authentication of the second card issuer through the delegated management.

Each of the applications 310,320, 330,340, 350 and 360 includes the identification of the corresponding application provider security domain 310 or 340, or a card issuer security domain.

The firewall 370 prevents unauthorized access to an application by using a

security domain of a card issuer by which the application is not installed, based on an application identification of a security domain of a card issuer or the application provider security domains 310 and 340, which is recorded in each application.

FIG. 4 is a flowchart of a method for installing multiple issuer security domains in a smart card after issuing the smart card, according to a preferred embodiment of the present invention.

In the present invention, installation of an issuer security domain involves storing a key package of the additional card issuer in the key package database 390. That is, by storing the key package of the card issuer, the present invention can provide the same result as installing the issuer security domain of the card issuer after issuing the smart card.

After issuing the smart card 300, the smart card 300 may include one or more issuer security domains. That is, the key package database 390 may store one or more key packages.

As shown in FIG. 4, a new card issuer connects the smart card 300 to a host computer 400 having a card recognition function, and an issuer security domain is selected, in operation 401.

In the case of one card issuer being registered in the smart card 300, the smart card 300 responds to the host computer 400 by providing the key package of the registered card issuer to a virtual security domain 301. In the case of multiple card issuers being registered in the smart card 300, the smart card 300 responds to the host computer 400 by providing a key package of a default card issuer to the virtual issuer security domain 301, or by providing a key package of a card issuer selected by the new card issuer to the virtual issuer security domain 301. The default card issuer is a card issuer pre-set by selecting one of the card issuers registered in the smart card 300 as the default card issuer.

Each card issuer is assigned a unique identification, and information of the identification is known. If the new card issuer selects one of the card issuers stored in the smart card, a selection command of issuer security domain and an identification of selected card issuer are transmitted through the host computer 400. Then, the key package manager 380 extracts a key package of the selected card issuer in the key package database 390 by using the received identification of the selected card issuer, provides the extracted key package to the virtual security domain 301, and responds to

the host computer 400 in operation 402. The selecting issuer security domain will be explained later with reference to FIG. 6.

The above described operations 401 and 402 are performed to select a subject for installing an issuer security domain, and for enabling data transmission between the host computer 400 and the smart card 300, before installing the issuer security domain in the smart card 300. However, an issuer security domain of a card issuer belonging to a key package currently provided to the virtual issuer security domain may be determined as the subject of installation without selecting one of card issuers stored in the smart card 300. Therefore, the operations 401 and 402 are not necessary for installing the issuer security domain.

However, the operations 401 and 402 become necessary when a predetermined card issuer is set for installing the issuer security domain.

The new card issuer requests a command of installing a key package used in its issuer security domain, and verification through the host computer 400, in operation 403.

The key for authentication request may be a key of one of the card issuers registered in the smart card 300, or may be a key generated by combining keys of all the card issuers registered in the smart card 300.

After the new card issuer is registered in the smart card 300, the new card issuer can install applications in the smart card 300 without needing permission from other card issuers. If one of the registered card issuers installs too many applications, there may be not enough storage space left in the smart card 300 for other card issuers.

Furthermore, the smart card 300 is manufactured by the first card issuer, and additional card issuers use the smart card 300 without paying for manufacturing the smart card 300 after issuing the smart card 300. Therefore, it is inappropriate to install additional card issuer's security domains without the permission of the first card issuer who manufactures the smart card 300. Therefore, it is preferable that the new card issuers need authentication from other registered card issuers.

It may be set to grant authentication from all registered card issuers, or to grant authentication from a predetermined registered card issuer, for installing a new issuer security domain.

In the case of requiring the predetermined card issuers'authentication, a key is allocated from that card issuer for authentication of a key package installation

command.

It is preferable to store a key corresponding to the allocated key in the key package manager 380. An encoding method using the allocated key may be performed in various ways, such as symmetric or asymmetric encoding. That is, the host computer 400 encodes the issuer security domain installation command based on a predetermined method by using the allocated key, and transmits the encoded issuer security domain installation command. The virtual issuer security domain 301 receives the encoded command and transfers the encoded command to the key package manager 380, in operation 404. The key package manager 380 decodes the encoded by a previously stored key, and verifies the installation command, in operation 405.

Also, the predetermined card issuer may transmit an electronic signature for verifying the integrity and the installation command directly to the new card issuer, for installing the issuer security domain of the new card issuer without allocating the key for authentication to the new card issuer.

In the case of requiring the authentication of all card issuers, the new card issuer receives the keys from all the registered card issuers and combines the keys for encoding, decoding or electronic signature.

The card issuer which is authenticating the new card issuer transfers a key used for authentication of the installation to the new card issuer.

The new card issuer generates a new key by combining the keys from all registered card issuers, according to a predetermined order. By using the generated key, the new card issuer performs the operations of encoding and electronic signature for installing the issuer security domain.

The key package manager 380 stores keys of card issuers and generates a key corresponding to the key generated by the new card issuer, since the order of combining keys is predetermined.

It is preferable to store a key value used for authenticating other card issuers' installation of security domains in the key package manager 380 or the key package of the new card issuer, after installing the issuer security domain of the new card issuer.

As well as the above described authentication method, other authentication methods may be implemented in the present invention.

After authentication of installing the issuer security domain, the result of the authentication is transmitted to the host computer in operation 406. The host

computer 400 registers the key package of the new card issuer. That is, the host computer 400 transmits information on installing the issuer security domain of the new card issuer to the key package manager 380, in operation 407.

The information on installing the issuer security domain includes a key package having a key for generating a token for delegated management, a key for the receipt representing the completion of a command, a key for data authentication pattern verification (DAP verification), a key for maintaining communication security between a card and a terminal, a key used in an application belonging to the card issuer; an application identification of the key package; and identification information of the new card issuer.

The key package manager 380 determines whether an identical key package has been previously installed, or whether the maximum number of stored key packages has been exceeded, in operation 408. That is, the key package manager 380 determines the possibility of registering the transmitted key package by inspecting the application identification of the transmitted key package.

If the key package is allowed to be installed, the key package manager 380 stores the transmitted key package in the key package database 390 in operation 409.

The key package manager 380 informs the host computer 400 that the transmitted key package has been stored, in operation 410, and registers the identification of the new card issuer with the virtual issuer security domain 301 in operation 411. After this, a user can select the issuer security domain of the new card issuer.

FIG. 5 is a flowchart of a method for removing an issuer security domain stored in a smart card according to a preferred embodiment of the present invention.

As shown in FIG. 5, a user selects a target issuer security domain by inputting an identification of the target issuer security domains'card issuer through the host computer 500, in operation 501. This selection will be explained later with reference to FIG. 6.

After receiving a response of selection in operation 502, the user inputs a command for deleting the issuer security domain with an authentication request in operation 503.

The virtual issuer security domain 301 transmits the transmitted authentication information to the key package manager 380 in operation 504 and the key package

manager 380 performs operations for authentication in operation 505. It is preferable to use a key registered with the key package manager 380 when the target issuer security domain is installed as the key for authentication, in operation 505.

The key package manager 380 deletes the corresponding key package, applications and application security domains from the key package database 390, after verifying the authentication, in operation 506. The result of the deletion is transmitted to the host computer 400 through the virtual issuer security domain 301, in operation 507.

In operation 506, it is preferable to persuade a card issuer to first delete an application provider security domain included in the issuer security domain, an application of an application provider, or an application of the card issuer, before deleting the card issuer's security domain. This may prevent the accidental deletion of wanted applications.

That is, it is preferable to provide a confirmation method to the card issuer for confirming remaining of an application provider security domain belonging to the card issuer security domain that is the target of the deletion, an application of the application provider security domain that belongs to the card issuer security domain or an application of the card issuer security domain that is the target of the deletion. The confirmation method may be provided to the card issuer by outputting a message warning that the issuer security domain will not be deleted, or a message noticing remaining of an application provider security domain belonging to the card issuer security domain that is the target of the deletion, an application of an application provider security domain that belongs to the card issuer security domain or an application of the card issuer security domain that is the target of the deletion FIG. 6 is a flowchart of a method for selecting an issuer security domain in a smart card according to a preferred embodiment of the present invention.

The case of requiring the selection of an issuer security domain is a case of total management for transferring ownership, installing or deleting the card issuer applications 330 and 360 and the application provider security domains 310 and 340 in the smart card, or a case of returning to a card issuer security domain of the corresponding card issuer from performing operations related to other security domains.

As shown in FIG. 6, a user transfers the identification information of a card issuer

of a corresponding card issuer security domain through the host computer 400 to the virtual issuer security domain 301, in operation 601. The virtual issuer security domain 310 transfers the identification information to the key package manager 380, in operation 602.

The key package manager 380 extracts a corresponding key package from the key package database 390, and provides this key package to the virtual issuer security domain 301, in operation 603.

Then, the virtual issuer security domain 301 is used as a selected card issuer's issuer security domain, and the result is transferred to the host computer 400, in operation 604.

The method of the present invention can also be embodied as computer-readable code on a computer-readable recording medium. The computer-readable recording medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the computer-readable recording medium include read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and carrier waves (such as data transmission through the internet).

The computer-readable recording medium can also be distributed over network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion.