CN1308750A - Dynamic smart card synchronization and personalization method and device - Google Patents

Abstract

A system for personalizing and synchronizing smart card data within a distributed transaction system includes a smart card access point (102) that initiates transactions with a smart card (120), one or more enterprise data collection units (112), a security support client server, a card object database update system (106), one or more enterprise data synchronization interfaces (108), and an update logic system (110). Personalization of a multifunction smart card is achieved using a secure server that is structured to generate and/or retrieve encryption key information from multiple enterprise key systems during the final stages of the smart card issuance process.

Description

Dynamic smart card synchronization and personalization method and device

technical field

The present invention relates generally to integrated circuit cards ("smart cards") for commercial transactions, and more particularly to techniques for dynamic synchronization and personalization of smart card information in the context of a distributed transaction system.

Background technique

Recently, developments in Internet commerce, electronic data processing, and semiconductor device technology have led to increased interest in smart card technology. In general, a smart card is a wallet-sized (or smaller) card that incorporates a microprocessor or microcontroller that stores and manages data within the card. Being more complex than magnetic stripes and stored-value cards, smart cards exhibit advanced memory management and security functions. For example, multi-function cards are often provided to support debit, stored value, loyalty and many other applications within one card. A typical multifunction smart card includes a microcontroller embedded within a plastic card that is electrically connected to an external array of contacts located on the outside of the card. The microcontroller of the function card usually includes an electrically erasable programmable read-only memory (EEPROM) for storing user data, a random access memory (RAM) for erasing storage, and a memory card operating system. Read memory (ROM). Relatively simple microcontrollers are suitable for controlling these functions. Thus, smart cards typically use an 8-bit, 5MHz microcontroller (eg, Motorola 6805 or Intel 8051 microcontroller) with 8K EEPROM memory.

A number of standards have been developed for various aspects of integrated circuit cards such as: ISO 7816-1, Part 1: Physical characteristics (1987); ISO 7816-2, Part 2: Dimensions and locations of contacts (1988); ISO 7816 -3, Part III: Electronic Signaling and Transmission Protocol (1989, Amd.1 1992, Amd.2 1994); ISO 7816-4, Part IV: Inter-industry Commands for Interchange (1995); ISO 7816- 5. Part V: Numbering System and Registration Procedures for Application Identifiers (1994, Amd.1 1995); ISO/IEC DIS 7816-6, Inter-Industry Data Elements (1995); ISO/IEC WD 7816-7, Section Part VII: Enhanced Inter-Industry Commands (1995); and ISO/IEC WD 7816-8, Part VIII: Inter-Industry Security Architecture (1995). These standards are incorporated herein by reference. Furthermore, general information on magnetic stripe and chip cards has been found in many standard texts, such as Zoreda and Oton's "Smart Cards" (1994) and Rankl and Effing's "Smart Card Handbook" (1997), the contents of which are incorporated here as refer to.

For each smart card held by a consumer, it is desirable to maintain a substantially correct history of transaction information and applications associated with that smart card. In general, currently known systems are deficient in this respect in that they do not provide efficient and reliable means of ensuring synchronization between the information stored on the smart card and the corresponding information stored on one or more external databases. As a result, the current system cannot guarantee that lost or stolen cards can be reissued or replaced with up-to-date information.

In addition, the current system is also disadvantageous in that it generally does not allow enterprises such as common shareholders of the smart card (eg, Hertz, Hilton, etc.) to dynamically add or modify the application structure of the smart card. That is, in the case of multifunction cards, it is often not easy to change or add to the file structure of the card without engaging in a time consuming and costly reissue process.

Furthermore, generally known methods of issuing and reissuing smart cards in a multi-application, multi-enterprise environment are insufficient. In particular, smart cards typically encompass many different applications on a wide range of business organizations. For security purposes, it is advantageous to restrict writing, updating and reading of these files to specific parties according to a set of access condition rules. These access conditions are suitably implemented using encryption keys known only to the appropriate party, such as the enterprise. As a result, card issuers such as American Express typically do not have access to the keys needed to perform this function. Known systems have attempted to solve this problem by accumulating key data used in the issuance process in a central repository. This approach is unsatisfactory in many respects. Note that a breach in the security of the central repository of key information will have disastrous results.

Accordingly, there is a need for techniques that overcome these and other limitations of the prior art. More specifically, there is a need for a system that provides secure and efficient personalization and dynamic synchronization of multifunctional smart cards.

Contents of the invention

The present invention overcomes the limitations of the prior art by providing a method and apparatus for easy personalization and synchronization of smart card data in the context of a distributed transaction system.

According to one aspect of the present invention, a dynamic smart card synchronization system includes an access point (access point) configured to initiate a transaction in conjunction with a smart card, an enterprise data collection unit, and a card object database update system. An exemplary Dynamic Synchronization System (DSS) preferably includes various smart card access points, a secure support client server, a Card Object Database Update System (CODUS), one or more Enterprise Data Synchronization Interfaces (EDSI), an update logic system, one or more An enterprise data collection unit (EDCU) and one or more smart card access points that interoperably accept and interface with smart cards. In an exemplary embodiment, the DSS includes a personalization system and an account maintenance system configured in communication with CODUS.

In accordance with another aspect of the present invention, the personalization of a multifunction smart card is accomplished using a secure server configured to generate and/or retrieve encryption key information from multiple enterprise key systems during the final stages of the smart card issuance process .

Figure overview

The present invention will be described below in conjunction with the accompanying drawings, wherein the same reference numerals represent the same elements, and:

1 is a schematic diagram of an example dynamic synchronization system in accordance with aspects of the present invention;

Fig. 2 is the schematic diagram of the security support client server of example;

Fig. 3 is a schematic diagram of an example enterprise data synchronization interface;

Figure 4 is a schematic diagram of an example update logic system;

5 is a schematic diagram of an example enterprise data collection unit;

Fig. 6 is the schematic diagram of the Card Object Database Update System (CODUS) of example;

Figure 7 is a flowchart illustrating an example method of synchronizing pending transaction information;

Figure 8 is a flowchart illustrating an example synchronization method for updating transaction information;

Figure 9 is a schematic diagram of an example personalization system;

Figure 10 is a flowchart illustrating an example smart card personalization method; and

Figure 11 is an example transaction data structure suitable for use in a travel situation.

Preferred Embodiments of the Invention

A system according to aspects of the invention includes methods and apparatus for personalizing and dynamically synchronizing smart cards and associated databases in the case of a distributed transaction system. More specifically, referring now to FIG. 1 , an exemplary Dynamic Synchronization System (DSS) preferably includes a Security Support Client Server 104, a Card Object Database Update System 106 (CODUS), one or more Enterprise Data Synchronization Interfaces 108 (EDSI), Update logic system 110 , one or more enterprise data collection units 112 (EDCUs), and one or more smart card access points 102 that interoperably accept and interface with smart cards 120 are formed. In the exemplary embodiment, the DSS also suitably includes a personalization system 140 and an account maintenance system 142 configured in communication with CODUS 106.

More specifically, in a preferred embodiment, security support client server 104 is connected to EDSI 108 through enterprise network 114 via an appropriate network. EDSI 108 is linked to update logic system 110, which itself is coupled to enterprise data collection unit 112. Enterprise data collection unit 112 is coupled to CODUS 106 and security support client server 104 . In summary, each enterprise (e.g., airline shareholder, hotel shareholder, travel agency, etc.) is preferably associated with a corresponding EDSI 108, enterprise network 114, and EDCU 112, as described in more detail below. That is, EDCU 112(a) corresponds to EDSI 108(a) and enterprise network 114(a), EDCU 112(b) corresponds to EDSI 108(b) and enterprise network 114(b), and so on. A DSS may include any number of these functional blocks depending on the number of businesses represented.

Personalization system 140 suitably functions as an issuing source for smart card 120 . That is, the personalization system 140 creates and issues smart cards for use by consumers by providing a predetermined file structure loaded with initialization data (eg, account numbers, serial numbers, default preferences, and the like). Thus, the CODUS 106 interfaces with the personalization system 140 to facilitate reissuing the card by providing updated data in the event the card is damaged, lost or stolen. Personalization system 140 is described in detail below in conjunction with FIG. 9 .

The account maintenance system 142 is used for customer service purposes, therefore, it acts as an entry point for cardholder complaints, inquiries and other customer input. CODUS 106 communicates with account maintenance system 142 as appropriate to assist customer service representatives and/or automated systems in resolving cardholder issues.

smart card access point

The smart card access point 102 allows the cardholder to access the distributed transaction system through various means. These access points may include, for example, standard home phones, various PCS wireless systems, pay phones, palmtop computers, notebook computers, Internet workstations, automated teller machines (ATMs), point-of-sale terminals (POS), stand-alone kiosks, A network computer (NC), personal data assistant (PDA), or any other suitably configured communication device. Access points 102 may be portable (as is the case with PDAs and cellular phones) or centrally located (eg, in airline ticketing and entrance areas, taxi facilities, hotel lobbies, travel agencies, and shopping malls). In addition, a business may find it appropriate to have an access point 102 that streamlines business travel for its employees. In a preferred embodiment, the various access points 102 are configured to interface with contact-based smart cards 120 in accordance with relevant parts of the ISO-7816 standard.

Security Support Client Server

The security support client server 104 provides any functionality missing from the access points 102 used during the transaction, as appropriate. Server 104 also routes messages from access point 102 to the appropriate EDSI 108 and/or EDCU 112 as appropriate.

Referring now to FIGS. 1 and 2 , the example security support client server 104 includes a security engine 202 , supplemental application support 204 and router 206 . Security appliance 202 includes appropriate hardware and/or software to provide secure messaging between server 104, EDSU 112, and enterprise network 114. More specifically, security device 202 utilizes authentication, data encryption, and digital signature techniques in conjunction with incoming and outgoing message packets. In the context of the present invention, various conventional security algorithms are suitable including, for example, DES encryption, RSA authentication and various other symmetric and asymmetric encryption techniques.

Supplemental application support 204 preferably includes appropriate hardware and/or software components related to a particular access point 102 functionality. More specifically, server 104 suitably determines the nature of access point 102 utilized during the transaction. If the access point 102 does not include the appropriate software to carry out the requested transaction, the server 104 provides the functionality (i.e., software modules) with each EDSI 108 and/or EDCU 112 to complete the transaction. In particular, supplementary functionality includes software modules for the appropriate formatting of message packets sent via the various networks (including the DSS) (further detailed below). For example, when a transaction occurs via an access point 102 (which consists entirely of a stand-alone smart card reader), almost all functionality is provided by the server 104, since the smart card reader itself can only operate in a "dumb" manner. message to the smart card 102 in a manner. However, when access point 102 includes a suitably configured PC, various software modules located in the PC provide most of the necessary functionality. In this case, the server 104 only needs to deliver various message packets to the access point 102 without providing additional software. Added functionality may be provided by any suitable method, such as by using portable software code (eg, Java, ActiveX, etc.) or distributed software residing within access point 102, card 120, and/or server 104.

Router 206 routes messages to the relevant EDCU 112, enterprise network 114, and access point 102 as appropriate. That is, router 206 is configured to identify the relevant functional block within the DSS that a given message packet should be sent. Identification of relevant functional blocks can occur in a number of ways. In a preferred embodiment, identification is accomplished through the use of a look-up table that includes a list of relevant destinations keyed to information extracted from requests received from access point 102 .

In another embodiment of the present invention, the security support client server 104 is not used, and the functionality of the access point 102 is appropriately provisioned to eliminate the need for the server 104 . Alternatively, the functionality of the server 104 may be allocated and distributed among all components of the DSS in any advantageous manner.

Those skilled in the art will understand that the term "transaction" generally refers to transactions via a system for carrying out a specific goal (e.g., debit/charge authorization, preference change, reservation request, ticket request, etc.) Any message sent on. For example, Figure 11 shows an example transaction data structure useful in the context of an online transaction with travel agency shareholders, where field names 1102, data types 1104 ('C' for character), maximum byte length 1106 are listed in tabular form and description 1108. Although other data structures may be utilized, in this example, transaction messages suitably include comma-delimited data packets.

Card Object Database Update System (CODUS)

CODUS 106 suitably securely stores information related to the status of the various smart cards 120 issued. 1 and 6, in a preferred embodiment, CODUS 106 includes security device 602, data management module 604, card object database 116, card object supervision module 606 and audit (audit) file 608.

The security device 602 provides appropriate security for the information stored in the card object database 116 in particular. Accordingly, security device 602 may utilize various authentication, data encryption, and digital signature techniques in conjunction with incoming and outgoing message packets. For example, in the context of the present invention, suitable algorithms include DES encryption, RSA authentication, and various other symmetric and asymmetric encryption techniques.

Data management module 604 suitably functions as a data interface between CODUS 106 and account maintenance 142, and between CODUS 106 and the various EDCUs 112. More specifically, module 604 converts and translates the data formats used in these systems. For example, data stored within object database 106 may not necessarily be stored in a format that EDCU 112 or account maintenance 142 can easily use. Accordingly, the data management module 604 includes appropriate routines for performing conversion and formatting of incoming and outgoing data.

The card object administration module 606 preferably provides appropriate database software for editing, updating, deleting, synchronizing and ensuring that the data stored in the object database 106 is free from corruption. Various database packages are suitable for this task, including, for example, various conventional fourth-generation related database management systems (4GL RDBMS).

The audit file 608 properly tracks changes to the object database 116, thereby helping to ensure the integrity of the card data stored in the CODUS 106. More specifically, when changes to the object database 116 occur as a result of preference updates, transactions, application structure changes, and the like, the audit file 608 tracks appropriate messages about these changes, such as the time, date, and nature and content of the changes.

Card object database 116 may comprise a single database or a set of distributed databases that are used to store the known states of various smart cards 120 . In summary, the state of a smart card is characterized by an appropriate set of card flags. In a preferred embodiment utilizing a data structure according to ISO-7816, the card object database 116 stores the various applications (i.e., the entire file structure) that exist on the various smart cards 120 and the fields, directories, and information about the data. The file structure of the card object database 116 is chosen such that it includes the appropriate set of data fields for a given smart card 120 .

Enterprise data synchronization interface

In a preferred embodiment, the various EDSIs 108 track changes in smart card data and/or applications corresponding to various enterprises. 1 and 3, in a preferred embodiment, EDSI 108 includes a communication server 302, a security device 304 and a customer database 306.

Communication server 302 facilitates communications with enterprise network 114 and update logic system 110 as appropriate. Thus, server 302 is configured to translate between the various formats, media and communication protocols necessary given the particular choice of components used.

Security device 304 provides appropriate security measures with respect to access and storage of information in customer database 306 . In conjunction with incoming and outgoing message packets, security device 304 may utilize various authentication, data encryption, and digital signature techniques. For example, in the context of the present invention, suitable algorithms include DES encryption, RSA authentication, and various other symmetric and asymmetric encryption techniques.

Customer database 306 suitably provides means for storing smart card information about various shareholders or businesses. That is, a particular enterprise (hosting, eg, enterprise network 114a) may compile or hire others to compile smart card information that pertains only to that enterprise. For example, a hotel chain may store loyalty, preference, and other data pertaining specifically to that hotel chain. During synchronization (as described in further detail below), any changes to the database 306 will be propagated through the system, and vice versa, changes anywhere in the system will be transferred to the database 306 . This transfer is preferably made securely (using secure device 304) in conjunction with secure server 302.

In another embodiment, the functionality provided by the EDSI 108 is incorporated into a corresponding EDCU 112. That is, while the illustrated embodiment utilizes one or more EDSI 108 that are essentially separate, it may be advantageous to streamline the DSS by combining this functionality into a corresponding EDCU 112 functional block.

update logic system

In a preferred embodiment, update logic system 110 formats and securely routes card data received from and sent to EDCU 112 and EDSI 108. Referring now to FIG. 4 , in a preferred embodiment, update logic system 110 includes logic appliance 402 , data management module 404 , security appliance 406 , enterprise update supervisor 408 and enterprise update audit module 410 .

The logic device 402 suitably functions to direct and distribute information changes through the system. Thus, logic device 402 can determine which modules (i.e., which EDCUs 112 and EDSIs 108) need to reflect the change.

Data management module 404 suitably functions as a data interface between EDSI 108 and EDCU 112. More specifically, module 404 is capable of converting and translating between data formats used in these systems. Accordingly, the data management module 604 includes appropriate routines for performing the conversion and formatting of incoming and outgoing data.

Safeguards 406 are used to provide appropriate safeguards with respect to data flowing through update logic system 110 . In conjunction with incoming and outgoing message packets, security device 406 may utilize various authentication, data encryption, and digital signature techniques. For example, in the context of the present invention, suitable algorithms include DES encryption, RSA authentication, and various other symmetric and asymmetric encryption techniques.

Enterprise Update Supervisor 408 suitably includes overhead software needed to maintain data transfer between EDSI 108 and EDCU 112.

The enterprise update audit module 410 appropriately tracks update information flowing through the update logic system 110 . In particular, as information is communicated through the update logic system 110 (as a result of preference updates, transactions, application structure changes, and the like), the audit module 410 tracks appropriate labeling of that information, such as the time, date, nature, and content of that communication .

Enterprise Data Collection Unit

EDCU 112 preferably stores and coordinates the transfer of synchronization data corresponding to a particular enterprise. 5, in a preferred embodiment, the enterprise data collection unit 112 includes a security device 508, a customer update transaction database 504, a customer loyalty transaction database 510, a customer pending transaction database 514, an update database 502, an EDCU audit file 506, EDCU regulatory files 512 and EDCU data management module 516 .

Safeguard 508 is used to provide appropriate security measures with respect to data flowing through EDCU 112. In conjunction with incoming and outgoing message packets, security device 406 may utilize various authentication, data encryption, and digital signature techniques. For example, in the context of the present invention, suitable algorithms include DES encryption, RSA authentication, and various other conventional encryption techniques, both symmetric and asymmetric.

The customer update transaction database 504 is used to store updated information on the smart card 120, but this information has not yet propagated to various databases and networks that need to be updated. For example, smart card 120 may be used to change the cardholder's preferences during a transaction with a particular business. Briefly, this information is stored in a database 504 (corresponding to a particular enterprise) until it can be disseminated to CODUS 106 and EDCU 112 and EDSI 108 as appropriate. This transaction type is described in further detail below.

Customer loyalty transaction database 510 is suitably used to store loyalty information about a particular business or shareholder (eg, frequent fliers, frequent stayers, etc.). In another embodiment, the loyalty transaction database 510 is not used - instead the functionality of the database 510 is incorporated into the databases 502, 510 and 514 so that the loyalty transaction becomes another form of transaction tracked by the EDCU 112.

The customer pending transactions database 514 is suitably used to store information about transactions that have occurred without direct use of the smart card 120 . In particular, cardholders may initiate transactions such as preference changes and the like through channels that do not involve use of the card (eg, through verbal requests via standard telephone calls). In this case, this data is suitably stored in pending transactions database 514, as described in further detail below. This transaction data is retained in the database 514 until the corresponding smart card 120 is used in conjunction with the access point 120, at which point the smart card 120 itself (and CODUS 106) is updated with this new information.

The update database 502 is suitably used to store other types of transactions, ie transactions that cannot be classified as updated, loyal or pending. For example, as described in detail below, update database 502 may be utilized to store file structure updates.

Audit files 506 are used to track changes made to update database 504, pending database 514, database 502, and faithful database 510 (in the example embodiment). In another embodiment that does not use a separate faithful database 510 , audit file 506 tracks changes made to databases 504 , 514 , and 502 . Therefore, auditing files 506 helps to ensure the integrity of the data in each file.

Regulatory files 512 provide the appropriate database software needed to edit, update, delete, synchronize, and keep data stored within the various databases (including EDCU 112 - i.e., databases 502, 504, 510, and 514) from being corrupted.

Data management module 516 provides data management capabilities to facilitate data transfer between smart card 120 and databases 504, 514, 502, and 510, and between these databases and other systems (i.e., update logic system 110 and CODUS 106). Therefore, the data management module 516 acts as an interface to ensure the seamless transfer of data between systems.

network

The various components, databases, modules and devices described above in connection with the preferred embodiments are connected via appropriate data communication networks. Such a network may consist of various physical connections using various conventional data protocols (eg, TCP/IP protocol). It should be understood that the various connections between the system components may be different. For example, a wireless PCS network can be utilized from the access point 102 to the security support client server 104, while an Internet TCP/IP connection can be utilized from the CODUS 106 to each EDCU 112.

Those skilled in the art will appreciate that various hardware systems are suitable for implementing the invention. Various modems, routers, CPUs, monitors, backup systems, power supplies and peripherals can be utilized to achieve the objects of the present invention. For example, in one embodiment, secure support client server 104 is implemented using a Compaq Prolinea computer operating in an OS/2 environment using IBM MQ Server software, where each access point comprises a stand-alone smart card kiosk, running appropriate database software EDCU 112 and CODUS 116 are implemented on Compaq Prolinea computers operating in the Windows/NT environment of the package.

personalization system

Referring now to FIG. 9, in a preferred embodiment, the personalization system 140 suitably includes a card management system 902, a legacy management system 904, a collection application module 906, one or more databases 910, an activation block 908, a public Card personalization utility (utility) 912 (CCP), service bureau 914, public card security server 916, key management system 918 and one or more key systems 920. Key management system 918 suitably includes database module 922 , CID replacement module 924 , key system 926 and key system 928 .

CCP 912 suitably communicates with CODUS 106 (as shown in FIG. 1 ), and estate management system 904 suitably communicates with account maintenance 142, which also constitutes communication with CODUS 106.

The card management system 902 appropriately receives the card request 901 and initiates the collection of information from various sources. In general, card request 901 is composed of various request information specifying a desired set of card characteristics. For example, such characteristics may include: a list of desired applications (airlines, hotels, taxis, etc.); an indication of whether the card is new or reissued or replaced; a default card member preference corresponding to the desired application; A list of options; personal information about the card member (name, address, etc.); and desired security level.

The card management system 902 analyzes the card request appropriately and sends a request to the legacy card management system 904 for information that has been stored by the issuer. For information that cannot be used as legacy data, the card management system 902 sends the relevant components of the card request 901 to the collection application module 906 . In an example embodiment, the card management system 902 selects the best smart card physical characteristics for a particular card request 901 . That is, the card management system 902 appropriately determines the appropriate type of smart card chip to use based on factors such as the memory requirements and computational complexity of the desired security function. Similarly, an optimal Smart Card Operating System (SCOS) can be selected. In another embodiment, the smart card chip, operating system, etc. are specified in the card request 901 .

The legacy management system 904 serves as a suitable repository for information about the cardholder's past relationship (if any) with the card issuing organization. For example, a cardholder may have a long-term debit or credit account with the issuing organization (based on a standard imprinted magnetic stripe card), and this information may be advantageously incorporated into the issued card.

Collect application module 906 is suitably configured to receive information from card management system 902 and legacy management system 904 and then interface with respective databases 910 to collect all remaining application information specified in card request 901 . Preferably, database 910 corresponds to and is associated with each partner enterprise (eg, enterprise network 114 in FIG. 1 ) that provides smart card applications for use in smart card 120 . Thus, for example, a card request 901 that includes a hotel application request will trigger the collection application 906 to initiate a data communication with the appropriate hotel database 910 . The hotel database 910 will then return information specifying the correct file structure, access conditions (security), default values, and other data required to make up the smart card 120 with the requested application. Communication with the various databases 910 may be accomplished by any suitable means, for example, by data communication via the Internet, PSTN, etc., or by other channels such as simple telephone requests.

The activation block 908 is suitably used to provide a means for the card member to activate the card upon issuance. For example, cards such as credit cards to be sent to card members who have not been activated have in common that they require the card member to invoke (or contact) an automated system at the issuer in order to activate the card. This is usually accomplished by entering the card number and other appropriate ID using a touch-tone telephone. In this regard, use of the activation block 908 facilitates the function of the requested smart card by specifying whether or not this activation is required for a particular card.

Use the CCP 912 to generate an accurately formatted card "object" (i.e., the operating system, file structure, and all other available card data to be downloaded to the card 120), and then pass this information to the service bureau 914 (for creating smart card) and CODUS 116 (for recording the status of the issued card). The CCP 912 is preferably configured to match the format of the card object with the particular card issuing system (described below) to be used. Thus, the collection application system 906 can communicate a relatively high-level function request, and the CCP 912 can create specific "objects" for use in the implementation.

Personalization Service Bureau 914 includes the appropriate hardware and software components to complete the production of smart cards issued to card members. To this end, the service bureau 914 includes an appropriate smart card "printer" to handle the transfer of information to the smart card chip and any conventional embossing or magnetic stripe writing that may occur. For example, suitable smart card printers include any of the 9000 Series and 150i Series Smart Card Issuance Systems manufactured by Datacard Corporation of Minnesota, Minnesota.

The Common Card Security Server 916 (CCSS) suitably includes the software and hardware components required to retrieve encryption key information from the various enterprise key systems 920 . In an example embodiment, the service bureau 914 accesses this information to complete the personalization process. More specifically, it is often the case that smart card 120 encompasses many different applications relevant to a wide range of enterprise organizations. Those skilled in the art will appreciate that writing, updating and reading of these files are advantageously restricted to specific users according to a set of access condition rules. These access conditions are appropriately implemented using encryption keys known to the relevant user. Thus, the service bureau 914 (whose task is to create and provide the card file structure) cannot use the key required to perform this function from the beginning. As mentioned above, known systems have attempted to solve this problem by accumulating in a central repository the key data used in the issuance process, thereby creating an unacceptable security risk. However, the method according to the present invention allows communication between the smart card and each key system 920 at the time of card issuance, which in turn allows secure downloading of key information to the smart card without third party intervention. Using the CCSS 916, by receiving from the CCP 912 the identities of the various applications to be generated in each card, and then contacting the appropriate key system 920 when prompted by the service bureau 914 (or, prior to issuance by the service bureau 914) To request a key that will be sent to the service bureau 914 during personalization, thereby facilitating the process.

Key system 920 includes an appropriate database system capable of storing, generating, and securely distributing encryption keys associated with a particular enterprise. Depending on the context, key management system 918 is a system equivalent to key system 920, but is "owned" by the party implementing the personalization system. Key generation functionality may be distributed between CCSS and key system 920 . That is, keys may be generated in real-time at CCSS 916 (according to algorithm and key information received from a particular enterprise), rather than at key system 920.

Those skilled in the art will appreciate that various off-the-shelf and/or customer-developed hardware and software components can be used to implement the functional blocks shown in FIG. 9 . Database enhancement functions such as those performed by card management system 902 may be implemented using any suitable database package such as Codebase, dbase, or the like.

personalization process

A personalization system as described above in connection with FIG. 9 is suitably used to efficiently issue a large number of smart cards with a wide range of functional levels. This task involves obtaining and reconciling in a timely manner accurate data on each card member of each partnership supported by the system. Therefore, certain partnerships may want to limit the dissemination of proprietary data. This data may include, for example, private keys used in conjunction with smart card access conditions as well as file structures and card member personal data.

Referring now to Figures 9 and 10, an example smart card personalization process will be described. First, in step 1002, the system receives a smart card request. As described above, the card management system 902 is suitably used to receive card requests and initiate collection of information from various sources. The card request 901 suitably consists of request information specifying the desired set of card features. For example, these features may include: a list of desired applications (airlines, hotels, taxis, etc.); an indication of whether the card is new or reissued or replaced; default card member preferences corresponding to desired applications list; personal information about card members (name, address, etc.); and required security level.

Next, at step 1004, the system selects the smart card type and configuration applicable to the given card request 901. This step is suitably performed by the card management system 902 . Thus, the card management system 902 checks a number of factors (eg, memory requirements, desired security features, and the like) according to the information received in the card request 901, and then selects the appropriate smart card chip from the library of existing chips. Likewise, the optimal Smart Card Operating System (SCOS) can also be selected.

In step 1006, card member information is obtained. This step is suitably performed by collection application module 906 operating in conjunction with database 910 and loyalty management system 904 . More specifically, card member-specific information is preferably divided into two categories: information known to the personalization system and information unknown to the personalization system. Known information generally includes data obtained through past relationships with the organization hosting the personalization system. In this case, like some application data, it will most likely be certain data such as cardholder name, preferred billing address, title, company, etc. that are known. Such information is suitably stored in one or more databases (including loyalty management system 904), and may also be retrieved from such databases. As part of step 1006, the system (specifically, module 908) preferably determines whether the card requires activation. That is, as noted above, typically a label or the like is added to the card to notify the card member that the card requires activation before use. Activation usually involves the use of an automated telephone system. The choice as to whether a particular card requires activation may be based on many factors, such as demographics, crime rate figures, or postal fraud statistics regarding the zip code numbers of card members.

For data not contained in the loyalty management system 904 , the collection application module 906 communicates with the database 910 as appropriate to retrieve the information needed to satisfy the card request 901 . This information typically consists of file structure information (eg, DF and EF hierarchies), data type and length, and access condition specification for specific enterprise-sponsored applications. For example, where the card request 901 includes a request for an airline application, the collect application module 906 will contact the database corresponding to the enterprise hosting the airline application and then download all required file structure information. This process will continue for each new or modified application to be loaded into the smart card.

In step 1008, the CCP 912 is suitably used to generate a complete set of card member data. This data set or "card object" will eventually be used by the service bureau 914 to generate the actual smart card. The form of the card object can vary. In one embodiment, the card objects comprise objects known as binary large objects ("BLOBs"). Preferably, the card object is associated with the selected smart card configuration (e.g., chip type and operating system as specified in step 1004), the contents of the card member information data (collected in step 1006), and the predetermined smart card "printer" ( That is, the equipment used to produce the completed card within the service bureau 914) cooperates. In the above steps the system is made to specify the file structure, data types, etc., without itself having to do with how the structure is encoded onto the smart card or how the data is accessed. Until step 1008, the system need only develop a relatively high-level model of predetermined smart card data structures; with the exception of CCP 912, these specifications are essentially invisible.

In another embodiment, various details of the smart card data object may be determined at a previous point in the system. That is, the functions of the CCP 912 can be distributed among the various components of the system.

In step 1008, the card member data set or card object has been generated, and then this data is sent to CODUS 106 (step 1010). This ensures that the DSS (and especially the CODUS 106) has a record of the status of the smart card at the time of personalization. This information is then immediately available to account maintenance system 142 .

Then, send card object to service bureau 914 and (if required) CCSS 916 (step 1012). At step 1014, the required keys are obtained to allow the service bureau 914 to produce the completed smart card. As noted above, step 1014 is performed by CCSS 916 either concurrently or serially with the issuance process. In one embodiment, when each card is generated using an issuance system suitably located at the service bureau 914, the service bureau 914 queries the CCSS 916 for the relevant encryption key. These keys were previously (ie, after step 1012 ) retrieved from key systems 920 and 918 or in real time in response to a request from service bureau 914 . Alternatively, the key can be retrieved by the CCSS 916 and sent to the CCP 912 before the card object is sent to the service bureau 914. In either case, the one or more keys are then retrieved for inclusion in the card object generated in step 1008 .

At step 1016, the actual card is issued. The service bureau 914 properly downloads the card object into the correct card hardware using the correct encryption key. Then, the initialized smart card is packaged and issued to relevant card members according to conventional methods.

synchronization process

The "state" of the consumer's smart card is tracked using the dynamic synchronization system described above in various embodiments. The state of the smart card is properly characterized by the structure of the applications used in the smart card and the pieces of data stored in these applications.

The way applications and data are managed within a smart card can vary. For example, data files and directories may be stored in the smart card 120 in a "tree-like" structure. That is, the smart card file structure is suitably similar to the well-known MS-DOS (Microsoft Disk Operating System) file structure, where files are logically organized in a directory hierarchy. Specifically, three types of files are defined in ISO 7816-4: Dedicated File (DF), Elementary File (EF), and Master File (MF). The main file is similar to the MS-DOS "root" directory and contains all other files and directories. Dedicated files are actually directories or "folders" that hold other DFs or EFs. Thus, a MF may contain any number of DFs, which may or may not contain other DFs. Base files are used to store user data, and they can exist in dedicated files or in master files. Higher level DFs (ie, DFs that store specific applications) are often called Application Specific Files (ADFs). However, the scope of the present invention is not limited to this type of multifunction card. Other implementations such as Multos or Java-based cards are also suitable in the context of the present invention.

Many simultaneous issuances can occur in the case of a multifunctional smart card; in fact, three exemplary cases reoccur with some frequency, involving: 1) update transactions, 2) pending transactions, and 3) file structure changes. Each of these three cases will now be described in turn in accordance with the present invention.

Example 1: Update transaction

Cardholders typically make local changes to the smart card 120 that are not immediately reflected in all databases that could benefit from this information. For example, assume that at initialization time (i.e., when the card is initially issued by the personalization system 140), the cardholder's smart card 120 will be configured to reflect general preferences for smoking (e.g., a file containing Boolean field), but the cardholder now wishes to change this general preference to reflect the no-smoking preference.

Therefore, referring now to Fig. 1,7 according to a preferred embodiment of the present invention, the cardholder suitably inserts the card 120 into the conventionally positioned access point 102 where authentication of the card and/or card reader is performed (step 802 ). In a preferred embodiment, verification is performed according to the relevant chapters of the ISO 7816 standard.

The cardholder then uses the appropriate user interface (provided by the access point 102 working in conjunction with the server 104) to conduct the transaction—ie, request a change to the preferences file (step 804). This change is usually reflected on the smart card 120 immediately. That is, access point 102 and/or server 104 will include the functionality required to access and update relevant files within smart card 120 .

Communication router 206 in server 104 then routes the transaction to the party concerned, EDSI 108 or EDCU 112, corresponding to branches 807 and 812, respectively. That is, depending on the system configuration, the files to be changed may be related to a specific enterprise, or the files to be changed may be related to the organization in charge of the DSS. These two cases are described in turn.

Along branch 807 in Figure 8, the change data is sent to the relevant EDSI 108 and stored therein (step 808). The update logic system 110 then communicates this change request to the appropriate EDCU 112—that is, the EDCU 112 corresponding to the particular EDSI (step 810). This information is stored in a corresponding update database 504 as appropriate. This information is also distributed to other EDSIs. In this example, update logic system 110 will identify those systems that would benefit from knowing the cardholder's smoking status. These systems may include, for example, various hotels, taxi agencies, and the like.

Alternatively, following branch 805 in FIG. 8, the data may first be stored at the appropriate EDCU (step 812) and then distributed to other EDCUs 112 and EDSIs 108 as described above.

The card data change is then passed to CODUS 106. Specifically, various fields and files associated with the smart card 120 are updated to reflect the changes stored in the update database 504 . Thus, the information within CODUS 106 is consistent with the information contained in smart card 120 and each of EDCU 112 and EDSI 108. After this transfer, the corresponding changes in the update database 504 are purged (step 818).

Example 2: Pending Transactions

Cardholders may make changes or perform transactions through channels that do not directly involve the smart card 120, creating inconsistencies between the data in the smart card 120 and the data in the various databases throughout the DSS. Such a situation may occur, for example, when the cardholder calls the hotel to make a reservation (instead of using the smart card 120 to perform the transaction online) and verbally requests to change his preference from smoking to non-smoking.

Referring now to Figures 1 and 7, in this case, with respect to a preferred embodiment of the present invention, the cardholder first contacts an enterprise through a device that does not include the smart card 120 - i.e., a "no smart card" transaction (step 702) . Using the appropriate interface (voice, keypad, etc.), select Change or Transaction (step 704). This change is then stored locally within a particular enterprise network 114 and/or within the EDSI 108 (step 706).

Next, in step 708, the update logic system 110 routes the information to the corresponding EDCU 112 located in the pending database 514. At this point, the smart card 120 itself forgets about this change. As a result, if a cardholder initiates a transaction with a smart card, the corresponding enterprise may first notice the preferences in the smart card 120 data structure, and as noted above, the enterprise may very well draw the wrong conclusion (e.g., regardless of the cardholder's It is still possible to assign smoking rooms according to the preferences indicated).

To remedy this situation, the present invention provides a method in steps 710-712 by which the smart card is updated the next time the smart card is used. That is, after inserting the smart card into the access point 102 and performing the relevant authentication (step 710), the system queries the pending database 514 to determine whether any changes have been made. If there are changes, the relevant information is downloaded to the smart card 120 (step 712).

After successfully completing the above information delivery, the change data is delivered to CODUS 106, and CODUS 106 stores the information in the card object database 116. Finally, all information in the pending database 514 is cleared (step 716).

Example 3: File Structure/Apply Changes

In addition to the modifications described above with respect to data, it may also be desirable to change the structure of the data stored in the smart card 120 in certain circumstances. That is, during the life of the smart card, the issuer of the card, a partnership or the cardholder themselves may want to extend the functionality of the card by adding the set of applications contained within the card. For example, a cardholder who uses a smart card for taxi and airline reservations may also wish to use the card to acquire and pay for hotel reservations. In this case, the relevant hotel shareholder can process the cardholder's request and arrange for the hotel application to be added to be added to the smart card's file structure. In another example, the issuer of the smart card may authorize the unsolicited addition of a new application, such as a debit and/or credit application. Conversely, in some cases it may also be appropriate to remove certain applications from the card.

In a preferred embodiment, the type of file structure change described above can be manipulated in a manner similar to the process shown in FIG. 7, depending to some extent on which party proposed the file structure change. That is, as in step 712, relevant file structure change information may be stored in the EDCU 112 (e.g., in the database 502), and then passed to the smart card 120 when the card is used in conjunction with an online transaction (steps 710 and 712). After adding or modifying the file structure on smart card 120, CODUS 106 (specifically, database 116) is similarly modified to reflect this change. Then, the change information is cleared from the database 502 (step 716).

Although the present invention is described herein with reference to the accompanying drawings, those skilled in the art will understand that the scope of the present invention is not limited thereto. Changes may be made in the selection, design and arrangement of the various components and steps discussed herein without departing from the scope of the invention as set forth in the appended claims.

Claims (11)

1. A system for personalizing a smart card, wherein said smart card includes a card object having at least one application, said system comprising: security server; at least one key system associated with said at least one application, said key system configured to communicate with said security server and provide keys in response to a request from said security server; a personalization utility configured to receive said card object and communicate with said secure server; The personalization utility is further configured to add the key to the card object. 2. A system for dynamically synchronizing smart card information about smart cards, said system comprising: an enterprise data collection unit configured to store updated transactions and pending transactions with respect to said smart card; at least one access point configured to interface with said smart card and said enterprise data collection unit; A card object database system, coupled to said enterprise data collection unit, configured to store said smart card information in accordance with said update transaction and said pending transaction. 3. The system of claim 1, further comprising a card management system configured to accept card requests and communicate said card requests to said personalization utility. 4. The system according to claim 3, further comprising a collection application module configured to communicate with the card management system and collect application information from at least one database according to the card request. 5. The system of claim 1, further comprising a service bureau configured to communicate with said personalization utility and said security server to generate a smart card. 6. The system of claim 1, further comprising an activation block configured to determine whether the smart card requires activation by the cardholder. 7. The system of claim 4, further comprising a loyalty management system configured to communicate with the card management system and to send loyalty data to the collection application module in response to the card request . 8. The system of claim 1, further comprising a card object database update system configured to communicate with said personalization utility and store said card objects associated with said smart card. 9. The system of claim 2, further comprising an update logic system coupled to at least one enterprise data synchronization interface, the update logic system configured between the enterprise data synchronization interface and the enterprise data collection unit securely routing card information between, said enterprise data synchronization interface coupled to an enterprise network that constitutes communication with said access point. 10. The system according to claim 9, further comprising a security support client server configured to communicate with the access point, and the security support client server is also configured to adaptively communicate with the existing communication function of the access point Provides communication functions. 11. An integrated smart card system for managing personalization and synchronization of a smart card, wherein said smart card comprises a card object having at least one application, said system comprising: security server; at least one key system associated with said at least one application, said key system configured to communicate with said security server and provide keys in response to a request from said security server; a personalization utility configured to receive said card object and communicate with said secure server; said personalization utility is further configured to add said key to said card object; a card object database update system configured to communicate with said personalization utility and store said card objects related to said smart card; an enterprise data collection unit configured to store updated transactions and pending transactions related to said smart card, said enterprise data collection unit configured to communicate with said card object database update system; At least one access point configured to interface with said smart card and said enterprise data collection unit.

Images