MXPA00010766A - Methods and apparatus for dynamic smartcard synchronization and personalization - Google Patents

Abstract

A system for personalizing and synchronizing smartcard data within a distributed transaction system includes smartcard access points (102) which initiate transactions with smartcards (120), one or more enterprise data collection units (112), a secure 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 multifunction smartcards is accomplished using a security server configured to generate and/or retrieve cryptographic key information from multiple enterprise key systems during the final phase of the smartcard issuance process.

Description

METHODS AND DEVICES FOR SYNCHRONIZATION AND INTELLIGENT DYNAMIC CHARACTERIZATION DESCRIPTION OF THE INVENTION The present invention is generally related to the use of cards with integrated circuits ("smart cards") for business operations and, more particularly, with techniques for dynamically synchronizing and customizing smart card information in the context of a distributed trading system. Recent advances in Internet commerce, electronic data processing, and semiconductor device technology have led to an increase in the interest of smart card technology. Generally speaking, smart cards are wallet-sized (or smaller) cards that incorporate a microprocessor or microcontroller to store and manage data within the card. Being more complex than stored value and magnetic stripe cards, smart cards are characterized by sophisticated security features and memory management. Cards with multiple functions, for example, are very often set up for credit, debit, stored value, loyalty support, and a number of other applications all within a single card. A typical multifunction smart card includes a microcontroller embedded within the plastic of the card, which is electrically connected to a range of extreme contacts provided on the outside of the card. The microcontroller of the smart card generally includes a read-only memory that can be programmed and electrically erased (EEPROM) to store user data, a random access memory (RAM) for improvised storage, and a memory of Read only (ROM) to store the operating system of the card. Relatively simple microcontrollers are adequate to control these functions. Thus, it is not unusual for smart cards to use 8-bit, 5 MHz microcontrollers with approximately 8K of EEPROM memory (for example, Motorola 6805 or Intel 8051 microcontrollers). A number of standards have been developed to address various aspects of cards with integrated circuits, for example ISO 1816-1, Part 1: Physical characteristics (1987); ISO 7816-2, Part 2: Dimensions and locations of the contacts (1988); ISO 7816-3, Part 3: Electronics Signals and Transmission Protocols (1989, Amd. 1 1992, Amd. 2 1994); ISO 7816-4, Part 4: Inter-industry commands for interchange (1995); ISO 7816-5, Part 5: Numbering system and registration procedure for application identifiers (1994, Amd. 1 1995); ISO / IEC DIS 7816-6, Inter-industry data elements (1 995); ISO / IEC WD 781 6-7, Part 7: Enhanced inter-industry commands (1995); and ISO / IEC WD 781 6-8, Part 8: Inter-industry securi ty archi tecture (1995). These standards are incorporated herein by reference. In addition, general information regarding cards with magnetic strips and cards with chips can be found in a number of standard texts, for example, Zoreda & Otón, Smart Cards (1994), and Rankl & Effing, Smart Card Handbook (1997), whose contents are incorporated herein by reference. It is desirable to maintain, for each smart card carried by a consumer, a substantially accurate history of information on operations and applications associated with the smart card. Currently known systems are typically unsuitable in this respect because they do not provide efficient and reliable methods to ensure synchronization between the information stored in the smart card and the corresponding information stored in one or more external databases. As a result, current systems do not ensure that lost or stolen cards can be re-shipped or replaced with updated information. On the other hand, current systems are inadequate because systems very often do not allow a company, as a corporate partner of the smart card (for example, Hertz, Hilton and the like) dynamically adds or otherwise modifies the application structure of the smart card itself. This is in the context, the multifunctional cards very often it is impossible to alter or increase the file structure of the card without engaging in a process that takes time and costly to re-issue the card. In addition, the known methods for issuing and reissuing smart cards in a multiple application, multiple environments are typically inadequate. More particularly, a smart card very often contains a number of different applications associated with a wide range of business organizations. For security purposes, the writing, updating, and reading of these files is advantageously restricted to individuals according to a set of access conditions rules. These access conditions are properly implemented using cryptographic keys that are known only by the appropriate person such as the company. In this way, a person who issues a card such as American Express will typically not have access to the keys necessary to perform its function. The known systems have tried to solve this problem by accumulating the key data in a central repository used in the dispatch process. This method is unsatisfactory in many respects. Most notably, the lack of security in the central repository of key information would have disastrous consequences. Therefore techniques are needed to solve these and other limitations of the prior art. More specifically, systems are needed to provide dynamic synchronization and secure and efficient personalization of smart cards with multiple functions. The present invention overcomes the limitations of the prior art by providing methods and apparatus for customizing and synchronizing smart card data in the context of a distributed transaction system. In accordance with one aspect of the present invention, a dynamic smart card synchronization system comprises access points configured to initiate an operation together with a smart card, an enterprise data collection unit, and a database update system of object card. An exemplary dynamic synchronization system (DSS) preferably comprises several smart card access points, a customer insurance support server, an object card database update system (CODUS), one or more synchronization interfaces enterprise data (EDSI), a logical update system, one or more enterprise data collector units (EDCUs), and one or more smart card access points configured to interoperably accept the interface with the smart cards. In an exemplary embodiment, the DSS comprises a personalization system and an account maintenance system configured to communicate with the CODUS. According to another aspect of the present invention, the personalization of smart cards with multiple functions is achieved by using a security server configured to generate and / or retrieve key cryptographic information from multiple business key systems during the final phase of the card issuing process. intelligent . BRIEF DESCRIPTION OF THE DRAWINGS The present invention will hereinafter be described in conjunction with the accompanying drawings, in which like reference numerals denote similar elements, and: FIGURE 1 is a schematic overview of an exemplary dynamic synchronization system of according to various aspects of the present invention; FIGURE 2 is a schematic overview of a customer insurance support server; FIGURE 3 is a schematic overview of an exemplary enterprise data synchronization interface; FIGURE 4 is a schematic overview of an exemplary update logic system; FIGURE 5 is a schematic overview of an exemplary business data collection unit; FIGURE 6 is a schematic overview of an exemplary object card database update system (CODUS); FIGURE 7 is a flowchart representing an exemplary method for synchronizing information on pending operations; FIGURE 8 is a flowchart representing an exemplary method for synchronizing updated operation information; FIGURE 9 is a schematic overview of an exemplary personalization system; FIGURE 10 is a flowchart representing an exemplary method of personalizing a smart card; and FIGURE 11 is an exemplary operations data structure suitable for use in a travel context. A system according to various aspects of the present invention includes methods and apparatuses for customizing and dynamically synchronizing smart cards and associated databases in the context of a distributed operations system. More particularly, referring now to FIGURE 1, preferably the exemplary dynamic synchronization system (DSS) comprises a customer insurance support server 104, an object card database update system 106 (CODUS), an or more enterprise data synchronization interfaces (EDSI) 108, a logical update system 110, one or more enterprise data collector units (EDCUs) 112, and one or more smart card access points 102 configured to interoperably accept the interface with smart cards 120. In an exemplary embodiment, the DSS also suitably comprises a personalization system 140 and an account maintenance system 142 configured to communicate with the CODUS 106. More particularly in a preferred embodiment, the server 104 support The client is securely supported in an adequate network to the EDSIs 108 through business networks 114. The EDSIs 108 are linked to the logical update system 110, which is linked to the enterprise data collector units 112. The business data collector units 112 are linked to the CODUS 106 and the customer insurance support server 104. In general, as will be described in detail below, each company (eg airline partner, hotel partner, travel agency, etc.) is preferably associated with a corresponding EDSI 108, a business network 114, and an EDCU 112. This is EDCU 112 (a) corresponds to EDSI 108 (b) and business network 114 (b), etc., etc. The DSS may include an arbitrary number of such functional blocks according to the number of companies represented. The personalization system 140 suitably functions as the source for issuing smart cards 120. That is, the personalization system 140 creates and issues smart cards that can be used by the consumer by providing a populated structure of predetermined files with initialization data (for example, example, account numbers, serial numbers, implicit preferences, and the like). In this regard, the CODUS 106 is interfaced with the personalization system 140 in order to facilitate re-issuing the card by providing updated data in case a card is destroyed, lost or stolen. The personalization system 140 is described in detail below along with FIGURE 9. The gutter maintenance system 142 is provided for customer service purposes and, in this capacity, acts as the entry point for the complaints., questions, and other customer issues of the cardholder. The CODUS 106 conveniently communicates with the account maintenance system 142 to assist customer service representatives and / or automated systems to handle issues related to the cardholder. Smart Card Access Points The smart card access points 102 allow the cardholder to access the distributed operating system through a variety of means. Such access points may include, for example, standard telephones, PCS wireless systems, public telephones, handheld computers, desktop computers, Internet stations, ATMs, points of independent kiosks of sales terminals (POS), network computers (NCs), personal data assistants (PDAs), or any other properly configured communication device. The access points 102 can be portable (as in the case of PDAs and cell phones) or centrally located, for example, in areas of rooms and ticketing of airlines, car rental facilities, hotel lobbies, agencies of travel, and shopping centers. In addition, businesses may see fit to have a point of access 102 to modernize their employees' business vials. In a preferred embodiment, several access points 102 are configured for the interface with contact-based smart cards 120 in accordance with the relevant portions of ISO-7816.

Customer Insurance Support Servers The customer insurance support server 104 provides, where appropriate, any function absent from the individual access point 102 used during an operation. The server 104 also suitably handles message routing from the access points 102 to the appropriate EDSI 108 and / or the EDCU 112. Referring now to FIGURES 1 and 2, an exemplary client insurance support server 104 comprises a security engine 202, a supplementary application support 204, and a router 206. Security engine 202 comprises hardware and / or software suitable for providing secure message delivery between server 104, EDSUs 112, or enterprise networks 114 . More specifically, the security engine 202 uses authentication techniques, data encryption, and digital signature, together with packets of input and output messages. A variety of security algorithms conventions are suitable in the context of the present invention, including, for example, DES encryption, RSA authentication, and a variety of other symmetric and non-symmetric cryptographic techniques. The supplementary application support 204 preferably comprises suitable hardware and software components related to a specific access point 102 functionality. More particularly, the server 104 suitably determines the nature of the access point 102 used during an operation. If the access point 102 does not include the appropriate software to perform the requested operation, then the server 104 supplies the functionality (i.e., software modules) which completes the operation with the EDSIs 108 and / or the respective EDCUs 112. The supplementary functionality includes, inter alia, software modules for properly formatting message packets (described in detail below), sent by various networks comprising the DSS. For example, where a transaction is carried out by means of an access point 102 which consists entirely of an independent smart card reader, almost all the functionality is provided by the server 104 because the smart card reader, by itself it is only capable of transferring messages to and from the smart card 102 in a "silent" manner. However, when a properly configured PC is included for access point 102, the most needed functionality is provided by several software modules that reside on the PC. In such a case, the server 104 only needs to transfer the different message packets to and from the access point 102 without supplying additional software. The added functionality may be provided through any suitable method, for example, through the use of a portable software code (for example Java, ActiveX, and the like), or a distributed software that resides within the access points 102. on cards 120, and / or server 104. Router 206 suitably handles routing of messages to appropriate EDCUs 112, business networks 114, and access pintos 102. That is, router 206 is configured to identify the functional blocks within the DSS to which a given message packet should be sent. The identification of the appropriate functional blocks can be carried out in different ways. In a preferred embodiment the identification is achieved through the use of a look-up table comprising a list of appropriate destinations with keys for the information extracted from the requests received from the access points 102. In an alternative embodiment of the present invention, a client insurance support server 104 is not used, and the functionality of the access points 102 is suitably specified to avoid the need for the server 104. Alternatively, the functions of the server 104 may be assigned and distributed through the DSS components in any advantageous manner. It will be appreciated by those skilled in the art that the term "operation" refers to, generally, to any message communicated by the system to accomplish a particular objective, for example, debit / charge authorization, preference changes, reservation requests, ticket requests, and the like. FIGURE 11, for example, shows an exemplary operations data structure useful in context to perform an online operation with a travel partner, wherein field member 1102, data type 1104 ('C for character) , maximum bit length 1106 and description 1108 are listed in a tabular form. In this example, the operation messages suitably comprise comma delimited data packets, although other data structures may also be employed. Object Card Database Update System (CODUS) The CODUS 106 appropriately and safely stores information related to the status of different issued smartcards 120. Referring now to FIGURES 1 and 6, in a preferred embodiment, the CODUS 106 comprises a security engine 602, a data handling module 604, an object card database 116, an object card management module 606 , and an audit file 608. The security engine 602 provides adequate security for, inter alia, the information stored within the database 116 of the object card. In this regard, the security engine 602 can use various authentication techniques, data encryption, and signature. digital together with packets of input and output messages. Suitable algorithms in the context of the present invention include, for example, DES encryption, RSA authentication, and a variety of other symmetric and non-symmetric cryptographic techniques. The data handling module 604 suitably acts as a data interface between the CODUS 106 and the account maintenance 142 as well as between the CODUS 106 and the different EDCUs 112. More specifically, the module 604 performs conversions and translations between the format of data used in these systems. For example, the data stored within the object database 106 may not be stored in a format that can be easily used by the EDCUs 112 or the account maintenance 142. Accordingly, the data handling module 604 comprises suitable routines for performing the conversion and formatting of both incoming and outgoing data. The card management module 606 preferably object provides a database software suitable for editing, updating, deleting, synchronizing and ensuring non-corruption of data stored within the database object 106, A variety of base packets of data are suitable for this task, including for example, different systems of management of relational database of the fourth generation conventional (4GL RDBMS). The audit file 608 suitably tracks the changes in the object database 116, thereby helping to ensure the integrity of the card data stored within the CODUS 106. More particularly, when changes are made to the database 116 object as a result of updates, operations, changes of application structure, preferably and the like, the audit file 608 tracks the appropriate information related to these changes, for example, time, date and nature and content of the change. The object card database 116, which may comprise a single database or a distributed database set, is used to store the known state of the different smart cards 120. In general, the state of a smart card is characterized by an appropriate set of card indications. In a preferred embodiment, where a data structure according to ISO-7816 is employed, the object card database 116 stores information related to the individual applications present in the different smart cards 120 (ie, the general file structure) as well as the individual fields, directories and data that comprise those applications. A file structure for the object card database 116 is chosen to include a suitable set of data field for a given smart card 120. Business Data Synchronization Interface In a preferred embodiment, the different EDSIs 108 track changes in the smart card data and / or the applications corresponding to the individual companies. With reference to FIGURES 1 and 3 in a preferred embodiment, the EDSI 108 comprises a communication server 302, a security engine 304, and a client database 306. The communication server 302 suitably facilitates communication with business networks 114 and logical update systems 110. In this regard, server 302 is configured to make translations between different formats, media and communication protocols as necessary given the particular choice of components employed. The security engine 304 provides adequate security measures with respect to accessing and storing information with the customer database 306. The security engine 304 can use various authentication techniques, data encryption, and digital signature in conjunction with incoming and outgoing message packets. Suitable algorithms in the context of the present invention include, for example, DES encryption, RSA authentication, and a variety of symmetric and non-symmetric cryptographic technical fillers. The client database 306 suitably provides a means to store smart card information related to individual partners or companies. That is, a particular company (hosting, for example, a 114 (a) business network) can compile, or employ others to compile, smart card information related only to that company. For example, a hotel chain can store loyalty, preference and other data specifically related to that hotel chain. During synchronization (as will be described in detail below, any changes to the database 306 would propagate through the system and vice versa, changes elsewhere in the system would be reported to the database 306. This communication is made from preferably in secure ways (using the security engine 304) in conjunction with the communication server 302. In an alternative mode, the functionality provided by the EDSIs 108 is duplicated in the corresponding EDCU 112. That is, while an illustrated mode employs one or more EDSIs 108 physically separated, it may be advantageous to further modernize the DSS by incorporating this functionality into the EDCU functional block 112 corresponding. Logical Update System In a preferred embodiment, the logical update system 110 formats and securely routes the card data received from and transmitted to the EDCUs 112 and the EDSIs 108. Referring now to FIGURE 4, in a preferred embodiment , the logical update system 110 includes a logic engine 402, a data management module 404, a security engine 406, a business update manager 408 and an enterprise update audit module 410. The logical engine 402 suitably functions to direct and distribute information changes through the system. In this way, the logic engine 402 is able to determine which modules (ie, which EDCUs 112 and EDSIs 108) need to reflect the change. The data handling module 404 suitably acts as the data interface between the EDSIs 108 and the EDCUs 112. More specifically, the module 404 is capable of converting and making translations between data formats used in these systems. Accordingly, the data handling module 604 comprises suitable routines for effecting the conversion and formatting of both the output and the input data.

The security engine 406 is used to provide adequate security measures with respect to data flowing through the logical update system 110. The security engine 406 can use various authentication techniques, data encryption and digital signature in conjunction with incoming and outgoing message packets. Suitable algorithms in the context of the present invention include, for example, DES encryption, RSA authentication, and a variety of other symmetric and non-symmetric cryptographic techniques. The business update administrator 408 suitably comprises elevated software necessary to maintain the data transfer between the EDSIs 108 and the EDCUs 112. The business update audit module 410 suitably tracks the update information flowing through the logical update system 110 . More particularly, when the information is communicated through the logical update system 110 (as a result of preference updates, operations, changes in the application structure, and the like), the audit module 410 tracks the appropriate indications of this information, for example, time, date and nature and content of the communication. Business Data Collection Unit The EDCUs 112 preferably store and coordinate the transfer of the synchronization data corresponding to a particular company. Referring to FIGURE 5, in a preferred embodiment, the business data gathering unit 112 includes a security engine 508, a refresh operations client database 504, a loyalty operations client database 510, a client database 514 of pending operations, an update database 502 and an EDCU audit file 506, an administrative EDCU file 512, and an EDCU data management module 516. The security engine 508 is used to provide adequate security measures with respect to data flowing through the EDCU 112. By this point, the security engine 406 can use various authentication techniques, data encryption and digital signature together with incoming and outgoing message packets. Suitable algorithms in the context of the present invention include, for example, DES encryption, RSA authentication, and a variety of other conventional symmetric and non-symmetric cryptographic techniques. The updating operations client database 504 is used to store information that has been updated in a smart card 120, for which it has not been propagated to the different databases and networks that require updating. For example, a smart card 120 may be used to change the preferences of the cardholder in the course of an operation with a particular company. This information would be, in the short term, stored in the 504 database (for the particular company) until it was ventilated to the CODUS 106 and the appropriate EDCUs 112 and EDSIs 108. This type of operation is described in detail later. The loyalty operations client database 510 is suitably used to store loyalty information (eg, frequent traveler, frequent guest, etc.) associated with a particular business or partner. In an alternative embodiment, a database of loyalty operations 510 is not used, instead, the functionality of the database 510 incorporates into the databases 502, 510 and 514 so that a loyalty operation becomes just in another mode of operation to be tracked by the EDCU 112. The client database 514 of pending operations is suitably used to store information related to the operations that have been carried out without the direct use of the smart card 120. More particularly, some transactions, such as changes of preference and the like, can be initiated by a cardholder through a channel that does not involve the use of the card. For example, through a verbal request through a standard telephone. In this case, and as will be detailed later, this data is stored properly in database 514 of pending operations. The operation data remains in the database 514 until the corresponding smart card 120 is used in conjunction with an access point 120, where the smart card 120 itself (like the CODUS 106) is updated with this new information. The updating database 502 is suitably used to store other types of operations, i.e., operations that can not be classified as update, loyalty or pending. For example, update database 502 can be used to store file structure updates as will be detailed later. The audit file 506 is used to track changes in the update database 504, the pending database 514, the database 502, and, in an illustrated embodiment, the loyalty database 510. In an alternative embodiment, where a separate loyalty database 510 is not used, the audit file 506 tracks the changes in the 504, 514 and 502 databases. The audit file 506 therefore helps to ensure the integrity of the data in the respective files. The administrative file 512 provides the appropriate database software necessary to edit, update, delete, synchronize and ensure non-corruption of data stored within the different databases comprising the EDCU 112, that is, the 502 databases , 504, 510 and 514. The data handling module 516 provides data handling capabilities to facilitate the transfer of data between smart cards 120 and 504, 514, 502 and 510 databases as well as between these databases and databases. the other systems, i.e., the logical update system 110 and the CODUS 106. In this way, the data handling module 516 acts as an interface to ensure a uniform transfer of data between the different systems. Network The different components, databases, modules and apparatuses described above in relation to the preferred embodiment are connected by means of a suitable data communications network. Said network may consist of several physical connections using a variety of conventional data protocols, for example, the TCP / IP protocol. It will be appreciated that the individual connections between the components of the present system may differ.

For example, a wireless PCS network can be employed from a point 102 for accessing the customer insurance support server 104, while a TCP / IP Internet connection can be used from CODUS 106 to several EDCUs 112. Those experts in the will appreciate that a variety of hardware systems are suitable for implementing the present invention. Various modems, routers, CPUs, monitors, backup systems, power supplies, and peripherals can be used to realize the benefits of the present invention. In one embodiment, for example, a Compaq Prolinea computer operating in an OS / 2 environment using IBM MQ Server software is used to implement the customer insurance support server 104, where the different access points comprise card kiosks independent smartphones, an EDCU 112 and a CODUS 116 are then implemented on a Compaq Prolinea computer that operates in a Windows / NT environment running an appropriate database software package. Personalization System Referring now to FIGURE 9, in a preferred embodiment, the personalization system 140 suitably comprises a card management system 902, a legacy management system 904, a meeting application module 906, one or more databases 910, an activation block 908, a common card personalization service 912 (CCP), a service office 914, a common card security server 916, a key management system 918, and one or more 920 key systems. The key management system 918 suitably comprises a database module 922, a CID replacement module 924, a key system 926, and a key system 928. The CCP 912 suitably communicates with the CODUS 106 (shown in FIGURE 1), and the legacy management system 904 appropriately communicates with the account maintenance 142 which is also configured to communicate with the CODUS 106. The system 902 of Card management properly receives the 901 card request and initiates the information meeting from various sources. Generally the card request 901 consists of different request information intended to specify a desired group of card characteristics. These characteristics may include, for example: a list of desired applications (airline, hotel, car rental, etc.); a designation of whether the card is new, a renewal or a replacement; a list of implicit preferences of the card member corresponding to the desired applications; personal information related to the card member (name, address, etc.); and security levels required. The card management system 902 suitably passes the card request, and, for the information already stored by the person issuing the card, an application is sent to the legacy card management system 904. For information not available as legacy data, the card management system 902 sends the relevant components of the card request 901 to the meeting application module 906. In an exemplary embodiment, the card management system 902 chooses the optimal physical characteristics of the smart card for a particular card request 901. That is, the card management system 902 suitably determines the appropriate type of smart card chip to be used according to a number of factors, for example, memory requirements and computational complexity of the desired security functions. In the same way you can choose the optimal operating system of the smart card (SCOS). In an alternative embodiment, the chip of the smart card, the operating system and the like are specified in the card request 901. The legacy management system 904 acts as an adequate repository of information related to the past relationship of the cardholder, if any, with the organization issuing the card. For example, a cardholder can have a large credit or due account with an organization that issues cards (based on a card with standard embedded magnetic stripe) and this information can be advantageously incorporated into the issued card. The meeting application module 906 is suitably configured to receive information from the card management system 902 and the legacy management system system 904 and then the interface with the different 910 databases to gather all the remaining application information specified. in card request 901. Preferably, the databases 910 correspond to and are associated with the companies of individual societies that offer smart card applications that are used in the smart cards 120 (for example, business networks 114 in FIGURE 1). Thus, for example, a card request 901 including a request for a hotel application could trigger the meeting application 906 to initiate data communication with the appropriate hotel database 910. The hotel database 910 would then return the information specifying the correct file structure, access conditions (security), implicit values, and other data necessary to configure the smart card 120 with the requested application. The communication with the different databases 910 can be carried out by any suitable means, for example, data communication over the Internet, PSTN, and the like, or through other channels, such as simple requests by telephone. Activation block 908 is suitably used to provide a means for the card member to activate the card once it has been issued. For example, it is common for credit cards and the like to be sent to the card member deactivated, requiring the card member to call (or otherwise contact) an automated system at the issuing location in order to activate the card. This is typically achieved by entering the card number and other suitable identification using a keypad. In this respect, the activation block 908 is used to facilitate this function for the requested smart card, that is, to specify whether said activation is necessary for a particular card. CCP 912 is used to create a properly formatted "object" card, that is, the operating system, file structure, and other card data available to be downloaded to card 120, then transfer this information to office 914 (to create the smart card) and CODUS 106 (to record the status of the card as it was issued). The reference CCP 912 is configured to adjust the format of the object card to the specific card issuing system to be used (which will be described later) in this way, the meeting application system 906 can supply a request for functionality with a relatively high level, and CCP 912 can create the specific "object" to be used in the implementation. Office 914 in customization service comprises hardware and software components suitable for completing the production of the smart cards for issuance to the respective card members. In this regard, the service office 914 includes a smart card "printer" suitable for handling the transfer of information to the smart card chip as well as any conventional engraving or magnetic strip writing that can be carried out. Similarly, smart card printers include, for example, any of the systems of the 9000 series and the 150i series of smart cards issued by Datacard Corporation of Minnetonka, MN. The common card security server 916 (CCSS) suitably comprises software and hardware components necessary to retrieve key cryptographic information from the different business key systems 920. In an exemplary mode, this information is accessed by the 914 service office in order to complete the customization process. More particularly, it is the particular case that a smart card 120 contains a number of different applications associated with a wide range of business organizations. Those skilled in the art will appreciate that the writing, updating and reading of these files is advantageously restricted to particular individuals according to a set of rules of access conditions. These access conditions are suitably implemented using cryptographic keys that are known to the right individual. In this way, the service office 914, whose task is to create and populate the card file structure, no, ab initio, will have access to the necessary keys to perform this function. As mentioned briefly above, known systems have attempted to solve this problem by accumulating key data in a central repository used in the issuance process, thereby creating an unacceptable security risk. The methods according to the present invention, however, allow communication between the smart card and the individual key systems 920 as the card is being issued, thereby allowing the key information to be safely downloaded to the card intelligent without the intervention of a third party. The CCSS 916 is properly used to facilitate this process by receiving information from CCP 912 regarding the identity of the different applications to be created on the different cards, then, when prompted by the 914 service office (or, alternatively, before the expedition by the 914 service office), contact the appropriate 920 system key to request a key to be transmitted to the 914 service office during the customization. The key systems 920 comprise suitable database systems capable of securely storing, generating and transmitting cryptographic keys associated with a particular enterprise. The key management system 918 is, in this context, a system that can be compared to key systems 920, but which "belongs" to the individual who implements the personalization system. The function that generates the key can be distributed between the CCSS and the key systems 920. That is, the keys can be generated in real time in the CCSS 916 (according to algorithms and key information received from the particular companies), instead of being generated in the key 920 systems. It should be appreciated by those skilled in the art that the functional blocks illustrated in FIGURE 9 can be implemented using a variety of hardware and software components, both custom developed and marketed. The intense database functions performed, for example, by the card management system 902, can be implemented using any suitable database package, for example, Codebase, dBase, or the like. Customization Process A personalization system as described above in conjunction with FIGURE 9 is used appropriately to efficiently issue a large number of smart cards with a wide range of functionality levels. This task involves obtaining and coordinating, in a timely manner, accurate data for individual card members through various partner companies supported by the system. In this respect, it could be the case that certain companies of companies wish to limit the decrease of property data. This data may include, for example, private keys used in conjunction with smart card access conditions as well as file structures and personal data of the card member. Referring now to FIGURES 9 and 10, an exemplary smart card personalization process will be described. First, in step 1002, the system receives a smart card request. As mentioned above, a card handling system 902 is suitably used to receive the card request and initiate the information gathering from various sources. The card request 901 suitably consists of requesting information that is intended to specify a desired group of card feature. These features may include, for example: A list of desired applications (airlines, hotel, car rental, etc.); a designation of whether the card is new, a renewal or a replacement; a list of implicit card member preferences that correspond to the desired applications, personal information related to the card member (name, address, etc.,); and security levels required, Next, in step 1004 the system selects the type of smart card and the appropriate configuration for the given card 901 request. This step is suitably carried out by means of the operating system 902. In this way, the card management system 902 examines a number of factors in light of the information received in the card request 901 (e.g., memory requirements, desired security functions, and the like), then selects a appropriate smart card chip from a library of available chips. In the same way, you can also select the operating system of the optimal smart card (SCOS). In step 1006, the information of the card member is obtained. This step is suitably performed by the meeting application module 906 which operates in conjunction with the databases 910 and the legacy management system 904. More particularly, the specific information of the card member is preferably classified into two groups: known information for the personalization system, information unknown by the personalization system. The information known generally consists of data acquired through a past relationship with the organization hosting the personalization system. In this case, certain information such as the name of the cardholder, the preferred address for charges, position, company, etc., will probably already be known, as well as certain application data. Said information is stored appropriately and can be retrieved from one or more databases comprising the legacy management system 904. As part of step 1006, the system (specifically, module 908) preferably determines whether the card should be activated. That is, as mentioned briefly above, it is common to apply a decal or the like to a card that notifies the card member that the activation of the card is required before its use. Activation typically involves the use of an automated telephone system). The choice of whether a particular card requires activation may be based on a number of factors, for example, demographics, crime rate figures, or mail fraud statistics associated with the card member's zip code number. For data not included in the legacy management system 904, the meeting application module 906 conveniently communicates with the databases 910 to retrieve the information necessary to satisfy the card requests 901. This information will typically consist of file structure information, for example, the DF and EF hierarchy, types and lengths of data, and access condition specifications for the particular application sponsored by the company. For example, in the case where the card request 901 includes a request for an airline application, the meeting application module 906 will contact the database corresponding to the company that hosts the airline application, then download all the information of file structure needed. This process will continue in turn for each new application or modified application to be incorporated in the smart card. In step 1008, a total card member data set is created, suitably using the CCP 912. This data set, or "object card", will eventually be used by the service office 914 to create the physical smart card. The shape of the object card may vary. In one embodiment, the object card comprises what has been termed a Large Binary Object ("BLOB"). The preferred card is made to a selected smart card configuration (for example, chip type and operating system as specified in step 1004), the content of the card member information data (meeting at step 1006), and the intended smart card "printer" (i.e. device used to create the completed card inside the 914 service office). This allows the system, in the preceding steps, to specify the file structures, data type and the like, without having to do with how this structure will be encoded on the smart card or how the data will be accessed, until step 1008, the system only needs to develop a model with a relatively high level of the intended smart card data structure; the specifications are substantially invisible to all except CCP 912. In an alternative mode, various details of the smart card data object can be determined at a previous point in the system. That is, the functionality of the CCP can be distributed among various system components. Having created the data set of the card member, or card object, in step 1008, these data are then sent to the CODUS 106 (step 1010). This ensures that the DSS (particularly the CODUS 106) has a record of the state of the smart card at the time of its customization. This information is then immediately available for the account maintenance system 142. The card object is then sent to service office 914 and (if required) to CCSS 916 (step 1012). In step 1014, the necessary keys are acquired to allow the service office 914 to create the finished smart card. As mentioned above, step 1014 is properly performed by the CCSS 916 concurrently or serially with the issuance process. In one embodiment, as each individual card is being created using a dispatch system suitably located in the service office 914, the service office 914 interrogates the CCSS 916 to obtain the appropriate cryptographic keys. These keys have already been or are removed from the previous key systems 920 and 918 (ie, after step 1012), or are removed in real time in response to the request of the 914 service office. Alternatively, the keys can be removed by the CCSS 916 and transmitted to the CCP 912 before the transmission of the card object to the service office 914. In any case, the key or keys are then removed for inclusion in the card object created in step 1008. In step 1016, the current card is issued. The service office 914 suitably unloads the card object on the correct smart card hardware using the correct cryptographic keys. The initiated smart card can then be packaged and distributed to the appropriate card member according to conventional methods. Synchronization Process A dynamic synchronization system as described above in various modalities is used to track the "status" of the consumer's smart card. The state of the smart card is adequately characterized by the structure of the applications used in the smart card and the different pieces of data that are stored within these applications. The manner in which applications and data are handled in an intelligent manner can vary. For example, the data files and directories can be stored in a "tree" structure on the smart card 120. That is, the smart card file structure suitably resembles the known MS-DOS file structure (operating system of Microsoft disk) where the files are logically organized within a hierarchy of directories. Specifically, three file types are defined in ISO 7816-4: dedicated files (DF), elementary files (EF), and the main file (MF). The main file is analogous to the MS-DOS "root" directory, and contains all the other files and directories. The dedicated files are currently directories or "folders" to contain other DFs or EFs. In this way, the MF may contain an arbitrary number of DFs, and these DFs may or may not contain other DFs. Elementary files are used to store user data, and may exist within a dedicated file, or within the main file. Higher level DFs (ie DFs that host particular applications) are very often referred to as limited dedicated application files (ADFs) The scope of the present invention, however, is not limited to this type of multi-function card. Other implementations, eg, Multor or Java-based cards, are also suitable within the context of the present invention. A number of synchronization issues may arise in the context of smart card with multiple functions; In fact, three paradigmatic cases can recur with some frequency, and they are related to: 1) updating operations, 2) pending transactions and 3) file structure changes. Each of these cases will now be described with respect to the present invention. Example 1: Current operations It is very common for a cardholder to make a local change in the smart card 120 that is not immediately reflected in all the databases that can advantageously use this invention. For example, suppose that when initializing (that is, when the card was originally issued by means of the personalization system 140), the smart card 120 and the card carrier was configured to reflect a general smoking preference (for example, a file contains a Boolean field with keys for smoking / not smoking), but the cardholder now wishes to change this general preference file to reflect a non-smoking preference. In this case, without referring now to Figures 1,7 with respect to a preferred embodiment of the present invention, the card carrier suitably inserts the card 120 into a commercially located access point 102, whereby the authentication of the card and / or the card reader is carried out (Step 8). In a preferred embodiment, authentication is carried out in accordance with the relevant section of ISO 7816. Next, the card carrier uses a suitable user interface (provided by the access point 102 which works in conjunction with the server 104) to be able to perform a transaction, that is, to request a change in the preference file (Step 804). In this change it would typically be reflected in the smart card 120 immediately. That is, the access point 102 or the server 104 may include the functionality necessary to access and update the appropriate files within the smart card 120. The communication router 206 on the server 104 then routes the operation to the appropriate individual, i.e. , an EDSI 108 or an EDCU 112, corresponding to branches 807 and 812 respectively. That is, depending on the configuration of the system, the file to be changed may be associated with a particular company or, alternatively, may be associated with the organization hosting the DSS. These two cases are described one at a time. After branch 807 in Figure 8, data changes are sent and stored in the appropriate EDSI 108 (Step 808). The logical update system 110 then transfers this change request to the appropriate EDCU 112, ie the EDCU 112 corresponding to the particular EDSI (Step 810). This information is stored appropriately in the corresponding update database 504. The information is also distributed to other EDSs. In the present example, the logical update system 110 would identify those systems that benefit from knowing the smoking status of the cardholder. These systems may include, for example, several hotels, car rental agencies and the like. Alternatively, after branch 805 of Figure 8, the data can first be stored in the appropriate EDCU (Step 812), then can be distributed to other EDCUs 112 and EDSIs as described above. The card data change is then transferred to the CODUS 106. Specifically, the different files and fields associated with the smart card 120 are updated to reflect the change stored in the updated 504 database. In this way, the information within the CODUS 106 is conformed that contained within the smart card 120 and the different EDCUs 112 and EDSIs 108. After this transfer, the corresponding change data in the update database 504 are erased ( Step 818). Example 2: Operation Pending The card holder can make a change to perform an operation through a channel that does not directly involve the smart card 120, thereby creating an inconsistency between the data between the smart card 120 and the data in several databases in the DSS. Said may almost arise, for example, when the cardholder calls a hotel to make a reservation (instead of performing the online operation using the smart card 120) and makes an oral request to change his or her smoking preferences or not to smoke . Referring now to Figures 1 and 7, in this case, with respect to a preferred embodiment of the present invention, the card carrier first contacts the company through a medium that does not include a smart card 120, i.e. , an "intelligent packet not present" operation (Step 702). When using an appropriate interface (voice, keyboard, etc.), a change or operation is selected (step 704). This change is then logically stored within a particular business network 114 and / or stored within an EDSI 108 (Step 706). Next, in Step 708, the logical update system 110 routes information to the corresponding EDCU 112, where it resides in the pending 514 database. At this point, the smart card 120 itself ignores the change. As a result, if the cardholder initiates an operation with the smart card present, the corresponding company would most likely first look for the preferences in the data structure of the smart card 120, and as has just been mentioned, it would most likely come to the conclusion wrong (for example, a smoking room could be assigned despite the expressed preference of the cardholder). In order to remedy this situation, the present invention provides, in Steps 710-712, a method by which the smart card is updated when used the next time. That is, after the smart card has been inserted into an access point 102 and has been properly authenticated (Step 710), the system interrogates the pending database 514 to determine whether changes have been made. If yes, the appropriate information is downloaded to the smart card (Step 712). After the above information transfer has been properly completed, the change data is transferred to the CODUS 106, where it is stored within the object card database 116. Finally, the respective information within the pending database 514 is deleted (Step 716). Example 3: File Structure / Change of Application In addition to the modifications related to the data detailed above, changes to the structure of the data stored on the smart card 120 may also be desirable in certain contexts. This, during the life of a smart card, it is likely that the person issuing the card, a society company, or the cardholder itself may wish to extend the functionality of the card by increasing the list of applications housed within the card. For example, a cardholder who uses a smart card to rent a car and make airplane reservations may also wish to use the card to purchase and pay for hotel reservations. In such case, the appropriate hotel partner can process the request of the cardholder and additionally accommodate a hotel request to be added to the file structure of the smart card. In another example, the person issuing the smart card may authorize the addition of a new application by itself, for example, a credit and / or debit application. On the contrary, it may also be appropriate in some cases to remove applications from the card. In a preferred embodiment, the types of file structure changes described above can be handled in a manner analogous to the procedure set forth in Figure 7, depending, up to a certain point, on which individual causes the file structure change. That is, as in Step 712, the appropriate file structure change information can be stored in the EDCU 112 (e.g., in the database 502), and then transferred to the smart card 120 when the card is being used in conjunction with an online operation (Pasa 710 and 712). After the file structure on the smart card 120 is augmented in another modified manner, the CODUS 106 (specifically, the database 116) is modified in a similar manner to reflect the change. The change information is then deleted from the database 502 (Step 716). Although the invention has been described herein in conjunction with the accompanying drawings, those skilled in the art will appreciate that the scope of the invention should not be limited. Modifications in the selection as design and arrangement of the different components and steps discussed herein may be made without departing from the scope of the invention as set forth in the appended claims.

Claims (11)

1. CLAIMS 1. A system for personalizing a smart card, wherein the smart card comprises an object card that has at least one application, the system characterized in that it comprises: a security server; at least one key system associated with the application, the key system is configured to communicate with the security server and supply a key in response to a request from the security server; a personalization service configured to receive the object card and communicate with the security server; the personalization service that is also configured to add the key to the object card.
2. 2. A system for dynamically synchronizing the information of the smart cards associated with a smart card, the system characterized in that it comprises: a business data collection unit configured to store the update operations and pending operations associated with the smart card; at least one access point configured to interface with the smart card and the enterprise data collection unit; an object card database system coupled to the business data collection unit and configured to store the smart card information in accordance with the update operations and pending operations.
3. 3. The system in accordance with the claim 1, characterized in that it also comprises a card handling system, the card system is configured to accept a card request and communicates the card request with the personalization service.
4. 4. The system according to claim 3, characterized in that it further comprises a meeting application module configured to communicate with the card management system and gather application information from at least one database in accordance with the request of card.
5. The system according to claim 1, characterized in that it also comprises a service office configured to communicate with the personalization service and the security service in order to produce the smart card.
6. 6. The system according to claim 1, characterized in that it also includes an activation block configured to determine whether the smart card will require activation by a tar- ge carrier.
7. 7. The system according to claim 4, characterized in that it also comprises a legacy management system, the management system is configured to communicate with the card management system and transmit the legacy data to the meeting application module that respond to the card request.
8. The system according to claim 1, characterized in that it further comprises an object card database update system configured to communicate with the personalization service and store the card associated with the smart card.
9. The system according to claim 2, characterized in that it also comprises an update logical system coupled to at least one business data synchronization interface, the update logical system is configured to securely route the card information between the enterprise data synchronization interface and the enterprise data collection units, the business data synchronization interface is coupled to a company network to communicate with the access point.
10. The system according to claim 9, characterized in that it further comprises a client insurance support server configured to communicate with the access point, the client insurance support server is further configured to adaptively provide a communication functionality according to the communication functionality available at the access point.
11. 11. An integrated smart card system for managing the personalization and synchronization of a smart card, wherein a smart card comprises an object card that has at least one application, the system characterized in that it comprises: a security server; at least one key system associated with at least one application, the key system is configured to communicate with the security server and supply a key in response to the request of the security server; a personalization service and configured to receive the object card and communicate with the security server; the personalization service is also configured to add the key to the object card; an object database database update system configured to communicate with the personalization service and store the object card associated with the smart card; a business data collection unit configured to store the updated transactions and the pending operations associated with the smart card, the business data collection unit is configured to communicate with the object card database update system; at least one access point configured for the smart card interface and the enterprise data collection unit.