RU2260849C2 - System and device for personalization of intellectual cards - Google Patents

Abstract

FIELD: data carriers.

SUBSTANCE: system has personalization equipment, issuer administration system, system for personalization of intellectual cards. Other variant of system has interface of issuer administration system for receiving identifier of personalization equipment and personalization data for card owner from issuer administration system, personalization equipment interface for receiving data of equipment characteristics for type of personalization equipment from database record, identified by identifier pf personalization equipment. Method describes operation of said systems.

EFFECT: issuers can use any type of personalization equipment to manipulate large quantities of intellectual cards types and appropriate operating systems.

4 cl, 16 dwg

Description

FIELD OF THE INVENTION

The present invention relates to data storage devices, in particular the creation of portable programmable data carriers such as credit cards, debit cards, identification cards and other transaction cards.

State of the art

Increasing numbers of organizations that issue transaction cards for their users, customers, or staff require cards specifically designed to meet the requirements of their specific services or applications. These organizations also want the cards to contain information about the card holder. Known operation cards encode such data in a magnetic strip on the back of the card, but the amount of data that the magnetic strip may contain is limited. The new type of transaction card, known from US Pat. In addition, sophisticated use of cards specialized for the issuer can be performed in certain varieties of chips, and the chip may also contain a type of operating system. Cards of operations with integrated circuits in the industry are called portable media with programmed data, most often called "smart cards". The chip in the smart card is programmed with initialization and / or personalization data, while extrusion and / or printing is performed on the surface of the card.

Initialization data contains three main types of information: application data, security data, and printed data. Application information is common to all cards of this application and includes code and application program variables. These protections prevent fraudulent use of the card and are usually created in the form of "security keys". Printed data, such as a brand name, barcode, and various types of numerical information, is placed on the surface of the card. Some or all of such data may also be extruded onto the surface. Optical technology can also be used to make part or all of the surface of the card in the form of a storage medium on which data can be accessed by means of an appropriate optical reader.

The smart card is also programmed with information specific to the individual card holder using a process called “personalization”. The personalization information for a smart card is similar to the personalization information currently on non-smart cards, such as the name of the card holder, account number, expiration date of the card and photograph. Due to the increased storage capacity, the microcircuit in the smart card may contain additional data, in addition to the basic information on the standard transaction card, including a graphical representation of the person’s signature, data defining the types of services allowed to the card holder and the limits for recording these services.

The process of issuing a smart card should manage and report on each personalized card, as well as on the results of the personalization process. Therefore, it is necessary to save extensive message and verification files to maintain card tracking requirements.

At present, the system of issuing smart cards should be specialized in order to meet the requirements for the specific application of cards that will be programmed on a specific type of smart card under the control of the operating system of a particular card, and to format the data for the card in order to be able to combine with a specific type of personalization equipment selected to issue cards. The entire issue system should be reconfigured whenever any one of these variables changes (element application, smart card / card operating system and / or personalization equipment), increasing the time and cost imposed by the card issuer when providing personalized smart cards to their to consumers. In addition, many of the modern issuing systems do not have an acceptable means for providing dynamic feedback regarding the status of any particular group of cards produced for the issuer.

Moreover, the smart card issuing systems currently in use use the appropriate method developed by either the card manufacturer or the personalization equipment manufacturer. To encourage the sale of their respective cards or equipment, each manufacturer develops a unique personalization solution for a particular card application, and each solution is specific to a particular issuer. These unique solutions are designed to optimize the characteristics of cards or equipment and, thus, do not allow for a wider generalized personalization process, which accepts any card operating system and (or) work with any personalization equipment.

As the demand for smart cards is increasing, a smart card issuing system is required that will allow issuers to use any type of personalization equipment to manipulate a large number of smart card types and their associated operating systems and implement specific applications of issuer's cards, along with the required data of the card holder in any of various types of smart cards.

SUMMARY OF THE INVENTION

The smart card personalization system has a database containing card application data, issuer structure template data, card operating system data and personalization equipment data to enable the issuer to dynamically change card applications (applications), cards and card operating systems and / or equipment personalization in the process of issuing cards without the need to modify the issuer's interface for the issue process.

The smart card personalization system releases portable programmed storage media, or smart cards, by first obtaining a data format identifier, card operating system identifier, personalization hardware identifier, application identifier or identifiers and personalization data for the card holder from the issuer administration system. Identifiers allow the system to address the data stored in the data structure, such as a database, and precisely determine the specific data required by the system for each card to be issued. Due to the fact that each issuer formats its personalization data in different ways and can have a large number of data formats, the smart card personalization system has a database of data format templates that allows it to be combined with a large number of issuer administration systems. The system obtains a format template that defines the personalization data used by a particular issuer from the records in the database, identified by the data format identifier. The system uses a data format template to translate personalization data from the issuer format into an internal format recognized by system components. The system uses the identifier of the operating system of the card and the identifier (s) of the application programs in order to obtain control commands for the operating system previously loaded into the microprocessor chip integrated in the card and application data in the form of code and (or) variables for the type or types of application programs from the database. The system also receives data about the characteristics of the personalization equipment to be used to issue a smart card using the identifier of the personalization equipment. After the system receives all the data necessary for issuing the smart card, it transfers the programming control commands, the code and application variables, and the transferred personalization data to the personalization equipment, determined by the data on the characteristics of the equipment.

Alternatively, the issuer does not skip the data format identifier because the data format template is output from the data in the application data record, or because the personalization format uniquely matches the internal format used by the system. The issuer can also replace the record of the data format template with the data format identifier, so the system does not need to refer to its database of format records.

Another feature of the smart card personalization system is its card administration function. The system of personalization of smart cards communicates information regarding the process of issuing cards, and reports this information to the issuer's administration system.

Smart cards can include one or more "security keys" that are programmed to prevent fraudulent use of the card. The relevant data of the security keys is obtained by the system of personalization of smart cards from the records of the security keys available to the issuer, or from another source of protection, and then transfers them to the personalization equipment. The security source also provides security functions that are used by the personalization system of smart cards to guarantee the safety and security of data during data transfer to and from the system and within the system during the process of personalizing a smart card.

The smart card administration system performs the functions described above through a series of software modules running on a computer or in a large number of computers. One module is the interface of the issuer's administration system, which receives the identifier of the data format, the identifier of the card operating system, the identifier of the personalization equipment, the identifier (s) of the application and personalization data for the card holder from the issuer's administration system. The issuer administration system interface then uses the data format identifier to obtain a format template that defines personalization data and translates the personalization data into a regular internal data format. The card operating system interface module receives programming control commands for the type of card operating system specified by the card operating system identifier. The card application interface module uses the identifier (s) of the application program to determine which type (s) of the application program is to be placed on the card and accepts well-defined code and application variables. The personalization equipment interface module responds to receiving data on the characteristics of the equipment for the type of personalization equipment defined by the identifier of the personalization equipment, and in addition to transmitting programming control commands, code and application variables and translated personalization data to the personalization equipment in accordance with the requirements specified in the equipment characteristics data .

Reporting and protection functions are provided by the tracking / reporting module and the security key administration module.

The smart card personalization system uses an internal data structure, such as a database located in a computer storage medium, to organize the data needed to issue smart cards. The data structure contains several different types of data elements and uses “indexes” or “identifiers” for quick access to specific data. There are four main data elements in the system: an element of the data format, an element of the card operating system, an element of the application program (application program), and an element of personalization equipment.

The data format element contains a template that defines the format of the personalization data used by the issuer. The data format element can be stored in a database containing data format elements for various issuers, and the information stored in the data format element can be accessed using the data format identifier. Alternatively, the data format element can be retrieved simultaneously with the release of the card from the data in the application program element (s) so that the application program identifier (s) passed by the issuer identifies the data format. When the personalization data format exactly matches the internal format used by the personalization system of the smart card, the data format template is logically implied, which creates a virtual data format element for the release process.

The card operating system element contains programming control commands that direct card operating systems that control the smart card microchip and are selected using the card operating system identifier.

An application program element (s) contains application data, such as program code and variables required by applications associated with various issuers; access to application data is through the identifier (ies) of the application program.

The operational parameters for the various types of personalization equipment used to issue smart cards are stored in the personalization equipment element and accessed through the identifier of the personalization equipment corresponding to the type of personalization equipment to be used during the issuing process.

Special configurations of the smart card personalization system support elements that do not require complete system flexibility.

The portable programmable storage medium output system comprises an interface of an issuer's administration system for receiving a personalization equipment identifier and personalization data for a card holder from an issuer's administration system, a personalization hardware interface for receiving equipment characteristics data for a personalization type of equipment from a record in a database identified by a personalization equipment identifier moreover, the interface of the personalization equipment is made with the possibility of further transferring personalization data to personalization equipment precisely determined by the characteristics of the equipment for the type of personalization equipment in order to release the above data carrier.

The system also additionally receives format template data from a record in the database, identified by a data format identifier supported by the issuer's administration system, and converts personalization data into an internal format from a format defined by format template data, so that the interface of the personalization equipment transmits the translated personalization data to the personalization equipment .

The system includes a tracking / reporting processor for collecting data from the system with respect to the release of data carriers and for generating reports of collected data for the issuer's administration system, as well as an application card interface for receiving application data from a record in the database identified by the application program identifier accepted by the interface the issuer's administration system, and the interface of the personalization equipment is configured to additionally transfer application data to the device uru personalization data accurately defined personalization equipment specifications.

The system additionally contains a security key manager for receiving security data from the security source and transmitting security data to the personalization equipment interface, as well as a card operating system interface for receiving programming control commands from a database record identified by the card operating system identifier obtained by the issuer administration system interface moreover, the interface of the personalization equipment is configured to further transmit program control commands personalization equipment, precisely determined by the data of the characteristics of the equipment.

The system further comprises an application interface of cards for obtaining data from a record in a database identified by an application program identifier obtained by the interface of the issuer's administration system, the interface of the personalization equipment being configured to further transmit application data to the personalization equipment, which is precisely determined by the characteristics of the equipment.

A portable programmable storage medium release system according to the invention comprises

personalization equipment receiving a data stream, and in response to it, personalizing portable programmable storage media,

personalization data obtained from the issuer's administration system, and

a smart card personalization system having a database containing one or more data elements selected from a group containing

Data format template elements

card application data elements,

card operating system elements and

elements of personalization equipment,

in which the personalization system of smart cards outputs a data stream as a result of processing personalization data sent by at least one of the selected data elements.

There is also a system for the release of portable programmable storage media containing the system interface for receiving personalization data of the card holder and equipment characteristics data, and for additional transmission of personalization data to personalization equipment precisely determined by the characteristics of the equipment for the purpose of releasing the data medium.

According to the invention, a portable programmable storage medium exhaust system is provided

system interface for obtaining the identifier of the personalization tool and personalization data of the cardholder from the issuer's administration system,

a personalization interface for obtaining characteristics data for a personalization tool type from a record in a database identified by a personalization tool identifier, wherein

the personalization interface is configured to additionally transfer personalization data to the personalization means, precisely defined by the characteristics data for the type of personalization means, in order to release the data carrier.

The exhaust system further comprises an application interface for obtaining application data from a record in the database identified by the application identifier received by the system interface means, the personalization interface being configured to further transmit application data to the personalization means precisely determined by the characteristics data.

The exhaust system further comprises

an operating system interface for receiving programming control commands from a record in a database identified by a card operating system identifier received by a system interface means,

the personalization interface is configured to additionally transmit programming control commands to a personalization tool precisely defined by the characteristics data, moreover

the system additionally receives format template data from a record in the database, identified by a data format identifier supported by the issuer's administration system, and translates personalization data into an internal format from a format determined by the format template data, so that the personalization interface transfers the translated personalization data to the personalization tool.

A method for producing portable programmable storage media according to which

get the identifier of the personalization equipment and personalization data from the issuer's administration system,

receive data characteristics of the equipment for the type of personalization equipment from the record in the database identified by the identifier of the personalization equipment, and

transmit personalization data to the personalization equipment, precisely defined by the data of the characteristics of the equipment for the type of personalization equipment in order to release media. According to the method, personalization data is transferred to the internal format, so that the transferred personalization data is transferred to personalization equipment, personalization data is transferred from the format determined by the issuer administration system to the internal format in accordance with the format template data, and format format data is received from the record in the database, identified by the data format identifier supported by the issuer's administration system.

According to the method, format template data is obtained from the issuer administration system.

According to the method, format template data is obtained from the application data record in a database identified by the application program identifier supported by the issuer administration system, information regarding the release of storage media is collected, and reports obtained from the collected information are generated for the issuer administration system, and also

accept the application program identifier from the issuer's administration system,

receive application data from a record in the database identified by the application program identifier, and

transmit application data to personalization equipment, precisely defined by the equipment characteristics data.

According to the method further

receive protection data from the protection source and transmit protection data to the personalization equipment, determined by the data of the characteristics of the equipment,

accept the card operating system identifier from the issuer's administration system,

receive programming control commands from an entry in the database identified by the identifier of the operating system, and

transmit programming control commands to personalization equipment, precisely defined by the data of the characteristics of the equipment.

According to the method, an application program identifier is additionally obtained from the issuer's administration system,

receive application data from a record in the database identified by the application program identifier, and

transmit application data to personalization equipment, precisely defined by the equipment characteristics data.

A method for producing portable programmable storage media according to which

receive personalization data for the card holder and equipment characteristics data, and

transmit personalization data to personalization equipment, precisely defined by the characteristics of the equipment, for the release of the storage medium.

The smart card personalization system of the present invention overcomes the disadvantages of the prior art by providing a centralized input and output interface for a smart card personalization process designed to enable dynamic adaptation to changes in the issuing process. The system is interfaced with any issuer administration system, administers the transfer of cardholder data and card application to the specific personalization equipment used, and collects statistical data for real-time requests and offline requests for maintaining critical administration and reporting functions. The system contains a database of issuer data formats, card operating systems, card application programs and types of personalization equipment. This database allows the system to manipulate any combinations or permutations of data, thus reducing costs and time for the issuer. Moreover, the system interfaced with various card protection methods to reduce the likelihood of fraud.

Brief Description of the Drawings

FIG. 1A illustrates a flowchart representing a smart card issuing process that includes a smart card personalization system.

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

FIG. 1C is a functional block diagram illustrating software modules and data structures that encompass one embodiment of the smart card personalization system shown in FIG. 1B.

FIG. 2 is a functional block diagram of the embodiment shown in FIG. 1C with the addition of a security module for administering keys used for smart cards.

FIG. 3 is a functional block diagram of another embodiment of a smart card personalization system illustrating a minimal configuration for administering a large number of card types and personalization equipment.

Figure 4 is a functional block diagram of the embodiment of Figure 3 with the addition of a module for administering a large number of card operating systems.

FIG. 5 is a functional block diagram of the embodiment shown in FIG. 4 with the addition of a security module.

6 is a functional block diagram of the embodiment of FIG. 3 with the addition of a module for administering a large number of card applications.

FIG. 7 is a functional block diagram of the embodiment shown in FIG. 6 with the addition of a security module.

Fig. 8 is a graphical diagram of a high-level program for computing system software that implements the functions of a personalization system for smart cards.

9 is a block diagram of an alternative embodiment of a smart card personalization system using software modules and data records.

Figure 10 is a graphical diagram of a program for software of a computing system that performs the functions shown in figure 9 of an embodiment of a personalization system for smart cards.

11 is a diagram of data fields for recording a card structure template used in the embodiment of the personalization system of the smart card shown in FIG. 9.

FIG. 12 is a data field diagram for recording a data format template by the embodiment of the smart card personalization system shown in FIG. 9.

FIG. 13 is a diagram of data fields for recording card application data used by the embodiment of the smart card personalization system shown in FIG. 9.

14 is a recording format showing standard items tracked by a smart card personalization system.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings, which form part of the invention, and which show specific embodiments in which the invention can be used. These implementations are described in sufficient detail to enable those skilled in the art to implement the invention, and it should be understood that other implementations can be used, and that structural, logical, and electrical changes can be made without departing from the spirit and scope of the present invention. . Therefore, the following detailed description should not be taken in the sense of limitation, and the scope of the present invention is defined only by the attached claims.

The first digit (s) of the reference numbers in the drawings usually corresponds to the number of the drawing, except that identical components that are shown in a large number of drawings are denoted by the same reference numbers.

Smart Card Issue

Standard transaction cards, such as ordinary credit cards, are familiar to most people. An operations card usually has information about the card holder, such as name and account number, printed and / or stamped on the surface of the card. Operation cards often contain a magnetic strip, which is also encoded with the data of the card holder. The process of printing-extruding-encoding cardholder data on each transaction card is known as “personalization”. Each transaction card is also subjected to a process known as “initialization”, in which certain types of information, common to all group cards, such as the issuer’s identifier and group number, are placed on the card.

A smart card differs from a standard operation card in that the computer microprocessor chip is integrated into the plastic of the card to greatly increase the storage capacity of the card data. In some types of smart cards, the card manufacturer preloads the microprocessor of one of several possible card operating systems, and the operating system controls the programming of the chip during the personalization process.

In addition, the use of complex cards specific to the issuer can be performed in some types of microcircuits.

The initialization data for smart cards contains three main types of information: application data, security data, and printed data. These applications are common to all cards of this application and include code and application program variables that program into the chip. Security data, usually provided with security keys or security functions, validates the data on the card and prevents fraudulent use of the card. The printed data, such as a brand name, barcode, and various types of digital information, is printed on the surface of the card. Some or all of such data may also be extruded onto the surface. Optical technology can also be used to make part of the surface of the smart card in the form of a storage medium with the ability to sample data with the appropriate optical reader.

The personalization information for a smart card is similar to the information currently on non-smart cards, such as the name of the card holder, account number, expiration date of the card and a photograph. Due to the increased storage capacity, the microcircuit in the smart card may contain additional data, in addition to the basic information available on the standard operations card, including a graphical representation of the person’s signature, data defining the types of cardholder’s permitted services and account limits for these services.

Smart Card Personalization System

On figa shows the components of the process of issuing a smart card, which includes an embodiment of a personalization system of smart cards in accordance with the present invention. The smart card personalization system 100 receives data from the issuer administration system 150 (usually specific to the issuer), transmits the data to the information stream and outputs the information stream to the personalization equipment 130, which personalizes the smart cards 160. The issuer administration system 150 administers the card holder data and determines the type the card to be issued, the use of the card for implementation in the card, and also determines what personalization equipment is used acce for the purpose of issue of the card for a particular cardholder. The issuer's administration system is often a computer program, as shown in FIG. 1A, but the smart card personalization system 100 is capable of receiving data from alternative inputs, such as a person entering data from a telephone keypad. The smart card personalization system 100 is shown in FIG. 1A as a program of a software system used in a computing system. As described above, the smart card personalization system 100 fetches records in a database that define various types of cards and card operating systems, card applications, and personalization equipment.

The logical functions of the software and the database can be distributed among computers on a client / server network or located centrally in one processor. Functions can be distributed among processors connected via standard local area networks, large-scale networks, dedicated telephone networks or other means of communication used for loosely coupled processors. The software system program is run on an operating system such as Unix, Windows 95 ^© , or Windows NT ^© and at an industry standard workstation and / or personal computer hardware.

System 100 controls a card printer, extruders, and integrated or accessory smart card interface devices, collectively presented in FIG. 1A as a personalization system 130. The personalization apparatus 130 also presents devices such as large-volume card printing / extrusion devices, small-volume card printing / extrusion devices, vending machines, trading terminals, automatic information kiosks, personal computers, network computers, and non-autonomous telecommunication devices. Due to their financing in existing non-smart card personalization equipment, many issuers do not buy completely new smart card personalization equipment, but instead supplement their existing personalization equipment with a smart card interface, which programs the chip in the card, while older devices perform printing and extrusion functions . With this configuration, a computing system that functions as a smart card personalization system 100, or “host machine,” can be physically connected to both devices or to only one of the devices. In the latter case, the main machine controls a directly connected device and has a logical connection with another. The physical connection between the devices and the host machine changes according to the manufacturer’s desire and the device model. Typical industry standard connections include the RS232 serial interface, SCSI (Small Computer System Interface), Ethernet, and serial TTLs (transistor-transistor logic). In addition, some devices require a connection using the appropriate bus.

Connections between the smart card personalization system 100 and the issuer administration system 150 and devices 130 can also be implemented using standard local computing systems, large-scale networks, specialized telephone lines, or other remote communications infrastructure used to transmit data. The use of such distance communications in personalizing smart cards is described in US Pat. No. 5,524,857, published July 9, 1996 to Laing et al. Those skilled in the art can find alternative compounds without departing from the scope of the invention.

Figure 1 B shows a block diagram of one embodiment of a smart card personalization system illustrating the logical connections between the smart card personalization system 100 and the functions used by the organization of issuing cards to issue smart cards. Cardholder data contained in the card issuing organization contains information about each individual cardholder, such as name, account number, card expiration date and applicable services. Various methods for entering cardholder data into the issuer administration system 150 are shown in FIG. 1B in dashed lines in the form of cardholder data 152.

The issuer administration system 150 may receive card holder data on a recording medium of a computer, such as a magnetic tape, a floppy disk, a rewritable CD. Alternatively, cardholder data 152 can be entered through a real-time connection, such as a public switched telephone network, a packet-switched network, that is, the Internet, a dedicated line, or a cable / satellite television signal. Those skilled in the art will appreciate the additional ways in which cardholder data 152 can be entered into system 150.

In addition to the issuer's administration system 150, the issuer usually has an existing report formatting option 154 with which the smart card personalization system 100 is conjugated so that the issuer can check the statistical information available in the system 100. An external security source also provided by the issuer and shown as administrator 111 security keys and a database of 128 security keys, provides security functions that operate in accordance with the issuer's administration system 150 and a system of 100 personalization of smart cards. 1B also illustrates an alternative embodiment of a smart card personalization system 100 that supports an issuer having additional smart card interface devices. The system 100 sends a portion of the personalization information to the older personalization equipment 130, and the remaining data to the post processor 132 in the smart card interface 132, which programs the chip. The following is a detailed description of these features.

Embodiments of a software system program for a smart card personalization system 100 shown in the following drawings operate as a combination of code modules with each module performing a specific part of the release process. In these embodiments, the modules are linked through calls to certain input and output programs, and are also connected to data structures via standard data request commands that provide access to the data stored in the data structures. The protocols for exchanging data between modules and between modules and data structures are highly dependent on the language in which the modules are written and on the underlying data administration system used to maintain the database.

On figs presents a more detailed functional block diagram shown in figure 1 In the system 100 of personalization of smart cards without external protection functions. FIG. 1C illustrates internal connections between software modules and database recorders that enable the smart card personalization system 100 to combine a large number of types of issuer formats, card operating systems, card applications, and personalization equipment when issuing smart cards.

The smart card personalization system 100 provides a specialized interface 101 of the issuer administration with the issuer administration system 150. In this embodiment, the issuer administration system 150 passes the personalization data from the cardholder database 152 to the system 100. Each software module in the system 100 expects personalization data to be transmitted to it in a particular internal format. Due to the fact that personalization data has an external format defined by the issuer, which often differs from the internal format (s) expected by the software modules, personalization data is converted by the system 100 into an internal format (formats) using a data format template. The system 100 may obtain a data format template by a data format identifier passed by the issuer, which the system 100 uses to obtain an optional record 120 of a data format template (shown by dashed lines in FIG. 1C), as shown by an optional connection between the recorder 120 and the administration system interface 101 issuer. Alternatively, the issuer passes to the system 100, instead of a data format identifier, a record of a data format template. In another embodiment, the data format template can be obtained from data in the card application record 124, which is determined by the application program identifier that the issuer passes, as shown by the optional connection between the card application database 124 and the issuer administration system interface 101.

In a further alternative embodiment shown in FIG. 1C, internal security functions are provided to the smart card personalization system 100 by passing the security functions to the system as part of the recording of card applications.

FIG. 1C also shows the following alternative implementation in which the personalization data format is consistent with the internal format. Due to the fact that in this embodiment no translation between external and internal formats is needed, a data format template is not required, therefore, there is no data format recording device 120 and no connection between the issuer administration system interface 101 and data format recording device 120 and the database 124 card applications . The data format recording apparatus 120 may comprise a plurality of tables that teach the system 100 regarding the correct lexical analysis of personalization data, or a simple list that shows the order in which the card holder data record fields appear, as will be apparent to those skilled in the art. The various alternative procedures described above for determining the personalization data format are implied in all embodiments of the smart card personalization system 100 described herein.

Using the card identifier used by the issuer administration system 150, the card operating system interface module 103 retrieves the programming control commands specific to the card operating system 122 for the microprocessor chip that is embedded in the card type being issued. Programming control teams control the encoding of the chip with personalization data and the application (s) of the card selected by the issuer.

Each card application program contains program code and variable data that is stored in the database as 124 application data and identified by the application program identifier. The issuer administration system 150 passes one or more program application identifiers to the system 100, which is used by the card application interface module 105 to obtain the corresponding application data 124.

The personalization equipment that the issuer plans to use to issue a group of cards is determined by the identifier of the personalization equipment. The personalization equipment interface module 107 obtains equipment characteristics data 126 specific to the type of personalization equipment 130 corresponding to the personalization equipment identifier. The personalization equipment interface 107 also receives programming control commands, application code and variables, and translated personalization data, and transmits all of these data to the personalization equipment 130, determined by the equipment characteristics data 126, for issuing a smart card.

An alternative implementation of the system 100 supports an issuer that has expanded its existing personalization equipment with a smart card programming device and, thanks to the personalization equipment interface 107, sends a subset of the translated personalization information to older personalization equipment 130, and the rest of the data to a post processor 132 in the smart programming device cards.

A smart card personalization system 100 also provides a module / processor 109 for tracking / generating reports that collects statistical information from other modules in the system 100 and generates statistical information for output as a printout of reports 154, or as input to a report generation function in system 150 issuer's administration. Due to the fact that this statistical information is collected in real time, the issuer administration system 150 may interactively request a tracking / reporting module 109 to obtain statistics on the smart card personalization system as they are executed. Examples of positions controlled by tracking / reporting module 109 are shown in FIG.

In the alternative embodiment shown in FIG. 2, the smart card personalization system 100 includes a security source in the form of a security key manager module 111 and a security key database 128. In the manufacture of the smart card, the manufacturer includes a security architecture on the chip to prevent unauthorized programming. The implementation of the security architecture usually depends on the application (s) programmed on the chip. For example, the security keys programmed in the stored value application program will differ from the security keys programmed in the health card application program. The implementation of the security architecture also varies depending on the type of card: some cards require a single security key that allows microchip programming, while others require a large number of security keys to enable microchip programming to perform additional security functions. Figure 2 shows the main functions of the administrator 111 of the security keys when paired with the security architecture on the card, which requires a large number of security keys.

As shown in FIG. 2, security key data is stored in a security key database 128, which is external to the smart card personalization system 100 and is maintained by the issuer or other security source. The extension of the administrator 111 of the security keys for manipulating additional or several security keys and for interfacing with the security key database administered by the smart card personalization system 100 itself depends on the application, operating system and personalization hardware used in the particular card issuing program, and will be obvious to those skilled in the art in the art.

The security key manager 111 also provides additional mechanisms to guarantee authentication of the security key data, data integrity, and data protection. In one embodiment, authentication of the security key data is accomplished by implementing various encryption methods. The integrity of the security key data is achieved through digital signature mechanisms that use public keys to ensure that the security key data is transmitted and received from reliable sources. Data protection of security keys is provided by encrypting the transmitted data with a private key, which is shared with the data receiver, and which the data receiver uses to encrypt data at reception.

After the system 100 receives the security key record from the security key database 128, the security key manager 111, together with the card operating system interface 103 and the card application interface 105, authenticates the security keys, data integrity and data protection functions. The system 100 then transmits the security key data to the personalization equipment 130 through the personalization equipment interface 107 along with other card data.

In an alternative embodiment, the security key manager 111 passes security information to other modules of the smart card personalization system 100. For example, parts of the cardholder’s data, such as LIN (personal identification number), can be encrypted by the issuer's administration system 150 before passing data to the smart card personalization system 100. The issuer's administration system interface 101 retrieves the encryption key from the security key database 128 through the security key manager 111 and decrypts the data before encoding or programming the LIN code into a magnetic strip or microcircuit.

In yet another alternative embodiment, the security key manager 111 is a code hook to the smart card personalization system 100, which provides a gateway connection to an external security source that provides the required security features. An example of such an external security source is a security administrator program written by a third party that administers a security key protection database and / or security functions similar to the 128 security key database. Security functions can be either external routines executed by the security administrator, or code modules skipped by the security administrator, which are often executed by the personalization system 100 of smart cards in order to provide the required security functions, or a combination of both.

Figure 3 presents the minimum configuration of the system 100 personalization of smart cards. In this embodiment, only modules 101 of the issuer's administration interface and modules 107 of the personalization equipment interface are unlocked in the software. This implementation option allows the issuer to use the system 100 to personalize non-smart cards, thus saving on the costs of maintaining two separate personalization systems, while at the same time using a large number of data formats and a large number of types of personalization equipment. FIG. 3 also shows a further alternative embodiment, which includes a tracking / reporting module 109 described above in connection with FIG. 1C.

In yet another alternative embodiment, the smart card personalization system 100 shown in FIG. 3 encodes data onto an optical transaction card when optically encoded equipment is used as personalization equipment 130.

Figures 4 and 5 show the following alternative implementations that are carried out when the issuer does not program the use of the card on the smart card chip. These implementation options allow the issuer to issue a large number of card types with an accompanying variety of operating systems on a large number of personalization equipment types without configuring the smart card personalization system 100. As described above in connection with FIG. 1C, FIG. 4 includes modules that support reporting. FIG. 5 illustrates embodiments shown in FIG. 4 with the addition of a security key manager module 111, which protects the interface 103 of the card operating system for transmission to personalization equipment 130.

Similarly, FIGS. 6 and 7 show embodiments for supporting an issuer that uses a chip on a smart card only as a storage device for using the card and does not have an operating system on the chip. The smart card personalization system 100 serves a large number of card applications for a large number of card types used with a large number of personalization equipment types. 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.

Fig. 8 is a high-level graphical diagram of a program for one embodiment of software that implements the above-described functions of the smart card personalization system 100. The software, at 801, obtains the identifier (ID) of the personalization equipment for the group of transaction cards to be issued from the issuer's administration system. Depending on the type of cards to be issued, the software at the same time also receives the identifier (s) for using the programs and (or) the identifier of the card operating systems. The software then obtains a data format control pattern corresponding to the personalization data format through one of the above protocols (block 803). At block 805, the system obtains the characteristics of the personalization equipment to be used to issue a group of cards from the personalization equipment record identified by the personalization equipment identifier.

If the issuer's administration system identifies the card operating system identifier (step 807), the software extracts the programming control commands from the records in the database (DB) of the operating system (O / C) cards corresponding to the card operating system identifier (step 809). At steps 811 and 813, the same logic is executed for applying the card, extracting application data, such as code and / or variables, from the database. At this point, the software receives the usual data needed for all cards in the group, and starts organizing cycles through a logic circuit that issues cards for individual cardholders.

The issuer's administration system passes personalization data for one cardholder to software (step 815), which transfers the data elements from the format defined by the data format template to the internal format used by the smart card personalization system modules (step 817). If the card chip contains a security architecture that requires key protection (block 819), the software, in block 821, obtains the security key data necessary to perform the functions of the security keys from the corresponding source of the security keys.

Now the software is ready to transfer data to personalization equipment for the purpose of programming the card. If the card is protected by security keys, the functions of the security keys are performed, and at step 823 the security key data is transmitted. Then, programming control codes for the microcircuit operating system are transmitted (block 825 and 827), if applicable; then the code and (or) application variables are transmitted, if necessary (step 829 and 831). And finally, at step 833, personalization data of the cardholder is transmitted, which has been converted to an internal format.

After the data are transferred to the card, the software adds the corresponding values with the statistical data that it collects for the issuer's administration system at step 839. If there are still cards of the same group for issuing (step 841), the software returns to step 815 and receives personalization data for next card holder. Otherwise, the software determines whether the issuer's administration system has another group of cards to be issued (block 843), and returns to block 801 to receive the necessary cycle information for the new group. If there are no more additional cards to be issued, then the software completes the execution.

The mechanisms by which the issuer administration system 150 passes the necessary data to the smart card personalization system 100, and the order in which the card personalization system processes data from the issuer administration system can be changed without departing from the scope of the invention. The various arrangements are determined by the particular condition in which the system 100 operates, as shown in the alternative implementation of FIGS. 9 and 10.

The security module 911 shown in FIG. 9 acts as a gateway to the smart card personalization system 100 for the security source, such as the security administrator 940 and the security database 942 shown in FIG. 1B at 111 and 128, respectively. The security manager 940 controls access to the security database 942 and is connected to the security gateway 911 to perform the necessary security functions with respect to the smart card personalization system 100. The security gateway 911 is connected to the interface 901 of the issuer's administration system, which allows the interface 901 to request that the security administrator 940 decrypt the personalization data that was missed in the encryption format by the issuer administration system 950. The security gateway 911 is also connected to the card application interface 903 and the card operation interface 905, so that it can provide the necessary security keys and / or security functions for those interfaces that were explained above with reference to FIG. 2.

In addition, the embodiment of the smart card personalization system 100 shown in FIG. 9 receives application data 922 determined by the application program identifier before receiving programming control commands specific to the operating system 924 cards using the card identifier. This implementation option allows you to convert personalization data and application data into an internal format before extracting programming commands for the operating system 924 cards and data 926 characteristics of the equipment, thus speeding up the processing of such an intelligent card.

Standard transaction cards have data printed and extruded onto the surface of the card, and / or data encoded in a magnetic strip on the card. In the case of a smart card, data can also be stored in the internal memory area of the microprocessor. The same data can be placed on the surface of the card in a magnetic strip, as well as in the storage device of the chip. This configuration of the data in and on the card strongly depends on the type of smart card issued and the requirements of the issuer.

FIG. 10 is a high-level graphical diagram of the program of the embodiment shown in FIG. 9 and, in connection with FIGS. 11, 12, and 13, further illustrates how various mechanisms can be used to implement smart card personalization system 100. The issuer administration system 950, in step 1001, skips a card structure template that determines the configuration of the smart card for the smart card personalization system 100.

11 illustrates one embodiment of a data format for recording 1100 a card structure template. The microprocessor chip identifier 1101 and the card operating system identifier 1102 (if any) are specific to the smart card to be issued. The definition of the main file 1103 contains control information, for example, the source of the chip and the last date when the chip was changed. System file definitions 1104, 1105, 1107 contain addresses for the locations of system files in the chip memory. System files are used by the operating system of the card and contain information such as LIN code (s) for cards and applications, and table algorithms. In the embodiment shown in FIG. 11, the main file and system file definitions correspond to directive number 7816-4 of the International Organization for Standardization (ISO).

The following three sections 1100 of the card structure template determine the location of the data on the surface and magnetic strip of the card. If the information is such that it needs to be printed on the card, for example, photograph 1109 of the card holder, the location on the surface of the card for printing such data is skipped by the issuer administration system 950 in the printing pattern of the record 1100 of the card structure template. Similarly, the location on the surface of the card for extruding data is skipped in the extrusion pattern, and the location of the data to be encoded in the magnetic strip is skipped in the magnetic strip pattern. The extrusion data in the record 1100 of the card structure template is illustrated, such as the name (name extrusion) 1111, account number (accounting extrusion) 1113, and the expiration date (extrusion of the expiration date) 1115, and the magnetic strip data by the account number (MP account) 1117 and the term expiration date (MP expiry date) 1119. The number of data positions in the printing, extrusion and magnetic strip patterns strongly depends on the configuration of the smart card required by the issuer, as it will be clear to those skilled in the art .

If the issuer needs card applications programmed into the chip in the smart card, the issuer passes the application program identifiers to the smart card personalization system 100 in sections 1121, 1123, 1125 of the record 1100 of the card structure template. Each application program may have special security functions associated with it (1127, 1129, 1131), and this information is also passed through by the issuer administration system 950. The card structure pattern template record 1100 also contains a personalization equipment identifier 1123 for the personalization equipment to be used to issue smart cards.

In an alternative implementation, the smart card personalization system 100 stores commonly used card structure template entries in an internal database, so that the issuer administration system 950 should only pass the card structure template identifier, which identifies which card structure template record should be used for a particular group of cards.

The smart card personalization system 100 obtains, at step 1003, a personalization data format template from a predetermined location determined by the issuer. If the issuer passes the data format identifier to the system 100, the data format pattern entry corresponding to the data format identifier is retrieved from the database 920 data formats. Alternatively, the issuer may skip the recording of the data format template itself. If neither the data format identifier nor the recording of the data format template is passed to the system 100, the personalization data format is determined by the card application data, as will be explained in more detail below.

An example of recording a data format template is shown in FIG. The data format pattern template record 1200 defines a hypothetical arrangement of personalization data records in the card holder database 952, in which account number 1201 represents the first field, card holder name 1202 represents the second field, and the expiration date 1205 represents the third field. In one embodiment, personalization data records are comma-separated records, so data field lengths are not needed to determine the recording format. Thus, the data format pattern template record 1200 shown in FIG. 12 completely defines the structure of the following example of a comma-separated personalization data record for the smart card personalization system 100: 133444999922, Mary Jane Smith, 0299.

The system 100 personalization of smart cards receives at step 1007 data 922 applications for applications or applications of cards corresponding to the identifiers of the application programs, if any, that were missed by the issuer administration system 950. If the issuer's application program identifiers are not skipped, the smart card personalization system 100 receives default application data (step 1008). The default value and / or application data in the record (s) of card application data corresponding to the identifier (s) of the application program are entered in the corresponding sections, that is, 1121, 1123, 1125, records 1100 of the card structure template.

One embodiment of a card application data recording arrangement is shown in FIG. 13. The first field in the card application data record 1300 is the application name 1301. As with other computer-based software applications, the card application program processes data from external sources, such as a vending machine, or internal sources, such as data files encoded into the microprocessor's memory. Using a smart card causes the corresponding application program to be executed by the microprocessor, and the application program, in turn, provides access to internal files for the purpose of extracting or storing data. To extract internal data, the application data record of the card contains the application file pointers in the memory (1302, 1305, 1037) of the chip, as well as the location of the fields in the application files. Some fields are initialized with data from the cardholder database 952 when the card is issued. The application data 1300 includes the address 1303 of the card holder data file located in the microchip memory, and a card holder file is defined that contains three fields: card holder name (1C name) 1309, account number (1C account) 1311, and expiration date ( 1C expiration date) 1313. In other application files, additional internal data is stored, and the location of these additional files is also determined by the data of 1300 applications.

If the chip embedded in the smart card contains an operating system precisely defined by writing the card structure template, the smart card personalization system 100, at 1011, receives a set of programming control commands for the operating system from the database 924 of operating card systems. Programming control commands for each operating system include commands for functions, such as creating files and accessing them in the memory of the microcircuit, reading and writing records in files located in the memory of the microcircuit, together with security commands that verify PIN codes (personal identification codes numbers) and control operations that quickly change the values stored in the microcircuit.

The smart card personalization system 100 in step 1013 receives the hardware characteristics data corresponding to the personalization hardware identifier in a card structure template record from the personalization equipment database 926. A set of personalization programming control commands that control the operation of personalization equipment is included in the data on the characteristics of the equipment. As with card operating systems, personalization management teams are owned by the hardware vendor and typically include commands for administering, formatting, and creating smart cards.

When the smart card personalization system 100 receives all the data necessary to determine the smart card, it is ready to accept personalization data records 952 from the issuer administration system 950. When you pass each personalization data record 952 at step 1015, the smart card personalization system 100 uses a data format template, if available, to translate personalization data into an internal format, and card application data and a card structure template to convert personalization data into variables in the command bar recorded in the internal scripting language at step 1017. The translation and conversion process is further described below. The scope of the invention includes alternative implementations in which a standard programming language such as BASIC, Java or C is used instead of the internal scripting language.

The smart card personalization system in step 1019 checks the security requirements for various components of the smart card issuing process. In the embodiment of the card structure template shown in FIG. 11, security requirements for applications are determined at 1019 by writing 1100 the card structure template. If there are security requirements, the smart card personalization system 100 receives the security data and / or functions from the security administrator 940 and adds functions to the internal script at 1021. An alternative implementation of the smart card personalization system 100 passes the identifiers of the card operating system and personalization equipment, as well as the application program identifier, to the security administrator 940, which outputs the corresponding data and / or security functions from the security database 942. Security functions usually use data from additional sources, including data stored in the internal files of the chip, personalization data 952, a database of 924 operating systems, a database of 922 card applications combined with tables of algorithms stored in the chip, or from an external protection module, such as security administrator 940, for performing authentication of security keys, data integrity, data protection, and other security processes described in connection with FIG.

After the script of internal commands is completed, it must be transferred to specific programming control commands inherent in the operating system (if any) of the card and personalization equipment, so that the personalization data is transferred to the smart card. In this embodiment, the translation is performed in steps 1025 and 1027 by the scripting language interpreter using information obtained from the card operating system database 924 and the personalization equipment database 926.

At 1029, the smart card operating system 100 passes the interpreted script to the personalization equipment, which then executes the programming control commands to extrude / print, encode and program the corresponding personalization data to the surface and to the magnetic strip and chip, respectively, of the smart card. As described above, if the issuer decided to purchase additional smart card programming equipment in order to connect to its existing personalization equipment, an alternative embodiment of the smart card personalization system 100 sends control commands for extrusion and encoding to personalization equipment 930, and a control command for the microcircuit to the post processor 132 in the smart card programming device.

Upon completion of the process of issuing one card, the smart card personalization system 100 receives the next personalization data record if there are additional cards of the same type awaiting release (step 1033). Otherwise, the smart card personalization system determines whether there is another group of smart cards of another type awaiting issue (step 1001), and again starts the issuing process by receiving a new record of the card structure template from the issuer.

In the example below, sample data is used to further describe the processing performed by the embodiment of the smart card personalization system 100 shown in FIGS. 9 and 10. The issuer's administration system 950 requests initialization of the issuing process by sending to the smart card personalization system 100 a record of the card structure template, application program identifier (s), card operating system identifier, hardware identifier, and optionally a data format template identifier or data format template record. In this example, the issuer administration system 950 skips the application resource template entry shown below, which contains identifiers. System 100 obtains a data format template using one of the above procedures, and explained in more detail below in connection with samples of a cardholder data record.

Application Resource Template Record | A1 | DFT = CARD1.DFT CAT = CARD1.CAT CID = CHIPX.CID CPT = CARD1.CPT SOURCE = A1

The first statement in the record marks the beginning of the information for a particular application, in this case, the use of "A1". The following four operators define identifiers for recording a card structure template (DFT), card application recording (CAT), card operating system recording (CID), and personalization equipment recording (CPT). The last operator represents the name of the file created by the card issuing administration system 950, which contains a record (s) of cardholder data. The card issuing administration system 950 enters the cardholder's data as either a single request or a “group” of requests regarding the cards to be issued.

System 100 outputs identifier entries from the database. The system 100 then uses the information contained in the card structure template and in the data format template to create an internal “script” that later translates specific commands contained in the card operating system and personalization equipment records that instruct the personalization equipment to process the personalization data and issue the card for each card holder.

Shown below are two sample records of 952 cardholders.

Cardholder Data Records Smith, James ^ 12653683091245 ^ 0998 ^ 041052 ^ mmmm Anderson, Sue ^ 39485003984138 ^ 0297 ^ 110248 ^ mmmm

In these records, the format determined by the issuer has the account name (name of the card holder) in the first field, followed by the account number, expiration date, date of birth and medical data.

System 100 uses a data format template to interpret each card holder data record 952 during processing. System 100 also uses records 922 of the data format template and card applications to validate data 952, providing the correct data and format. An example of a data format template corresponding to the format of the above samples of a cardholder record is shown in the first row of the table below. James Smith's personalization data record is included in the table to show the correspondence between the data format template and the cardholder's data record fields. The data format template aligns each field in the cardholder’s record with the internal mark% 1,% 2, and so on, which corresponds to the internal order used in system 100.

Writing a data format template

Writing a data format template %1 % 2 % 3 %4 %5 Smith, James ^ 1265363091245 ^ 0998 ^ 041052 ^ mmmm

The above example represents the simplest case in which the fields of the cardholder data record 952 are arranged in the internal sequence used by the smart card personalization system 100. This one-to-one sequence means that the system 100 does not have to translate the cardholder data fields into an internal sequence of fields. In this case, writing a data format template is optional. Thus, in yet another alternative embodiment, the issuer does not pass the data format identifier to the smart card personalization system 100, but instead passes an indicator, such as a sign that informs the system 100 that the data format template is not needed, because the card holder’s data fields are in a one-to-one sequence with an internal sequence of fields. System 100 acts on the indicator by bypassing the translation step.

The more complex example shown below is an example in which the fields of the cardholder data record 952 and the data in the fields have a sequence different from the internal sequence of the system. In this case, a translation is necessary.

Cardholder data in issuer format 12345667891245 Jamts Smith 0998 041052 mmmm Cardholder data translated into internal format Smith, James ^ 1265383091245 ^ 0998 ^ 041052 ^ mmmm

System 100 uses a data format template to translate data fields into an internal sequence, as shown above. The translation may result in physical redistribution of the data fields or may be a local redistribution in which the data format template is activated as a key each time the system 100 accesses the data field of the card holder. Various data format templates designed to translate different locations of cardholder data, as well as replacing tables with field equivalents or a set of parsing instructions or other mechanisms, to select the table used above to illustrate this example, will be apparent to those skilled in the art.

The record of the card structure template describes the structure of the microcircuit on the card. In the sample shown below, the $ MF element defines the root directory (3F00), while the $ DF elements determine the medical application (5F20) and accounting application (5F10). In each directory, specific application files are identified by $ EF elements, such as 6F00, which contains the account name, and 6F10, which contains the account number. Descriptive data of all files is placed in the card structure template, and they are accessed at various points in time during the process of issuing the smart card.

Card Structure Template Record $ CHIP = 31026MEM = 81926SIZE = N10 $ MF PATH = x3F006, TAG = ROOT, TITLE = 'Root Directory', SIZE = D7194 $ DF PATH = x3F005F10, TAG = ACCT, TITLE = 'Acct Data', SIZE = D2048 $ DF PATH = x3F005F20, TAG = MED, TITLE = 'Medical', SIZE = D1024 $ EF PATH = x3F003100, TAG = ICCID, TITLE = 'Issuer ID ', FORMAT = T, SIZE = D10 $ EF PATH = x3F005F205E00, TAG = MEDI, TITLE = 'Medical profile ', FORMAT = T, SIZE = D80 $ EF PATH = x3F005F106F00, TAG = NAME, TITLE = 'Acct Name ', FORMAT = T, SIZE = A30 $ EF PATH = x3F005F106F10, TAG = ACCTID, TITLE = 'Account No. ', FORMAT = T, SIZE = N14 $ EF PATH = x3F005F106F20, TAG = EXPIRE, TITLE = Expire Date ', FORMAT = T, SIZE = N4 $ EF PATH = x3F005F106F30, TAG = BIRTH, TITLE = 'Account Holder Birthdate ', FORMAT = T, SIZE = N6

Record 922 card applications “converts” cardholder data 952 into data fields used by the application program. The sample of the record 922 of the card applications shown below has data elements arranged in the sequence in which they are processed by the smart card personalization system 100.

Recording Card Applications $ VL ICCID VALUE = 1234509876 $ VL MEDI% 5, TYPE = A $ VL NAME% 1, TYPE = A $ VL ACCTID% 2, TYPE = N $ VL EXPIRE% 3, TYPE = N $ VL BIRTH% 4, TYPE = N $ VL FMTACCT% 2 (1-4) -% 2 (5-9) -% 2 (10-14)

The ICCID element contains the chip identifier. Each of the other elements, with the exception of FMTACCT, converts a “tag” in a field in a cardholder data record 952, which contains information (as defined in the data format template above) and determines the type of data in the field. Thus, the MEDI tag represents the fifth field in the cardholder data record 952, and the data is in alphabetical format. The FMTACCT element breaks the second field in the cardholder data record 952, that is, the account number, into sections and enters hyphens between sections.

The card operating system record 924 contains the programming control commands necessary for programming the microcircuit on the card. The selection of card operating system programming control commands shown below is taken from ISO (International Organization for Standardization) directive number 7816-4, and these commands are not internal specific commands of any particular card operating system.

Card operating system recording SELECT A0A4000002% F WRITE A0D0% 0% L% D READ A0B0% 0% L% D RESET VALUE = xFF

Each element in the above sample record contains a flag, followed by a corresponding command in the native language of the card operating system. Fields of variable parameters are shown by the index "%", followed by a letter, and are filled in with the corresponding data of the card holder during processing of each individual card.

The personalization equipment record 926 contains personalization equipment characteristics data, such as instructions that determine the actual sequence, and the steps necessary to issue the completed card on a special set of personalization equipment. The sample instructions used in this example are imaginary and do not represent internal specific instructions for any particular personalization equipment.

Personalization equipment recording SEMBOSS     # EMB #% FMTACCT% ^% NAME% $ ENCODE     #ENC # %%% ACCT ID% ^% NAME% Sic     # @ #     @ICCID     WRITE ICCID     © NAME     SELECT ACCT     SELECT NAME     WRITE NAME     © ACCTID     SELECT ACCTID     WRITE ACCTID     © EXPIRE     SELECT EXPIRE     WRITE EXPIRE $ PR

When each card is issued, the personalization equipment characteristics shown above are sequentially processed in four stages determined by the issuer, which are preceded by the $ index. A record of 922 card applications is used to determine the field values of variable parameters in each instruction.

The $ EMBOSS instruction is a single data stream that begins with the control sequence # EMB #, notifying the personalization equipment that the data that follows it should be aligned on the card. Each data field in the instruction is enclosed in a pair of percent signs. In this case, the first data field is FMTACCT or the formatted accounting field defined in the record 922 card applications. System 100 searches for a record of 922 card uses for the FMTACCT issuer and creates the string “1265-36830-91245” from the second data field in the first sample record 952 of the card holder. The next field, NAME (name), is taken from the first data field in record 952 of the card holder. Thus, the squeeze instruction for the first sample record 952 of the cardholder becomes # EMB% 1265-36830-91245 %% Smith, James%.

The $ ENCODE instruction causes the system 100 to process the cardholder data to be encoded on the magnetic strip of the card in the same manner as the extruder instructions. Additional control characters are entered into commands in accordance with the following standards: IATA (International Air Travel Association (IAVP)) and ISO (MOC). It turns out the following structure: #ENC # %%% 12653683091245 %% Smith, James%.

The $ IC command determines the information to be stored in the card's memory. Record 924 of the operating system of the card is used to translate the instructions in the recording of personalization equipment into programming control commands for the operating system. The control sequence \ @tt is used to notify the personalization equipment that the subsequent data is chip data. The first field to remember is the ICCID. The system 100 interprets the WRITE flag (record) in the personalization equipment record 926 in accordance with the command identified by the WRITE flag in the card operating system record 924. Since the offset value is not defined for the chip identifier element in application record 922, the default operator “0000” is loaded into the variable parameter file% 0. The variable parameter field% L is set to the SIZE value (size) of the field in the SCHIP element in the card structure template, that is, "10" or the hexadecimal number "OA". The% D variable parameter field is set to ICCID, "1234509876". The resulting team is the A09000000A1234509876 team.

The following commands cause the operating system to memorize the card holder’s name in the account name file on the card’s directory. System 100 translates the ACCT SELECT (selection) command into the corresponding card operating system command. System 100 locates the SELECT element (selection) in the card operating system record 924, the ACCT element in the card structure template record and replaces the established catalog path with the accounting directory defined in the ACCT element, that is, 5F10, for the variable parameter field% F in the command defined in the SELECT element (selection). The resulting team is team A0A40000025F10. Similarly, the SELECT NAME command (selection name) causes the system 100 to replace the account name file "6F00" with the variable parameter field% F. The resulting team is A0A40000026F00. The final command in this sequence is the WRITE (write) command. System 100 interprets the WRITE command by replacing the default offset “0000” with% 0, the value of the SIZE field (size) with “30”, or the hexadecimal number “1E” defined by the NAME element in the card structure template entry with% L , and the name of the Smith, James card holder for the first selective record of 952 card holder data on% D in order to create the team A0D000001E Smith, James≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈, where each character is “% "represents a trailing space entered to fill the remote name with thirty characters.

The system 100 processes the remaining commands in the personalization equipment record 926 in a similar way to create a continuous strip of data containing card issuing instructions for the first selective record of card holder data 952:

# @ # A0D000000A123459876A0A40000025F10A0A40000026F

00A0D000001ESmith, James≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈≈A0A40000

026F10A0A4000002E12653683091245A0A40000026F2040998.

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

Shown in FIG. 11, 12 and 13, the data formats and sample data described in connection with the above example are only examples used to illustrate the functioning of various embodiments of the smart card personalization system 100. These formats and data are necessarily determined by the condition in which they are used, and will be apparent to those skilled in the art.

Those skilled in the art also understand that the smart card personalization system 100 embodies alternative embodiments of a software system program in which system functions are performed by modules other than those shown in the figures. System 100 may process data in a sequential or parallel manner or in a combined manner, without departing from the spirit and scope of the invention. A software system program can be written in one or more commonly used programming languages, and modules can be encoded as subprograms, subsystems, or objects, depending on the language selected. Similarly, the data used by system 100 is described and presented as logical records embodied in a database, but the invention is not limited to the described embodiment of data records and is not the use of any particular type of proposed data administration system. Relational database systems from vendors such as Oracle, Seabase, Informix, or Microsoft provide the necessary infrastructure for administering basic data in a system where they are centralized and distributed, but they can be replaced with other organizational data structures, that is, indexed flat files without leaving while beyond the scope of the invention.

In addition, those skilled in the art will recognize alternative embodiments of the invention that implement the system in hardware, firmware, or in combination of hardware and software and hardware, as well as distributing the modules and (or) data in a different way within the scope inventions.

It should be understood that the above description is intended to illustrate and not limit. When considering the above description, many other embodiments of the invention will become apparent to those skilled in the art. However, the scope of the invention will be determined by the appended claims together with the full scope of equivalents to which the scope of protection of such claims applies.

Claims (23)

1. A method for producing portable programmable storage media, which consists in obtaining a personalization equipment identifier and personalization data from the issuer's administration system, obtaining equipment characteristics data for a personalization equipment type from a record in a database identified by a personalization equipment identifier, and transmitting personalization data to personalization equipment, precisely determined by the data of the characteristics of the equipment for the type of personalization equipment that performs programming control commands for extruding / printing, encoding and programming the respective personalization data of each card holder, thereby releasing portable programmable storage media. 2. The method according to claim 1, characterized in that it further translates the personalization data into an internal format recognized by the components of the system, and then transfers them to the personalization equipment. 3. The method according to claim 2, characterized in that the personalization data is transferred from the format determined by the issuer's administration system to the internal format in accordance with the format template data. 4. The method according to claim 3, characterized in that it additionally obtain format template data from a record in a database identified by a data format identifier supported by the issuer administration system. 5. The method according to claim 3, characterized in that it further obtains the format template data from the issuer's administration system. 6. The method according to claim 3, characterized in that they additionally obtain format template data from the application data record in the database, identified by the application program identifier supported by the issuer administration system. 7. The method according to claim 1, characterized in that it additionally collect information regarding the release of the aforementioned programmable storage media, and generate reports obtained from the collected information for the issuer's administration system. 8. The method according to claim 1, characterized in that they additionally obtain the application program identifier from the issuer's administration system, obtain application data from a database record identified by the application program identifier, and transmit application data to the personalization equipment determined by the personalization equipment characteristics data. 9. The method according to claim 1, characterized in that it further obtains the protection data from the protection source and transmits the protection data to the personalization equipment, determined by the characteristics of the personalization equipment. 10. The method according to claim 1, characterized in that they additionally obtain the identifier of the operating system of the card from the issuer's administration system, receive programming control commands from a record in the database identified by the identifier of the operating system, and transmit programming control commands to the personalization equipment precisely defined by the data personalization equipment characteristics. 11. The method according to claim 10, characterized in that it further obtains the identifier of the application program from the issuer's administration system, obtains application data from a record in the database identified by the identifier of the application program, and transfers the application data to the personalization equipment precisely determined by the data of the equipment characteristics. 12. The method according to any one of claims 1 to 11, characterized in that the personalization equipment is such devices as devices for printing / extruding cards of large volume, devices for printing / extrusion on cards of small volume, vending machines, trading terminals, automatic information kiosks, personal computers, network computers and non-autonomous telecommunication devices. 13. A system for producing portable programmable storage media containing an interface of an issuer's administration system for receiving a personalization equipment identifier and personalization data for a card holder from an issuer's administration system, a personalization hardware interface for receiving hardware characteristics data for a type of personalization equipment from a record in a database identified by an identifier personalization equipment, and the interface of the personalization equipment is configured to yes further transferring personalization data to personalization equipment precisely determined by personalization equipment characteristics data for the type of personalization equipment for releasing a portable programmable storage medium, said personalization equipment being capable of extruding / printing, encoding and programming the corresponding personalization data of each card holder, thereby releasing portable programmable storage media. 14. The system of claim 13, characterized in that it is configured to receive format template data from a record in a database identified by a data format identifier supported by the issuer's administration system, and translate personalization data into an internal format from a format determined by the format template data, wherein the translated personalization data is transmitted by the interface of the personalization equipment to the personalization equipment. 15. The system according to item 13, characterized in that it further comprises a tracking / reporting processor for collecting data regarding the release of portable programmable storage media data carriers and for generating reports of the collected data for the issuer's administration system. 16. The system according to item 13, characterized in that it contains an application card interface for receiving application data from a record in the database identified by the application program identifier adopted by the issuer administration system interface, the personalization equipment interface being configured to additionally transfer application data to the equipment personalization, precisely determined by the characteristics of personalization equipment. 17. The system according to item 13, characterized in that it contains the administrator of the security keys for receiving protection data from the protection source and transmitting protection data to the interface of the personalization equipment. 18. The system according to item 13, characterized in that it contains the interface of the operating system of the card for receiving programming control commands from a record in the database identified by the identifier of the operating system of the card obtained by the interface of the issuer's administration system, and the interface of the personalization equipment is configured to further transmit commands control programming for personalization equipment, precisely defined by the characteristics of personalization equipment. 19. The system according to p. 18, characterized in that it contains the application interface of cards for obtaining data from a record in a database identified by the application program identifier obtained by the interface of the issuer's administration system, and the interface of the personalization equipment is configured to further transmit application data to personalization equipment precisely defined by the characteristics of personalization equipment. 20. The system according to any one of paragraphs.13-19, characterized in that the personalization equipment is such devices as devices for printing / extruding cards of large volumes, devices for printing / extrusion on cards of small volumes, vending machines, trading terminals, automatic information kiosks, personal computers, network computers and non-autonomous telecommunication devices. 21. A system for issuing portable programmable storage media comprising an issuer's administration system capable of administering cardholder data for insertion in a card and determining which personalization equipment to use to issue a card for a particular card holder, personalization equipment receiving a data stream from a personalization system smart cards and performing operations on extrusion / printing, coding and programming personalization data for each cardholder, thus releasing and personalizing portable programmable storage media, the smart card personalization system having a database containing one or more data elements selected from the group containing data format template elements, data card application elements, elements of the card operating system and elements of personalization equipment, while the personalization system of smart cards is configured to output via eye data as a result of processing the personalization data directed to at least one of the selected data elements. 22. The system according to item 21, wherein the personalization equipment is such devices as devices for printing / extruding cards of large volume, devices for printing / extrusion on cards of small volume, vending machines, trading terminals, automatic information kiosks, personal computers, network computers and non-autonomous telecommunication devices. 23. A method for producing portable programmable storage media, according to which personalization data for a card holder and personalization equipment characteristics data is received and personalization data is transmitted to personalization equipment precisely defined by personalization equipment characteristics data that performs extrusion / printing, encoding and programming of relevant data personalization of each card holder, releasing and personalizing, thus, portable programs mirrored storage media.

Images