KR100508351B1 - System and apparatus for smart card personalization - Google Patents

Abstract

The smart card maintains a database containing card issuer data format templates, card application programs, card operating system commands, and personalization device specifications, and a central input / output interface to the card issuing process that dynamically adapts to changes in the card issuing process. The card issuer enables the card issuer to easily change the format, card application program, card operating system and / or personalization device 130 in the card issuing process. The system interfaces to any card issuer management system 150, manages the transfer of cardholder data and card application programs to the specific personalization device in use, and maintains statistics for real-time and offline queries, Support management and reporting functions. In addition, the system operates in a variety of security ways to prevent illegal activities.

Description

Smart card personalization system and device {SYSTEM AND APPARATUS FOR SMART CARD PERSONALIZATION}

FIELD OF THE INVENTION The present invention relates to data storage, and more particularly to the manufacture of programmed portable data carriers such as credit cards, debit cards, identification cards and other transaction cards.

An increasing number of institutions that issue trading cards to users, customers or employees require the cards to be adjusted to meet the requirements of their particular service or application. These agencies also want such a card to contain data about the cardholder. Conventional trading cards encode such data on the magnetic line on the back of the card, but the data that can be held by the magnetic line is limited. Newer types of trading cards have significantly increased the data storage capacity of the cards by inserting microprocessor computer chips into the card's plastic. Incidentally, advanced card applications specific to the card issuer may run on various kinds of chips, which may also include any kind of operating system. Trading cards with embedded chips are called industry-programmed portable data carriers, more commonly "smart cards." The chips in the smart card are programmed with initialization and / or personalization data as soon as the surface of the card is embossed and / or printed.

The initialization data includes three main kinds of information: application data, security data, and print data. Application data is common to all cards for a given card application and includes application program code and variables. Secure data prevents fraudulent use of the card and is typically provided in the form of a "security key." Print data such as logos, bar codes, and various kinds of numerical information are placed on the surface of the card. Some or all of the same data is also embossed on the surface. In addition, optical techniques are used to make some or all of the card surface into a storage medium having data that can be accessed by a suitable optical reader.

Smart cards are also programmed with information specific to individual cardholders through a process called "personalization." Personalization information for a smart card is similar to the personalization information currently included on non-smart cards such as cardholder's name, account number, card expiration date, and photo. Due to the increasing storage capacity, chips in smart cards can provide additional data other than basic information on standard trading cards, including a graphical representation of an individual's signature, data defining the types of services that cardholders should enjoy, and May contain transaction limits.

The smart card issuing process should be able to control and report the results of each personalized card and personalization process. Therefore, extensive report and audit files must be maintained to support card tracking requirements.

Currently, smart card issuing systems meet the prerequisites for a particular card application to be programmed according to a particular type of smart card under the control of a particular card operating system and are compatible with a particular type of personalization device selected for the card to issue the card. It should be adjusted to format. Each time one of these variables (issuer application, smart card / card operating system, and / or personalization device) changes, the entire issuing system must be reconfigured. This increases the time and cost incurred by the card issuer in delivering personalized smart cards to the customer. In addition, most of the current issuing systems lack a valid means for providing card issuers with dynamic feedback regarding the status of any particular group of cards in process.

Moreover, smart card issuing systems in use today use proprietary methods developed by either card manufacturers or personal device manufacturers. To encourage the sale of each of these cards or devices, each manufacturer develops a unique personalization method for a particular card application, each method being specific to a particular card issuer. This unique method is intended to optimize the performance of a card or device and thus does not allow for a more comprehensive and general purpose personalization process that accommodates any card operating system and / or operates with any personalization device. .

As the demand for smart cards increases, the card issuer can use any type of personalization device to process multiple types of smart cards and accompanying operating systems, and also assigns them to any of various types of smart cards. There is a need for a smart card issuing system that enables the embedding of a specific card application of an issuing machine with cardholder data of a card.

Summary of the Invention

The smart card personalization system maintains a database containing card application data, issuer format template data, card operating system data, and personalization device data so that the card issuer does not have to modify the card issuer's interface to the issuance process. To dynamically change card applications, card and card operating systems, and / or personalization devices.

The smart card personalization system obtains a programmed portable data carrier, i.e., by first obtaining a data format identifier, a card operating system identifier, a personalization device identifier, an application program identifier or identifiers, and personalization data for the cardholder from the card issuer management system. Issue a smart card. The identifiers allow the system to address data stored in a data structure, such as a database, and to specify specific data needed by the system for each card to be issued. Since each card issuer formats its personalization data differently and can have multiple data formats, the smart card personalization system has a database of data format templates that enable interfacing with a plurality of card issuer management systems. The system obtains a format template that defines the personalization data used by a particular card issuer from a record in the database identified by the data format identifier. The system uses a data format template to convert personalized data from the card issuer's format to an internal format recognized by the system's components. The system uses the card operating system identifier and the application program identifier (s) to preload the microprocessor chip engraved on the card, in the form of code and / or variables, for the application program type or types from the database. Acquire program control instructions and application data for the operating system. The system also uses the personalization device identifier to obtain device characteristic data for the personalization device that can be used to issue smart cards. Once the system has obtained all the information needed to issue the smart card, it sends the program control instructions, application code and variables, and the converted personalization data specified by the device characteristic data to the personalization device.

Optionally, no format identifier is passed by the card issuer because the data format template is derived from the data in the application data record or because the personalized format corresponds one-to-one with the internal format used by the system. The card issuer can also replace the data format template record instead of the data format identifier, so that the system does not need to refer to the database of format records.

Another feature of the smart card personalization system is its card management function. The smart card personalization system collects information related to the card issuing process and reports this information to the card issuer management system.

The smart card may include one or more "security keys" programmed into the chip to prevent fraudulent use of the card. Appropriate security key data is obtained by the smart card personalization system from a security key record or other security source maintained by the card issuer and then transferred to the personalization device. The security source also provides security functions used by the smart card personalization system to ensure the reliability and security of the data in the system during the transmission of data to and from the system and during the smart card personalization process.

The smart card management system performs the functions described above through a series of software modules running on a computer or multiple computers. One module is a card issuer management system interface for obtaining a data format identifier, a card operating system identifier, a personalization device identifier, an application program identifier (s), and personalization data for the card holder from the card issuer management system. At this time, the card issuer management system interface defines the personalization data using the data format identifier and obtains a format template for converting the personalization data into a common internal data format. The card operating system interface module obtains a program control command for the card operating system type specified by the card operating system identifier. The card application interface module uses the application program identifier (s) to determine what kind of application program (s) will be embedded in the card and obtain the specified application code and variables. The personalization device interface module is responsible for obtaining device characteristic data for the personalized device type specified by the personalization device identifier, and also in accordance with the preconditions defined by the device characteristic data, programming control commands, application code and variables, and converted personalization. Responsible for transferring data to personalized devices.

Reports and security functions are provided by the tracking / reporting module and the security key management module.

Smart card personalization systems use underlying data structures, such as databases residing on computer storage media, to organize the data needed to issue smart cards. A data structure contains several different kinds of data elements and uses "indexes" or "identifiers" to quickly access specific data. There are four main data elements in the system: data format elements, card operating system elements, application program elements, and personalization device elements.

The data format element includes a template that defines the format of personalization data used for the card issuer. The data format element can be stored in a database that includes data format elements for various card issuers and the information stored in the data format element is accessed via a data format identifier. Optionally, the data format element may be extracted at the time the card is issued from the data of the application program element (s) such that the application program identifier passed by the card issuer identifies the data format. When the data format of the personalized data exactly matches the internal format used by the smart card personalization system, a data format template is logically represented that creates a virtual data format element for the issuance process.

The card operating system element holds programming control instructions that direct the card operating system to control the smart card chip and is accessed via the card operating system identifier.

The application program element (s) includes application data, such as program code and variables, required for an application associated with various card issuers; Application data is accessed via an application program identifier.

Operational parameters for the various types of personalization devices used to issue smart cards are stored in personalization device elements and accessed via personalization device identifiers that match the type of personalization device to be used during the issuance process.

Certain configurations of smart card personalization systems support card issuers that do not require the full flexibility of the systems described above.

The smart card personalization system addresses the shortcomings of the prior art by providing a centralized input and output interface to the smart card personalization process designed to dynamically accommodate changes in the issuance process. The system connects to any machine management system, manages card applications for the transfer of cardholder data and the specific personalized devices used, and collects statistics during real-time and offline inquiries to support important management and reporting functions. The system maintains a database of issuer data formats, card operating systems, card application programs, and personalized device types. Such a database allows the system to handle any combination or permutation of data, improving the cost and time issues for issuing the issuer. The system also interfaces with various card security methods to reduce fraud.

1A is a block diagram illustrating a smart card issuing process for integrating a smart card personalization system.

1B is a schematic diagram of the functional blocks of input and output connections to the smart card personalization system shown in FIG. 1A.

1C is a schematic diagram of a functional block showing a software module and data structure including one embodiment of the smart card personalization system shown in FIG. 1B.

FIG. 2 is a schematic diagram of the embodiment functional block of FIG. 1C with a security module added to manage keys used for smart cards. FIG.

3 is a schematic diagram of a functional block of another embodiment of a smart card personalization system showing a minimal configuration for managing multiple types of cards and personalization devices.

4 is a schematic diagram of the functional blocks of the embodiment of FIG. 3 with the addition of a module for managing multiple card operating systems.

5 is a schematic diagram of the functional blocks of the embodiment of FIG. 4 with a security module added;

6 is a schematic diagram of the functional blocks of the embodiment of FIG. 3 with the addition of a module for managing multiple card applications.

7 is a schematic diagram of the functional blocks of the embodiment of FIG. 6 with a security module added.

8 is a high level flow chart for computer software implementing the functionality of a smart card personalization system.

9 is a schematic diagram of a functional block of another embodiment of a smart card personalization system using software modules and data records.

10 is a high level flow chart of computer software implementing the functionality of the embodiment of the smart card personalization system shown in FIG.

FIG. 11 is a data field chart for a card framework template record used by the embodiment of the smart card personalization system shown in FIG. 9.

12 is a data field chart for a data format template record used by the embodiment of the smart card personalization system shown in FIG.

13 is a data field chart for the card application data record used by the embodiment of the smart card personalization system shown in FIG.

14 is a record format showing sample items tracked by a smart card personalization system.

DETAILED DESCRIPTION In the following detailed description of the embodiments, reference is made to the accompanying drawings that illustrate specific embodiments, which are part of this specification and in which the invention may be practiced. These embodiments are described in detail to enable those skilled in the art to practice the invention, other embodiments may be utilized, and logical and electrical modifications may be made without departing from the spirit and scope of the invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is limited only by the appended claims.

The leading digit (s) of the reference numbers in the drawings generally correspond to the reference numbers, with the exception of identifying the same components that appear in multiple figures with the same reference numbers.

<Smart Card Issuance>

Standard trading cards such as ordinary credit cards are familiar to most people. On the surface of the transaction card is usually printed or embossed information about the cardholder, such as the name and account number. Trading cards often also include a magnetic stripe encoded with the cardholder data. The process of printing / embossing / encoding cardholder data on each transaction card is known as "personalization". Also for each transaction card, a process known as "initialization" is performed in which a certain type of information common to all the cards in the group, such as an issuer identifier and a batch number, is placed on the card.

Smart cards differ from standard trading cards in that a computer microprocessor chip is built into the plastic of the card to significantly increase the data storage capacity of the card. In some variations of the smart card, the card manufacturer pre-loads one of several possible card operating systems onto the chip, which controls the programming of the chip during the personalization process. In addition, in certain variations of the chip, very complex card applications specific to the card issuer may be executed.

Initialization data of a smart card includes three main types of information: application data, security data, and printed data. Application data is common to all cards for a given card application and includes application program code and variables programmed into the chip. Security data, usually provided as a security key or security function, identifies the data on the card and prevents fraud on the card. Print data such as logos, bar codes and various kinds of numerical information are printed on the surface of the card. Some or all of the same data may be embossed on the surface. Optical techniques may be used to make a portion of the surface of the smart card into a storage medium having data accessible by a suitable optical reader.

The personalization information of a smart card is similar to the personalization information commonly included in non-smart cards, such as the cardholder's name, account number, card expiration date, and photograph. Due to the increase in storage capacity, chips in smart cards can provide additional data other than basic information on standard trading cards, including a graphical representation of personal signatures, data defining the types of services the cardholder should enjoy, and the trading of such services. It may also include additional data, including limits.

<Smart Card Personalization System>

1A illustrates the components of smart card issuing processing incorporating one embodiment of the smart card personalization system of the present invention. The smart card personalization system 100 receives data from the card issuer management system 150 (typically owned by the card issuer), converts the data into a data stream, and personalizes the data stream into a smart card 160. Output to the personalization device 130. The card issuer management system 150 determines the type of card to manage and issue cardholder data, the card application to be embedded in the card, and the personalization device to be used to issue the card of the specific cardholder. The card issuer management system is often a computer program such as that shown in FIG. 1A, but the smart card personalization system 100 can receive data from other inputs, such as an individual entering data from a telephone keypad.

The smart card personalization system 100 is shown in FIG. 1A as a software program running on a computer. As will be described below, the smart card personalization system 100 accesses database records that define various types of cards and card operating systems, card applications, and personalization devices.

The logical functions of the software and database can be distributed to computers within a client / server network or concentrated on a single processor. These functions may also be distributed to the combined processors through standard local area networks (LANs), wide area networks (WANs), dedicated telephone lines, or other communication means used to combine the processors. Software programs are Unix, Windows 95 ^?? , Or Windows NT ^?? And is run under the control of an operating system such as, and run on industry standard workstation and / or personal computer hardware.

System 100 controls card printer, embossing device, and integrated or add-on smart card interface devices collectively shown in FIG. 1A as personalization system 130. . In addition, personalization device 130 may include a large number of card printers / embossers, a small number of card printers / embossers, automatic teller machiners (ATMs), sale terminal points, unmanned newspaper kiosks, personalized computers, network computers, and online communications. Represents a device such as a device. Because of the investment costs of existing non-smart card personalization devices, many card issuers rarely purchase new smart card personalization devices, but instead use smart card interface devices that program chips in the card. While extending existing personalization devices, older devices perform printing and embossing functions. In such a configuration, a computer system or " host " running smart card personalization system 100 can be physically connected to both devices or to one of the devices. In the latter case, the host controls the directly connected device and has a logical connection to the remaining devices. The physical connection between the devices and the host varies depending on the manufacturer and model of the device. Common industry standard connections include serial RS232, Small Computer System Interface (SCSI), Ethernet, and serial TTL. In addition, some devices require proprietary bus connections.

The connection between the smart card personalization system 100, the card management system 150, and the devices 130 may be performed through a standard local area network, a telecommunications network, a dedicated telephone line, or other telecommunication infrastructure used to transmit data. Can be. The use of remote access in personalizing smart cards is described in US Pat. No. 5,524,857, issued July 9, 1996 by Laing et al. Other connections will be apparent to those skilled in the art and are within the scope of the present invention.

1B is a block diagram illustrating one embodiment of a smart card personalization system showing a logical connection between the smart card personalization system 100 and the functions used by the card issuing organization for issuing a smart card. Cardholder data maintained by the card-issuing organization includes information about each individual cardholder, such as name, account number, card expiration date, and available services. Various methods of inputting cardholder data to the card issuer management system 150 are shown in phantom of the cardholder data 152 in FIG. 1B. The card issuer management system 150 may receive cardholder data on computer media, such as magnetic tape, floppy disks, or CD-ROMs. Alternatively, cardholder data 152 may be input via a general switched telephone network, a packet switched network, i.e., an online connection such as the Internet, a dedicated line, or a cable / satellite television signal. Other additional ways in which cardholder data 152 can be entered into system 150 will be apparent to those skilled in the art.

In addition to the card issuer management system 150, the card issuer is typically connected with the smart card personalization system 100 so that the card issuer can reconsider the statistical information maintained by the system 100. Equipped with. In addition, the external security source provided by the card issuer and shown as the security key manager 111 and the security key database 128 operates in combination with the card issuer management system 150 and the smart card personalization system 100. Provide the function. 1B illustrates another embodiment of a smart card personalization system 100 that supports a card issuer having an attached smart card interface device. The system 100 sends some of the personalization information to the old personalization device 130 and the rest of the data to the post processor 132 in the smart card interface device 132 programming the chip. These functions will be described in detail below.

Embodiments of the software program for the smart card personalization system 100 shown in subsequent figures operate in combination with code modules in which each module executes a particular portion of the issuance process. In these embodiments, the modules are coupled through defined input and output program calls and coupled to the data structure through standard data query instructions that provide access to data stored within the data structure. The communication protocol between modules and the communication protocol between modules and data structures vary according to the underlying data management system employed to support the language and database in which the modules are written.

1C is a schematic diagram of detailed functional blocks showing the smart card personalization system 100 of FIG. 1B without an external security function. 1C illustrates an internal connection between a software module and a data record, which allows the smart card personalization system 100 to combine various types of machine data formats, card operating systems, card applications and personalization devices when smart cards are issued. .

The smart card personalization system 100 provides an on-demand card issuer management interface 101 to the card issuer management system 150. In this embodiment, card issuer management system 150 transfers personalization data from cardholder database 152 to system 100. Each software module in the system 100 expects personalized data to be delivered to it in a specific, internal format. Since this personalization data is often represented in an external format defined by the card issuer that is different from the internal format (s) expected by the software module, the personalization data is internal format using the data format template by the system 100. Is converted to. Passed by the card issuer that the system 100 used to obtain an optional data format template record 120 (shown in dashed lines in FIG. 1C) shown by the selective connection between the record 120 and the card issuer management system interface 101. Through the data format identifier, the system 100 may obtain a data format template. As an alternative, the card issuer passes the data format template record to the system 100 instead of the data format identifier. In another embodiment, the card application record 124 specified by the application program identifier passed by the issuer as shown by the selective connection between the card application database 124 and the card issuer management system interface 101. A data format template can be derived from the data in.

In another embodiment of FIG. 1C, by delivering a security function into the system as part of a card application record, the security function is provided internally to the smart card personalization system 100.

Another embodiment in which the personalization data format matches the internal format is also shown in FIG. 1C. Since no conversion between external and internal formats is required in this embodiment, no data format template is needed. Thus, there is no data format record 120 and there is no connection between the card issuer management system interface 101 and the data format record 120 and the card application database 124. The data format record 120 instructs the system 100 for proper parsing of the personalized data or simple list indicating the order in which the fields of the cardholder data record appear to those skilled in the art. It may be composed of a plurality of tables. Various other procedures for determining the format of personalization data as described above are included in all embodiments of the smart card personalization system 100 described herein.

Using the card identifier provided by the card issuer management system 150, the card operating system interface module 103 retrieves programming control instructions specific to the card operating system 122 for the microprocessor chip inherent in the type of card being issued. . The programming control instruction directs the encoding of the chip to the personalization data and card application (s) selected by the card issuer (s).

Each card application includes variable data and program code stored in a database as application data 124 and identified by an application program identifier. The card issuer management system 150 passes the one or more program application identifiers to the system 100 used by the card application interface module 105 to obtain corresponding application data 124.

The personalization device that the card issuer will use to issue the group of cards is defined by the personalization device identifier. The personalized device interface module 107 obtains device characteristic data 126 specific to the type of personalized device 130 corresponding to the personalized device identifier. The personalization device interface 107 also obtains programming control commands, application code and variables, transformed personalization data, and sends all of this data to the personalization device 130 specified by the device characteristic data to issue a smart card. To pass.

Another embodiment of the system 100 is a personalization device interface that delivers a subset of the converted personalization information to the old personalization device 130 and the remainder of the data to the post-processor 132 in the smart card programming device. 107) supports card issuers that have extended their existing personalization devices with smart card programming devices.

In addition, the smart card personalization system 100 collects statistical information from other modules in the system 100 and outputs the statistical information for output as a hard copy report or as input to a reporting function in the card issuer management system 150. Provides a tracking / reporting module or engine 109 for formatting. Since such statistical information is collected in real time, the card issuer management system 150 may query with the tracking / reporting module 109 to obtain statistics regarding the smart card personalization system that is running. An example of items monitored by tracking / report module 109 is shown in FIG. 14.

In another embodiment shown in FIG. 2, the smart card personalization system 100 includes a security source in the form of a security key management module 111 and a security key database 128. When a smart card is manufactured, the vendor includes a security structure on the chip to prevent unauthorized programming. The security architecture implementation typically depends on the application (s) programmed on the chip. For example, security keys programmed in stored value applications are different from security keys programmed in healthcare applications. In addition, the implementation of the security architecture varies by card type, some cards require a single security key that can be chip programmed, while others require multiple security keys that enable chip programming while executing additional security functions. do. 2 illustrates the basic functions of the security key manager 111 when interfacing with the security structure of a card requiring multiple security keys.

As shown in FIG. 2, the security key data is stored in a security key database 128 external to the smart card personalization system 100 and maintained by a card issuer or other security source. Extending the security key manager 111 to handle some security keys and interface with a security key database managed by the smart card personalization system 100 itself is a personalization device used in applications, operating systems and certain issuing applications. It will be apparent to those skilled in the art that it depends on the.

Security key manager 111 also provides additional devices that ensure security key data authentication, data integrity, and data concealment. In one embodiment, security key data authentication is accomplished through various cryptographic implementations. Security key data integrity is achieved through a digital signaling mechanism that uses a public key to verify that security key data is being sent and received from a valid source. Security key data concealment is ensured by encrypting the transmission data using a private key shared with the data receiver and used by the data receiver to decrypt the data upon receipt of the data.

After the system 100 receives the security key record from the security key database 128, in combination with the operating system interface 103 and the card application interface 105, the security key manager 111 performs security key authentication, data integrity. And data hiding functions. The system 100 then passes the security key data to the personalization device 130 along with other data for the card via the personalization device interface 107.

In another embodiment, security key manager 111 delivers security information to other modules of smart card personalization system 100. For example, some of the cardholder data, such as a PIN (personal identification number) code, may be encrypted by the card issuer management system 150 before passing the data to the smart card personalization system 100. The card issuer management system interface 101 retrieves the encryption key from the security key database 128 by the security key manager 111 and converts the data before encoding or programming the PIN code into magnetic lines and / or chips. Detox.

In another embodiment, security key manager 111 is a code “hook” into smart card personal system 100 that provides gateway access to an external security source that provides the necessary security functionality. One example of such an external security source is a security manager program recorded by a third party that manages a security database of security keys and / or security functions similar to the security key database 128. The security functions may be external routines executed by the security manager or code modules delivered by the security manager or a combination of both, which are then executed by the smart card personal system 100 to provide the necessary security functions.

3 illustrates a minimum configuration of the smart card personal system 100. In this embodiment, only the card issuer management system interface module 101 and the personalization device interface module 107 are executed in software. This embodiment allows the card issuer to personalize non-smart cards using the system 100, thereby saving money while having two different personalization systems, while allowing the card issuer to use multiple data formats and multiple formats. Allows the use of a variety of personalized devices. FIG. 3 also describes another embodiment that includes the tracking / reporting module 109 as described above with respect to FIG. 1C.

In another embodiment, the smart card personalization system 100 shown in FIG. 3 encodes data on an optical transaction card when the optical encoding device is used as the personalization device 130.

4 and 5 illustrate another embodiment executed when the card issuer does not program the card application for the smart card chip. These embodiments allow the card issuer to issue multiple types of cards to multiple and diverse operating systems on multiple kinds of personalization devices without having to reconfigure the smart card personalization system 100. As described in connection with FIG. 1C, FIG. 4 includes a module that supports reporting and post processing. 5 illustrates the embodiment of FIG. 4 with a security key manager module 111 providing security to the card operating system interface 103 for transmission to the personalization device 130.

Similarly, Figures 6 and 7 describe an embodiment for supporting a card issuer that uses a chip on a smart card only as a data storage device for a card application, and thus does not have an operating system running on the chip. Smart card personalization system 100 supports multiple card applications for multiple types of cards issued to multiple types of personalization devices. 6 and 7 are similar to FIGS. 4 and 5 except that the security key manager 111 provides security keys and / or functions to the card application interface 105 instead of the card operating system interface 103. Do.

8 is a high level flow chart of the software of the first embodiment for executing the functions of the smart card personalization system 100 described above. The software obtains a personalized device identifier for a group of transaction cards issued from the card issuer management system at block 801. Depending on the type of card issued, the software also simultaneously acquires the program application identifier (s) and / or the card operating system identifier. The software then obtains a specific data format template corresponding to the format of the personalized data through one of the processes described above (block 803). In block 805, the system obtains device characteristics of the personalization device used to issue a group of cards from the personalization device record specified by the personalization device identifier.

If the card operating system identifier has been passed by the card issuer management system (block 807), the software retrieves a programming control command from the card operating system database record corresponding to the card operating system identifier at block 809. Blocks 811 and 813 perform the same process for card applications that retrieve application data such as codes and / or variables from a database. At this point, the software begins to iterate by acquiring the common data needed for all the cards in the group and issuing a card for each cardholder.

The card issuer management system sends the personalization data for the single cardholder to the software (block 817), which transfers the data items from the format defined by the data format template to the internal format used by the modules of the smart card personalization system. Convert (block 817). If the card chip includes a security structure that requires a security key (block 819), the software obtains the security key data needed to perform the security key function from the appropriate security key source at block 821.

The software is now ready to transfer data to the personalization device to program the card. If the card is protected by a security key, a security key function is performed at block 823 and the security key data is transmitted. Then, if applicable, programming control codes for the chip operating system are sent (blocks 825 and 827), and the next application code and / or variable, if necessary (blocks 829 and 831). Finally, the cardholder's personalized data converted to the internal format is transmitted (block 833).

After the data has been transferred to the card, the software adds the appropriate data to the statistics that accumulate for the card issuer management system at block 839. If many of the cards in the same group remain unissued (block 841), the software returns to block 815 to obtain personalization data for the next cardholder. Otherwise, the card issuer management system determines if there is another group of cards to issue (block 843), and returns to block 810 to obtain the information needed to repeat the cycle for the new group. If there are no more cards to be issued, the software is terminated.

The mechanism for delivering the necessary data to the smart card personalization system 100 by the card issuer management system 150 and the order in which the smart card personalization system processes the data from the card issuer management system are not changed within the scope of the invention. It may be. Other configurations are possible depending on the particular environment in which the system 100 operates, as shown in another embodiment described with reference to FIGS. 9 and 10.

In FIG. 9, the security module 911 is a component of the smart card personalization system 100 for a security source, such as a security manager 940 and a security database 942, shown at 111 and 128 in FIG. 1B, respectively. It acts as a gateway. Security manager 940 controls access to security database 942 and connects to security gateway 911 to perform the necessary security functions for smart card personalization system 100. The security gateway 911 is connected to the card issuer management system interface 901 which requests the interface 901 to decrypt the personalized data delivered by the card issuer management system 950 in encrypted format by the card issuer management system 950. Allow to do The security gateway 911 is also connected to the card application interface 903 and the card operating interface 905, which in turn can provide the security key and / or security functionality required for the interfaces described above in conjunction with FIG. 2.

In addition, the embodiment of the smart card personalization system 100 shown in FIG. 9 uses the card identifier to obtain application data 922 defined by the application program identifier before acquiring programming control instructions specific to the card operating system 924. ). This embodiment improves the processing speed of each smart card by enabling personalization data and application data to be converted into an internal format before retrieving programming instructions for card operating system 924 and device characteristic data 926. .

A standard trading card has data that is printed and embossed on the surface of the card and data encoded on the magnetic lines on the card. For smart cards, data may be stored in internal storage in the microprocessor. The same data is also placed in the magnetic line and chip memory on the surface of the card. The exact composition of the data inside and on the card will depend on the type of smart card to be issued and the requirements of the card issuer.

FIG. 10 is a high level flow chart of the embodiment shown in FIG. 9 and, in combination with FIGS. 11, 12 and 13, further illustrates how different mechanisms may be used to implement the smart card personalization system 100. The card issuer management system 950 delivers to the smart card personalization system 100 a card framework template that defines the configuration of the smart card at block 1001.

11 illustrates one embodiment of a data layout for a card framework template record 1100. The microprocessor chip identifier 1101 and the card operating system identifier 1102 (if present) are specific to the type of smart card to be issued. The master file definition 1103 includes control information such as the latest date of the chip change and the chip source. System file definitions 1104, 1105, and 1107 contain addresses for the location of system files in the memory of the chip. This system file is used by the card operating system and contains information such as PIN code (s) and algorithm tables for the card and application. In the embodiment shown in FIG. 11, the master file and system file definitions conform to International Standards Organization (ISO) indication number 7816-4.

The next three sections of the card framework template record 1100 define the organization of data on the surface of the card and on the magnetic lines. When information such as a card holder's photo 1109 is printed on the card, the position on the surface of the card for printing such data is transmitted to the card issuer management system 950 as a print template of the card framework template record 1100. Is delivered by Similarly, the location on the card surface for embossing the data is passed to the embossed template, and the configuration of the data to be encoded on the magnetic lines is transferred to the magnetic line template. The embossed data is the cardholder's name (EMName; 1111), account number (EMAcct; 1113), and magnetic line data by expiration date (EMXdat; 1115) and account number (MSAcct; 1117) and expiration date (MSXdat; 1119). Shown as card framework template record 1100. The number of data items in the print, emboss, and magnetic line templates varies with the configuration of the desired smart card by the card issuer, as will be apparent to those skilled in the art.

If the card issuer wants a card application programmed with a chip in the smart card, the card issuer passes the application program identifier to the smart card personalization system 100 in sections 1121, 1123, 1125 of the card framework template record 1100. . Each application may have a specific security function associated with sections 1127, 1129, 1131, and the information is also conveyed by the card issuer management system 950. The card framework template record 1100 also includes a personalization device identifier 1123 for the personalization device to be used to issue the smart card.

In another embodiment, the smart card personalization system 100 stores card framework template records that are commonly used in an internal database such that the card issuer management system 950 uses which card framework template records are for a particular group of cards. Only pass a card framework template identifier that identifies whether

The smart card personalization system 1100 obtains a data format template for personalization data from the predetermined location specified by the card issuer at block 1003. Once the card issuer has passed the data format identifier to the system 100, a data format template record corresponding to the data format identifier is retrieved from the data format database 920. Alternatively, the card issuer can convey the data format template record itself. If neither the data format identifier nor the data format template record is passed to the system 100, the format of the personalization data is determined by the card application data as described below.

One example of a data format template record is shown in FIG. The data format template record 1200 includes a cardholder database 952 in which the account number 1201 is the first field, the cardholder's name 1202 is the second field, and the expiration date 1205 of the card is the third field. Define a hypothetical layout of personalization data records. In one embodiment, the personalized data record is a comma-delimited record, so the data field length that defines the record format is not needed. Thus, the data format template 1200 shown in FIG. 12 defines the structure of the comma-delimited personalization data record in the smart card personalization system 100 in the following example: 133444999922, Mary Jane Smith, 0299.

The smart card personalization system 100 obtains application data for the card application (s) 922 (if present) corresponding to the card application program identifier passed by the card issuer management system 950 at block 1007. do. If no application program identifier is passed, the smart card personalization system 100 obtains default application data (block 1008). Application data and / or defaults in the card application data record corresponding to the card application program identifier are inserted into corresponding sections (ie, 1121, 1123, 1125) of the card framework template record 1100.

One embodiment of the layout of the card application data record is shown in FIG. The first field in card application data record 1300 is application name 1301. As with other computer-based application programs, card applications process data from an external source, such as an automated teller machine, or from an internal source, such as a data file that is encoded into the memory of a microprocessor. With the use of smart cards, appropriate applications can be executed by the microprocessor, which in turn accesses internal files to retrieve or store data. To access the internal data, the card application data record has a pointer to an application file in chip memory 1302, 1305, 1037 and the location of fields within the application file. Some fields are initialized with data from the cardholder database 952 when the card is issued. The application data 1300 includes an address 1303 to a cardholder file located in the chip memory, and includes three fields: the cardholder's name (ICName) 1309, account number (ICAcct) 1311, and expiration date (ICXdat; 1313). Define a cardholder file by including it. Additional internal data is stored in another application file, and the layout of the additional file is also defined by the application data 1300.

If the chip embedded in the smart card has an operating system specified by a card framework template record, the smart card personalization system 100 controls programming for the operating system from the card operating system database 924 at block 1011. Acquire a set of instructions. Programming control commands for each operating system are used to create and access files in chip memory, along with security commands that control transactions that authenticate PIN (Personal Identification Number) codes and change the amount of money stored on the chip. Contains instructions for functions such as reading and writing records to files in chip memory.

The smart card personalization system 100 obtains from the personalization device database 926 device characteristic data corresponding to the personalization device identifier in the card framework template record at block 1013. The device characteristic data includes a set of personalization programming control instructions that control the operation of the personalization device. As in the case of a card operating system, personalization control instructions are proprietary to the device vendor, but generally include instructions for managing, formatting, and producing smart cards.

When the smart card personalization system 100 obtains all the data needed to define the smart card, it is possible to obtain a personalization data record 952 from the card issuer management system 950. Once every personalization data record 952 is delivered at block 1015, the smart card personalization system 100 returns the personalization data to the internal format (if present) using the data format template at block 1017, and the card. Application data and card framework templates are used to map personalization data to variables in command scripts written in the internal scripting language. The conversion and mapping process is described in more detail below. The scope of the present invention also includes other embodiments using standard programming languages such as Basic, Java, or C instead of internal scripting languages.

The smart card personalization system 1019 checks security requirements for various components of the smart card issuance process. In the embodiment of the card framework template shown in FIG. 11, the security requirements for the application are specified by the card framework template record 1100 at block 1019. If a security requirement exists, at block 1021, the smart card personalization system 100 obtains secure data and / or functionality from the security manager 940 and adds the functionality to an internal script. Another embodiment of the smart card personalization system 100 is the application manager identifier, as well as the identifiers of the personalization device and card operating system, to the security manager 940 retrieving the appropriate security data and / or functionality from the security database 942. To pass. In general, security functions include data and security from additional sources, including internal chip file data, personalization data 952, operating system database 924, card application database 922, etc., associated with algorithm tables stored within the chip. Data from an external security module such as administrator 940 is used to perform security key authentication, data integrity, data concealment, and other security procedures mentioned above with respect to FIG.

Once the internal command script is complete, it is converted (if present) into proprietary programming control commands specific to the card operating system and personalization device, so that personalization data is transferred to the smart card. In this embodiment, the translation is performed by the script language translator at blocks 1025 and 1027 using information obtained from the card operating system database 924 and the personalization device database 926.

In block 1029, the smart card operating system 100 delivers the converted script to the personalization device, programming to emboss / print, encode, and program the appropriate personalization data on the surface of the smart card and into magnetic lines and chips, respectively. Perform control commands. If the card issuer purchases an additional smart programming device and adds it to an existing personalization device, another embodiment of the smart card personalization system 100 provides control commands for embossing and encoding to the personalization device 930 and posts in the smart card programming device. Send control commands for the chip to the processor 132.

If the issuance process has ended for one card, smart card personalization system 100 obtains the next personalization data record if there are additional cards of the same type waiting to be issued (block 1033). If not, the smart card personalization system determines if there is another group of smart cards waiting to be issued (block 1001) and resumes the issuing process by obtaining a new card framework template from the card issuer.

The following example uses sample data to better illustrate the processing performed by the embodiment of the smart card personalization system 100 shown in FIGS. 9 and 10. The card issuer management system 950 is a smart card personalization system 100 that provides card framework template records, application program identifier (s), card operating system identifiers, personalization device identifiers, and optionally data format template identifiers or data format templates. Request to start the issuing process by sending a record. In this example, card issuer management system 950 sends an application resource template record, shown below, with an identifier. System 100 obtains a data format template using one of the processes described above and is described in more detail below in conjunction with a sample cardholder data record.

The first statement in the record specifies the start of information for a particular application, which in this example is application "A1". The next four statements define the identifiers for the card framework template record (DFT), the card application record (CAT), the card operating system record (CID), and the personalization device record (CPT). The final statement is the name of the file generated by the card issuance management system 950 containing the cardholder data record (s). Card issue management system 950 enters cardholder data as a single request or group of requests for a card to be issued.

System 100 retrieves the record corresponding to the identifier from the database. The system 100 then sets up an internal "script" using the information contained within the card framework template and the data format template, which in turn causes the personalization device to process the personalization data and each card. It is translated into a specific command contained in the card operating system and personalized device record that instructs the card holder to issue a card.

The two sample card holder data records 952 are as follows.

In these records, the format defined by the card issuer is placed in the account name (cardholder name) in the first field, after which the account number, expiration data, birthday, and medical data are placed.

System 100 converts each cardholder data record 952 using a data format template during processing. System 100 also uses data format templates and card application records 922 to identify data 952 to ensure proper data and format. An example of a data format template corresponding to the format of the sample card holder record described above is shown in the first line of the table below. James Smith personalized data records are included in a table showing the correspondence between the fields of the data format template and the cardholder data records. The data format template makes each field in the cardholder record equivalent to an internal label,% 1,% 2, etc., corresponding to the internal order used in the system 100.

The above example shows the simplest case where the fields of the cardholder data record 952 are arranged in the internal order used by the smart card personalization system 100. This one-to-one correspondence means that the system 100 does not need to convert the cardholder data fields in the order of their internal fields. In this case, data format template records are unnecessary. Thus, in another embodiment, the card issuer does not pass the data format identifier to the smart card personalization system 100, but instead does not require a data format template because the cardholder data fields correspond one-to-one with the internal field order. It passes an indicator, such as a flag, to inform the system 100. The system 100 bypasses the conversion step according to the indicator.

A more complicated example described below is that the fields of the cardholder data record 952 and the data in those fields are not arranged in the internal system order. In this case, conversion is necessary.

System 100 uses the data format template to convert the data fields in internal order as described above. This conversion physically rearranges the data fields, or logically rearranges the data format template to be used as a key whenever a field from the cardholder data record is referenced by the system 100. Various data format templates designed to convert different arrangements of cardholder data will be apparent to those skilled in the art, and the simple tables illustrated in the examples above may be replaced by field equivalents or parsing instruction sets or other mechanisms. .

The card framework template record describes the structure of the chip on the card. In the sample shown below, the $ MF entry defines the root directory 3F00, while the $ DF entry defines the medical application 5F20 and the account application 5F10. Within each directory is an application specific file defined by the $ EF entry, such as 6F00 containing the account name and 6F10 containing the account number. All file description data is in the card framework template and is referenced at various points in the smart card issuance process.

Card application record 922 "maps" cardholder data 952 to data fields used by that application. The sample card application record 922 shown below has data entries arranged in the order that they are processed by the smart card personalization system 100.

The ICCID entry contains a chip identifier. Each entry except FMTACCT specifies a data type of the field by mapping a "tag" to a field in the cardholder data record 952 containing information (information as defined in the data format template above). do. Thereby, the MED1 tag represents the fifth field of the cardholder data record 952 and the data is in alpha format. The FMTACCT entry cuts the second field of the cardholder data record 952, the account number, into sections and inserts a hyphen between the sections.

Card operating system record 924 includes programming control instructions for programming the chip on the card. The sample card operating system programming control commands shown below are taken from ISO indication number 7816-4 and are not internal proprietary commands of any particular card operating system.

Each entry of the example record described above includes a tag followed by a corresponding instruction in the native language of the card operating system. Variable parameter fields are marked with a letter after the "%" and filled with the appropriate cardholder data as individual cards are processed.

Personalization device record 926 includes personalization device characteristic data, such as instructions that define the actual sequence and steps required to issue a complete card to a particular set of personalization devices. The sample commands used in this example are hypothetical and do not represent internally owned commands for any particular personalized device.

When each card is issued, such personalized device characteristic data is processed in succession in four steps defined by the entry preceded by "$". The card application record 922 is used to determine the value of the parameter field of each command.

The $ EMBOSS command is a single stream of data starting with control sequence # EMB # informing the personalization device that subsequent data should be embossed on the card. Each data field in the instruction is enclosed within a pair of percent signs. In this case, the first data field is a formatted account field as defined in FMTACCT, or card application record 922. The system 100 retrieves the card application record 922 for the FMTACCT entry and generates the string "1265-36830-91245" from the second data field in the first sample card holder record 952. The next field, NAME, is obtained from the first data field of the cardholder record 952. Therefore, the emboss command for the first sample card holder record 952 would be # EMB% 1265-36830-91245 %% Smith, James%.

The $ ENCODE instruction causes the system 100 to process the cardholder data to be encoded on the card's magnetic line in the same form as the emboss instruction. Additional control characters in accordance with the International Air Travel Association (IATA) and ISO standards are inserted in the command. The resulting command is #ENC # %%% 12653683091245 %% Smith, James%.

The $ IC instruction specifies the information stored in the memory of the chip. Card operating system record 924 is used to translate the commands in the personalization device record into programming control instructions for the operating system. The control sequence, ## @ #, is used to inform the personalization device that the subsequent data is chip data. The first field to be stored is a chip identifier (ICCID). System 100 translates the WIRTE tag in personalization device record 926 according to the command identified by the WIRTE tag in card operating system record 924. Since there is no offset value specified in the application record 922 for the chip identifier entry, the default "0000" is loaded into the% O variable parameter field. The% L variable parameter field is set to the value of the SIZE field of the $ CHIP entry of the card framework template, ie "10" or hexadecimal "0A". The% D variable parameter field is set to an ICCID value, that is, "1234509876". The resulting command is A0D000000A1234509876.

The following command causes the card operating system to store the cardholder name in an account name file in the account directory on the chip. System 100 converts the SELECT ACCT command into a corresponding card operating system command. The system 100 locates the SELECT entry in the card operating system record 924, the ACCT entry in the card framework template record, and locates the account directory defined within the ACCT entry, that is, the% F variable parameter of the command defined in the SELELT entry. Replace "5F10" for the field with the specific directory path. The resulting command is A0A40000025F10. Similarly, the SELECT NAME command causes the system 100 to replace the% F variable parameter field with an account name file "6F00". The resulting command is A0A40000026F00. The final command in the series of commands is the WRITE command. The system 100 is configured to include the NAME entry in the card framework template record for% L, and% 0 as defined by the cardholder name " Smith, James " of the first sample cardholder data record 952 for% D. , Convert the WRITE instruction by replacing the value of the SIZE field, "30" or hexadecimal "1E" with the default offset of "0000", and the instructions A0D000001ESmith, James ~~ ("~" each represent a subsequent space inserted to append a name from 30 characters each).

The system 100 processes the remainder of the instructions in the personalization device record 926 in a similar fashion to produce a continuous string of data that includes instructions for issuing a card for the first sample cardholder data record 952.

The $ PR command causes the system 100 to send a command data stream to the personalization device.

The data layouts shown in FIGS. 11, 12, and 13, and the sample data described in connection with the above example, are used to describe various embodiment functions of the smart card personalization system 100. As shown in FIG. It is apparent to those of ordinary skill in the art that layouts and data are necessarily defined by the environment in which they are used.

In addition, as will be apparent to those skilled in the art, the smart card personalization system 100 includes other embodiments of a software program in which the functions of the system are performed by modules other than those shown in the figures. . System 100 may process data in serial or parallel form, or in a combination of the two, without departing from the spirit or scope of the present invention. A software program can be written in one of several widely available programming languages, and a module can be coded into subroutines, subsystems, or objects depending on the language selected. Similarly, data used by system 100 appears as a logical record implemented within a database, but the present invention is not limited to the above arrangement of data records or also to the use of certain types of data management systems. Relational database systems produced by vendors such as Oracle, Sybase, Informix, or Microsoft provide the infrastructure necessary to manage the system's underlying data, whether centralized or distributed, which provides other organizational data structures, such as indexed. Flat files may be replaced without departing from the technical scope of the present invention.

Further, other embodiments of the invention in which the system is implemented in hardware, firmware, or a combination of hardware and software, and distribute modules and / or data in different ways are apparent to those of ordinary skill in the art. It will also be apparent within the technical scope of the present invention.

It will be understood that the above description has been described in an illustrative manner and is not intended to be limiting. It will be apparent to those skilled in the art that many other embodiments may be implemented by considering the above description. Accordingly, the scope of the invention is to be determined with reference to the claims, including the full range of counterparts to which the appended claims may apply.

Claims (31)

A method for issuing a programmed portable data carrier, Obtaining a personalization device identifier and personalization data for the cardholder from the card issuer management system; Obtaining device characteristic data for the personalized device type from a record in the database identified by the personalized device identifier; And Issuing the data carrier by transmitting the personalized data to a personalized device designated by device characteristic data for the personalized device type. How to include. The method of claim 1, Converting the personalized data into an internal format so that the converted personalized data is transmitted to the personalized device How to include more. The method of claim 2, The personalization data is converted from the format defined by the card issuer management system to the internal format according to format template data. The method of claim 3, Obtaining the format template data from a record in a database identified by a data format identifier provided by the card issuer management system. How to include more. The method of claim 3, Acquiring the format template data from the card issuer management system How to include more. The method of claim 3, Obtaining the format template data from an application data record in a database identified by an application program identifier provided by the card issuer management system. How to include more. The method of claim 1, Collecting information regarding the issuance of the data carrier; And Reporting statistics derived from the collected information to the card issuer management system; How to include more. The method of claim 1, Obtaining an application program identifier from the card issuer management system; Obtaining application data from a record in a database identified by the application program identifier; And Transmitting the application data to the personalized device specified by the device characteristic data. How to include more. The method of claim 1, Obtaining secure data from a secure source; And Transmitting the security data to the personalized device designated by the device characteristic data. How to include more. The method of claim 1, Obtaining a card operating system identifier from the card issuer management system; Obtaining a programming control command from a record in a database identified by the operating system identifier; And Sending the programming control command to the personalization device specified by the device characteristic data. How to include more. The method of claim 10, Obtaining an application program identifier from the card issuer management system; Obtaining the application data from a record in a database identified by the application program identifier; And Transmitting the application data to the personalized device specified by the device characteristic data. How to include more. A system for issuing a programmed portable data carrier, A card issuer management system interface for obtaining a personalized device identifier and personalized data for the cardholder from the card issuer management system; And Personalization device interface for obtaining device characteristic data for the personalization device type from a record in the database identified by the personalization device identifier. Including; The personalization device interface also sends the personalization data to the personalization device specified by the device characteristic data for the personalization device type to issue the data carrier. The method of claim 12, The system also obtains format template data from a record in a database identified by a data format identifier provided by the card issuer management system, and converts the personalization data from a format defined by the format template data to an internal format. Wherein the personalization device interface sends the converted personalization data to the personalization device. The method of claim 12, A tracking / reporting engine for collecting data on issuance of the data carrier from the system and reporting the collected data to the card issuer management system. The system further comprising. The method of claim 12, Card application interface for obtaining application data from a record in a database identified by an application program identifier obtained by the card issuer management system interface More, The personalization device interface also sends the application data to the personalization device specified by the device characteristic data. The method of claim 12, Security manager for obtaining security data from a security source and sending the security data to the personalized device interface The system further includes. The method of claim 12, A card operating system interface for obtaining a programming control command from a record in a database identified by a card operating system identifier obtained by the card issuer management system interface More, The personalization device interface is further to send the programming control command to the personalization device specified by the device characteristic data. The method of claim 17, Card application interface for obtaining application data from a record in a database identified by an application program identifier obtained by the card issuer management system interface More, The personalization device interface also sends the application data to the personalization device specified by the device characteristic data. A storage device for storing a data structure for manufacturing a programmed portable data carrier comprising a plurality of personalization device elements, Each personalized device element is addressed by a unique personalized device identifier, and specifies operating parameters for the personalized device type, such that the personalized data is suitable for transmission to a personalized device of the type used to issue the data carrier. Memory to be formatted. The method of claim 19, The data structure further includes a plurality of data format elements, Wherein each data format element is addressed by a unique data format identifier and formats the personalized data by specifying a template used by the card issuer. The method of claim 19, The data structure further includes a plurality of card operating system elements, Wherein each card operating system element is addressed by a unique card operating system identifier and specifies a programming control command for transmission to the personalization device. The method of claim 19, The data structure further includes a plurality of application program elements, Wherein each application program element is addressed by a unique application program identifier and specifies application data used by a particular type of application program for transmission to the personalization device. The method of claim 22, The data structure further includes a plurality of card operating system elements, Wherein each card operating system element is addressed by a unique card operating system identifier and specifies a programming control command for transmission to the personalization device. A system for issuing a programmed portable data carrier, A personalization device that receives the data stream and personalizes the programmed portable data carrier in response thereto; Personalized data obtained from the card issuer management system; And Smart card personalization system-The smart card personalization system has a database comprising one or more data elements selected from the group consisting of data format template elements, card application data elements, card operating system elements and personalization device elements. Process the personalized data indicated by at least one of the data elements and output the data stream. System comprising. A method for issuing a programmed portable data carrier, Obtaining personalization data and device characteristic data for the cardholder; And Issuing the data carrier by transmitting the personalized data to a personalized device designated by the device characteristic data. How to include. A system for issuing a programmed portable data carrier, A system interface for acquiring personalization data and device characteristic data for a cardholder, and for transmitting the personalization data to a personalization device designated by the device characteristic data to issue the data carrier. System comprising. A system for issuing a programmed portable data carrier, Interface means for obtaining personalization data for the cardholder and personality data for the personalization means, and for transmitting the personalization data to the personalization means designated by the personality data to issue the data carrier. System comprising. A system for issuing a programmed portable data carrier, System interface means for obtaining personalization means identifiers and personalization data for the cardholder from the card issuer management system; And Personalization interface means for obtaining characteristic data for the type of personalization means from a record in the database identified by said personalization means identifier. Including; The personalization interface means is further configured to issue the data carrier by sending the personalization data to personalization means designated by the characteristic data for the type of personalization means. The method of claim 28, Application interface means for obtaining application data from a record in a database identified by an application identifier obtained by said system interface means More, The personalization interface means further sends the application data to the personalization means designated by the characteristic data. The method of claim 28, Operating system interface means for obtaining programming control instructions from a record in a database identified by a card operating system identifier obtained by said system interface means More, The personalization interface means further sends the programming control command to the personalization means designated by the characteristic data. The method of claim 28, The system also obtains format template data from a record in a database identified by a data format identifier provided by the card issuer management system, and converts the personalization data from a format defined by the format template data to an internal format. Such that the personalization interface sends the converted personalization data to the personalization means.