Methods, systems and computer program products for smart card product management

Abstract

Methods, systems and computer program products are provided for managing a smart card product by providing a plurality of generic definitions, at least a portion of which have a predefined relationship to others of the generic definitions, so as to provide a hierarchy of generic definitions. Generic definitions are selected from the plurality of generic definitions and associated with an instance of a card product definition so as to define characteristics of the smart card product associated with the instance of the card product definition. The selected generic definitions are populated with data associated with the smart card product so as to provide a hierarchy of instances of the generic definitions which define the characteristics of the smart card product. The smart card product is managed utilizing the hierarchy of instances of the generic definitions so as to provide the smart card product having the defined characteristics. Systems for managing smart card products utilizing instances of definitions from the hierarchy of definitions are also provided.

Claims

That which is claimed:

1. A method of managing a smart card product, comprising the steps of:

providing a plurality of generic definitions in a database at least a portion of which have a predefined relationship to others of the generic definitions so as to provide a hierarchy of generic definitions;

selecting generic definitions from the plurality of generic definitions to associate the selected generic definitions with an instance of a card product definition, the instance of the card product definition defining characteristics of the smart card product; and

populating the selected generic definitions with data associated with the smart card product so a, to provide a hierarchy of instances of the generic definitions which define the characteristics of the smart card product;

wherein one or more data processing systems is configured to utilize the hierarchy of instances of the generic definitions to manage the smart card product;

wherein the steps of providing a plurality of generic definition objects, selecting generic definition objects and linking the selected generic definitions comprise the steps of:

establishing the instance of the card product definition;

associating at least one chip definition with the instance of the card product definition;

associating at least one process definition with the instance of the card product definition; associating at least one task definition with the at least one process definition;

associating at least one enterprise definition with the instance of the card product definition; and

associating at least one application definition with the instance of the card product definition.

2. A method according to claim 1, further comprising the step of managing at least one of registration of card product holders, smart card product enablement, smart card product personalization, smart card product application data, smart card product hot lists and smart card product post-issuance application updates utilizing the hierarchy of instances of the generic definitions so as to provide the smart card product having the defined characteristics.

3. A method according to claim 2, further comprising the step of selectively linking at least two of the selected generic definitions to further define the hierarchy of instances of the generic definitions associated with the smart card product so as to further define the characteristics of the smart card product.

4. A method according to claim 2, wherein the plurality of generic definitions include process definitions which define smart card management tasks which are configured to manage the attributes of the smart card product.

5. A method according to claim 2, wherein the plurality of generic definitions include a platform definition, a card product holder definition, a device definition, a certificate definition, or a key definition.

6. A method according to claim 1, wherein the step of associating at least one process definition with the instance of the card product definition comprises the step of associating an enablement process definition, a registration process definition and a personalization process definition with the card product definition.

7. A method according to claim 6, further comprising the step of associating at least one task definition with the enablement process definition so as to carry out the enablement process.

8. A method according to claim 6, further comprising the step of associating at least one task definition with the registration process definition so as to carry out the registration process.

9. A method according to claim 6, further comprising the step or associating at least one task definition with the personalization process definition so as to carry out the personalization process.

10. A method according to claim 1, wherein the step of associating at least one process definition with the instance of the card product definition comprises the step of associating a hot list definition with the instance of the card product definition.

11. A method according to claim 10, further comprising the step of associating at least one task definition with the hot list process definition so as to carry out the hot list process.

12. A method according to claim 1, wherein the step of associating at least one process definition with the instance of the card product definition comprises the step of associating an application load definition with the instance of the card product definition.

13. A method according to claim 12, further comprising the step of associating at least one task definition with the application load process definition so as to carry out the application process.

14. A method according to claim 1, further comprising the steps of:

associating an enterprise definition with the at least one process definition if the at least one process definition utilizes resources of an enterprise outside the domain of a smart card management server; and

associating a connection definition with the at least one process so as to define a mechanism for establishing a connection between the smart card management server and an enterprise associated with the enterprise definition associated with the at least one process definition.

15. A system for managing smart card products, comprising:

a database of smart card definitions, wherein the smart card definitions are associated in a hierarchical manner so as to encapsulate characteristics of smart card components, interrelationships with other components, and work processes; and

a smart card server operably associated with the database and configured so as to manage smart card products based on instances of the smart card definitions associated with the smart card products so as to define the characteristics of the smart card products and tasks associated with managing the smart card products; the smart card definitions associated with the smart card products including at least one chip definition, at least one process definition, at least one task definition, at least one application definition, at least one enterprise definition and at least one connection definition; and

wherein the smart card server is further configured to utilize an instance of an enterprise definition and an instance of a connection definition to establish communications with an enterprise associated with the enterprise definition so as to allow the enterprise associated with the enterprise definition to carry out a task associated with managing the smart card products.

16. A system according to claim 15, further comprising an application manager server, wherein the application manager server is configured to manage applications loaded on a smart card product based on smart card definitions associated with the smart card product.

17. A system according to claim 15, further comprising a certificate server configured to manage certificates utilized with a smart card product based on smart card definitions associated with the smart card product.

18. A system for managing a smart card product, comprising:

means for providing a plurality of generic definitions in a database, at least a portion of which have a predefined relationship to others of the generic definitions so as to provide a hierarchy of generic definitions;

means for selecting generic definitions from the plurality of generic definitions to associate the selected definitions with an instance of a card product definition, the instance of the card product definition defining characteristics of the smart card product; and

means for populating the selected generic definitions with data associated with the smart card product so as to provide a hierarchy of instances of the generic definitions which define the characteristics of the smart card product;

means for utilizing the hierarchy of instances of the generic definitions to manage the smart card product:

wherein the means for providing a plurality of generic definition objects, means for selecting generic definition objects and means for linking the selected generic definitions comprise:

means for establishing the instance of a card product definition;

means for associating at least one chip definition with the instance of the card product definition;

means for associating at least one process definition with the instance of the card product definition;

means for associating at least one task definition with the at least one process definition;

means for associating at least one enterprise definition with the instance of the card product definition; and

means for associating at least one application definition with the instance of the card product definition.

19. A system according to claim 18, further comprising means for managing at least one of registration of card product holders, smart card product enablement, smart card product personalization, smart card product application data, smart card product hot lists and smart card product post-issuance application updates utilizing the hierarchy of instances of the generic definitions so as to provide the smart card product having the defined characteristics.

20. A system according to claim 19, further comprising means for selectively linking at least two of the selected generic definitions to further define the hierarchy of instances of the generic definitions associated with the smart card product so as to further de fine the characteristics of the smart card product.

21. A system according to claim 19, wherein the plurality of generic definitions include process definitions which define smart card management tasks which are configured to manage the attributes of the smart card product.

22. A system according to claim 19, wherein the plurality of generic definitions include a platform definition, a card product holder definition, a device definition, a certificate definition or a key definition.

23. A system according to claim 18, wherein the means for associating at least one process definition with the instance of the card product definition comprises means for associating an enablement process definition, a registration process definition and a personalization process definition with the card product definition.

24. A system according to claim 23, further comprising means for associating at least one task definition with the enablement process definition so as to carry out the enablement process.

25. A system according to claim 23, further comprising means for associating at least one task definition with the registration process definition so as to carry out the registration process.

26. A system according to claim 23, further comprising means for associating at least one task definition with the personalization process definition so as to carry out the personalization process.

27. A system according to claim 18, wherein the means for associating at least one process definition with the instance of the card product definition comprises means for associating a hot list definition with the instance of the card product definition.

28. A system according to claim 27, further comprising means for associating at least one task definition with the hot list process definition so as to carry out the hot list process.

29. A system according to claim 18, wherein the means for associating at least one process definition with the instance of the card product definition comprises means for associating an application load definition with the instance of the card product definition.

30. A system according to claim 29, further comprising means for associating at least one task definition with the application load process definition so as to carry out the application process.

31. A system according to claim 18, further comprising:

means for associating an enterprise definition with the at least one process definition if the at least one process definition utilizes resources of an enterprise outside the domain or a smart card management server, and

means for associating a connection definition with the at least one process so as to define a mechanism for establishing a connection between the smart card management server and an enterprise associated with the enterprise definition associated with the at least one process definition.

32. A computer program product for managing a smart card product, comprising:

a computer readable media having computer readable program code embodied therein, the computer readable program code comprising:

computer readable program code which provides a plurality of generic definitions in a database, at least a portion of which have a predefined relationship to others of the genetic definitions so as to provide a hierarchy of generic definitions;

computer readable program code which selects generic definitions from the plurality of generic definitions to associate the selected generic definitions with an instance or a card product definition, the instance of the card product definition defining characteristics of the smart card product; and

computer readable program code which populates the selected generic definitions with data associated with the smart card product so as to provide a hierarchy of instances of the generic definitions which define the characteristics of the smart card product;

computer readable program code which utilizes the hierarchy of instances of the generic definitions to manage the smart card product;

wherein the computer readable program code which provides a plurality of generic definition objects, computer readable program code which selects generic definition objects and computer readable program code which selectively links the selected generic definitions comprise:

computer readable program code which establishes the instance of a card product definition;

computer readable program code which associates at least one chip definition with the instance of the card product definition;

compute readable program code which associates at least one process definition with the instance of the card product definition;

computer readable program code which associates at least one task definition with the at least one process definition;

computer readable program code which associates at least one enterprise definition with the instance of the card product definition; and

computer readable program code which associates at least one application definition with the instance of the card product definition.

33. A computer program product according to claim 32, further comprising computer readable program code which manages at least one of registration or card product holders, smart card product enablement, smart card product personalization, smart card product application data, smart card product hot lists and smart card product post-issuance application updates utilizing the hierarchy of instances of the generic definitions so as to provide the smart card product having the defined characteristics.

34. A computer program product according to claim 33, further comprising computer readable program code which selectively links at least two of the selected generic definitions to further define the hierarchy of instances of the generic definitions associated with the smart card product so as to further define the characteristics of the smart card product.

35. A computer program product according to claim 33, wherein the plurality of generic definitions include process definitions which define smart card management tasks which are configured to manage the attributes of the smart card product.

36. A computer program product according to claim 33, wherein the plurality of generic definitions include a platform definition, a card product holder definition, a device definition, a certificate definition or a key definition.

37. A computer program product according to claim 32, wherein the computer readable program code which associates at least one process definition with the instance or the card product definition comprises computer readable program code which associates an enablement process definition, a registration process definition and a personalization process definition with the card product definition.

38. A computer program product according to claim 37, further comprising computer readable program code which associates at least one task definition with the enablement process definition so as to carry out the enablement process.

39. A computer program product according to claim 37, further comprising computer readable program code which associates at least one task definition with the registration process definition so as to carry out the registration process.

40. A computer program product according to claim 37, further comprising computer readable program code which associates at least one task definition with the personalization process definition so as to carry out the personalization process.

41. A computer program product according to claim 32, wherein the computer readable program code which associates at least one process definition with the instance of the card product definition comprises computer readable program code which associates a hot list definition with the instance of the card product definition.

42. A computer program product according to claim 41, further comprising computer readable program code which associates at least one task definition with the hot list process definition so as to carry out the hot list process.

43. A computer program product according to claim 32, wherein the computer readable program code which associates at least one process definition with the instance of the card product definition comprises computer readable program code which associates an application load definition with the instance or the card product definition.

44. A computer program product according to claim 43, further comprising computer readable program code which associates at least one task definition with the application load process definition so as to carry out the application process.

45. A computer program product according to claim 32, further comprising:

computer readable program code which associates an enterprise definition with the at least one process definition if the at least one process definition utilizes resources of an enterprise outside the domain of a smart card management server; and

computer readable program code which associates a connection definition with the at lest one process so as to dine a mechanism for establishing a connection between the smart card management server and an enterprise associated with the enterprise definition associated with the at least one process definition.

Description

FIELD OF THE INVENTION

The present invention relates to smart card products and more particularly to the management of smart card products.

BACKGROUND OF THE INVENTION

Cards, such as credit cards, with built-in processing capabilities are generally referred to as smart cards. Smart cards may have many differing uses. For example, it has been proposed that smart cards be used for a wide array of uses ranging from access to networks through a network computer to on-line banking through the storage of encrypted banking information on the card. Such uses have, generally not been widespread, however, possibly as a result of the expense of manufacturing and maintaining smart cards. However, as costs are reduced, it is expected that smart card usage will increase.

A smart card product is comprised of many interrelated components, both physical and logical. Physical components include the plastic card, the embedded chip, ink, logos, or holograms applied to the plastic, and optional magnetic stripe and bar codes. Logical components are made up of software programs and data, including the card operating system, applications and application data, and security mechanisms such as keys and certificates. As used herein, the term "smart card" is used to refer to a card having processing capabilities and the term "smart card product" is used to refer to a smart card configured with the logical and physical components for a particular use of the smart card.

To produce a smart card product, each of the interrelated logical and physical components should be taken into account in the production and distribution process. However, various aspects of the smart card product may be controlled by different business enterprises. For example, the business enterprise which manufactures the smart card may differ from the business enterprise which controls the applications or data to be loaded on the smart card product. Furthermore, each of these enterprises may differ further from the enterprises responsible for card issuance or card security. Furthermore, for smart card products which may be field programmed, the application or applications loaded on the smart card may be changed, update, deleted or otherwise modified after the card has issued. Such modifications may be performed by a further business enterprise. As can be seen from this brief example, the manufacture, issuance and maintenance of smart card products may be a complex task. Such tasks may involve different enterprises which may coordinate their efforts to provide a smart card product.

SUMMARY OF THE INVENTION

Embodiments of the present invention include methods, systems and computer program products which provide for managing a smart card product by providing a plurality of generic definitions, at least a portion of which have a predefined relationship to others of the generic definitions, so as to provide a hierarchy of generic definitions. Generic definitions are selected from the plurality of generic definitions and associated with an instance of a card product definition so as to define characteristics of the smart card product associated with the instance of the card product definition. The selected generic definitions are populated with data associated with the smart card product so as to provide instances of the generic definitions which define the characteristics of the smart card product.

The smart card product may be managed utilizing the hierarchy of instances of the generic definitions so as to provide the smart card product having the defined characteristics. In particular, one or more of registration of card product holders, smart card product enablement, smart card product personalization, smart card product application data, smart card product hot lists and smart card product post-issuance application updates may be managed utilizing the hierarchy of instances of the generic definitions so as to provide the smart card product having the defined characteristics.

In further embodiments of the present invention, the selected generic definitions may be selectively linked to each other to further define the hierarchy of generic definitions associated with the instance of the smart card product so as to further define the smart card product. In such embodiments, the selection and linking of the selected definitions to the smart card product definition may be provided by establishing an instance of the card product definition and associating one or more chip definitions with the instance of the card product definition. One or more process definitions is also associated with the instance of the card product definition. Furthermore, one or more task definitions, one or more enterprise definitions and one or more application definitions are also associated with the instance of the card product definition.

In such embodiments, the association of process definitions with the instance of the card product definition may be provided by associating an enablement process definition, a registration process definition and a personalization process definition with the card product definition. Furthermore, one or more task definitions may be associated with the enablement process definition so as to carry out the enablement process. One or more task definitions may be associated with the registration process definition so as to carry out the registration process. One or more task definitions may also be associated with the personalization process definition so as to carry out the personalization process.

In further embodiments, associating process definitions with the instance of the card product definition may be provided by associating a hot list definition with the instance of the card product definition. In such embodiments, one or more task definitions may be associated with the hot list process definition so as to carry out the hot list process.

In additional embodiments of the present invention, associating process definitions with the instance of the card product definition may be accomplished by associating an application load definition with the instance of the card product definition. Furthermore, one or more task definitions may be associated with the application load process definition so as to carry out the application process.

In still other embodiments of the present invention, an enterprise definition is associated with the a process definition if the process definition utilizes resources of an enterprise outside the domain of a smart card management server. Furthermore, a connection definition is associated with the process definition so as to define a mechanism for establishing a connection between the smart card management server and an enterprise associated with the enterprise definition associated with the process definition.

In still further embodiments of the present invention, the plurality of generic definitions include process definitions which define smart card management tasks so as to manage the attributes of the smart card product.

In additional embodiments, the plurality of generic definitions include one or more of a chip definition, a platform definition, a card product holder definition, a device definition, a certificate definition, a key definition, an application definition and a process definition.

While the invention has been described above primarily with respect to the method aspects of the invention, both systems and/or computer program products are also provided.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a smart card product system according to embodiments of the present invention;

FIG. 2 is a block diagram of smart card product management system according to embodiments of the present invention;

FIG. 3 is a block diagram of a data processing system suitable for use as various components of a smart card product management system according to embodiments of the present invention;

FIG. 4 is a more detailed block diagram of data processing systems according to embodiments of the present invention;

FIG. 5 is a block diagram of a components of a smart card product management system according to embodiments of the present invention;

FIG. 6 is a block diagram of a card management server according to embodiments of the present invention;

FIG. 7 is a block diagram of a division of distributable components of a smart card product management system according to embodiments of the present invention;

FIG. 8 is a flowchart illustrating the life of a smart card definition object according to embodiments of the present invention;

FIG. 9 is a block diagram of a hierarchy of smart card product definitions according to embodiments of the present invention;

FIG. 10 is a block diagram of a communications aspect of embodiments of the present invention;

FIG. 11 is a block diagram illustrating smart card product states according to embodiments of the present invention;

FIG. 12 is a block diagram illustrating application states according to embodiments of the present invention;

FIG. 13 is a block diagram illustrating a card product issuance process according to embodiments of the present invention;

FIG. 14 is a block diagram illustrating card product registration according to embodiments of the present invention;

FIG. 15 is a block diagram illustrating card product enablement according to embodiments of the present invention;

FIG. 16 is a block diagram illustrating card product personalization according to embodiments of the present invention;

FIG. 17 is a block diagram illustrating card product distribution according to embodiments of the present invention;

FIG. 18 is a block diagram illustrating operations for customer support services according to embodiments of the present invention;

FIG. 19 is a block diagram illustrating hot list processing according to embodiments of the present invention;

FIG. 20 is a block diagram illustrating operations for post-issuance application management according to embodiments of the present invention;

FIG. 21 is a block diagram illustrating operations for security administration according to embodiments of the present invention;

FIG. 22 is a block diagram of an example smart card product management system according to embodiments of the present invention;

FIG. 23 is a flow chart illustrating operations for creating a smart card product according to embodiments of the present invention;

FIG. 24 is a flow chart illustrating operations for card enablement according to embodiments of the present invention;

FIG. 25 is a flow chart illustrating operations for card holder registration according to embodiments of the present invention;

FIG. 26 is a flow chart illustrating operations for card personalization and issuance according to embodiments of the present invention;

FIG. 27 is a flow chart illustrating operations for hot list management according to embodiments of the present invention; and

FIG. 28 is a flow chart illustrating operations for post-issuance application loading according to embodiments of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

As will be appreciated by one skilled in the art, the present invention may be embodied as a method, data processing system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code means embodied in the medium. Any suitable computer readable medium may be utilized including hard disks, CD-ROMs, optical storage devices, a transmission media such as those supporting the Internet or an intranet, or magnetic storage devices.

Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java.RTM., Smalltalk or C++. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and/or block diagram block or blocks.

Smart card product management systems according to embodiments of the present invention may provide the functions and processes necessary to support the life cycle of smart card products or portions of the life cycle of a smart card product. The smart card product management system may manage the smart card product from its initial creation and distribution to an end user, to the time when the smart card product is expired, withdrawn, or replaced by the card issuer or portions thereof. During a smart card product's useful life, the smart card product management system may support the capability to dynamically update the smart card product's content, adding and deleting applications, replacing keys and certificates, or, in the event of a lost or stolen card, preventing its unauthorized usage.

As described in more detail below, in embodiments of the present invention, the smart card product management system captures the characteristics of each component of a smart card product in a component "definition." Each component is represented by a definition, which encapsulates the component's characteristics, interrelationships with other components, and unique work processes in a single program object. The use of component definitions to provide the "blueprint" for each different smart card product provides a mechanism for expressing the hierarchical relationship of the smart card product's components, and for simplifying the selection and performance of management functions against individual smart card products. Once created and activated, a set of definitions for a smart card product can be used repeatedly to manage the potentially millions of individual cards issued of that product type. Furthermore, the hierarchical relationship of the definitions is well suited for implementation using a relational data repository, thus availing the card issuer to the security, transactional integrity, and archival capabilities of the variety of relational database products available in the marketplace.

An example of a smart card product environment in which embodiments of the present invention may be utilized is illustrated in FIG. 1. In this environment, the Card Issuer 10 is the central point of control. The Card Issuer 10 establishes business relationships with other enterprises in order to support the issuance and usage of its card products. Although all of the enterprises in FIG. 1 are shown as separate entities, some of them may actually be part of the same enterprise. For example, the Customer Support Services will typically be a part of the Card Issuer's enterprise, and a Card Issuer 10 can be an Application Provider 12 if they are deploying their own applications.

As illustrated in the example of FIG. 1, the Card Issuer 10 (CI) establishes the policies that control the smart card product management system, and therefore have a significant influence over the overall card management scheme. The Card Issuer 10 may also own the card and be legally responsible for it. The Application Provider(s) 12 (AP) may develop and own one or more applications, and may be legally and technically responsible for them. The Application Provider 12 establishes business relationships with one or more Card Issuers 10, which will put the Application Provider's application on their cards.

A Certificate Authority (CA) generates, manages, and administers public key certificates for both cards and applications. The CA is typically an external service provider for the Card Issuer 10 or Application Provider 12. The Card Issuer 10 and the Application Provider 12 may be responsible for issuing certificates. One or more CAs may operate within a smart card product management system. A Trusted Third Party (TTP) provides cryptographic services for the Card Issuer 10, the Application Provider 12, and the Personalization Agency 16. The TTP is typically responsible for the secure generation and storage of cryptographic keys. As illustrated in FIG. 1, the CA and TTP may be the same enterprise. Furthermore, the CA and TTP may be associated with a Card Issuer 10 or an Application Provider 12. Thus, in FIG. 1, a Card CA/TTP 14 is illustrated as communicating with the Card Issuer 10 and an Application CA/TTP 14' is illustrated as communicating with the Application Provider 12.

A Card Manufacturer, which may also be referred to as an Initialization Agency, performs the initialization of smart card chips during module production. The information that is needed to initialize the chip is provided by the card and application issuing functions within the smart card product management system. The Card Manufacturer may also act as a Personalization Agency (PA). The PA 16, which may also be referred to as a Card Bureau, personalizes both the chip and the plastic on a card. In some systems, the Personalization Agency 16 may interface directly with the TTPs or the CAs on behalf of both the Card Issuers 10 and the Application Providers 12. The Personalization Agency 16 may also provide related services, such as production and mailing of card letters.

The Registration Authority 18 (RA) may operate the registration process for card product holders that have been defined by the Card Issuers 10, the Application Providers 12, and the Certificate Authorities. The RA 18 may be a part of the Card Issuer 10, the Application Provider 12 or the Certificate Authority 14, or it may be a separate organization. In any case, it may be considered a logical extension of these enterprises and, therefore, may operate a portion of the smart card product management system.

A customer support services center 20, which is also referred to as a call center or service center, may be the Card Issuer 10 and the Application Provider 12 point of contact for a card product holder. A Card Terminal Server 22 may provide access points for use, update, distribution and/or activation of the smart card product.

In addition to the enterprises described above and illustrated in FIG. 1, other enterprises may also play a role in the development, production and deployment of a smart card product. For example, Card Operating System (OS) providers may contribute the information, such as product specifications, that are required to implement card capabilities management for a specific card or set of cards. Card distributors may be responsible for the distribution of newly issued smart card products to an outlet(s) that will subsequently sell or distribute the cards to an end user. Examples of such distribution may include anonymous cards stocked and sold from vending machines, distributed to retail outlets, or delivered to organizations that may distribute the cards as part of a promotional program.

As is clear from the exemplary environment of FIG. 1, the complex nature of the smart card product environment may make the use of a smart card product management system beneficial. Smart card product management includes providing the management support for multi-application, card-based products within a multi-enterprise environment. A smart card product may be the business product that a Card Issuer 10 plans to market. For example, the business product could be a corporate campus card, loyalty card, or corporate traveler card. The functions provided by a smart card product management system may include issuance, life-cycle management, post-issuance support, security services, and information exchange for the objects that are managed by a smart card product management system. Cards, applications, keys, certificates, enterprises and card product holders are examples of these objects. The smart card product management system provides the basis for developing smart card product management solutions using a component-based design. As is described in more detail herein, embodiments of the smart card product management system according to the present invention may provide a set of core card management components. These components may be assembled and/or extended (or built upon) to produce a customer specific implementation of a complete smart card product management system.

Embodiments of the smart card product management system of the present invention may provide the facilities to manage each smart card product through its life-cycle, from initial creation and issuance, to activation and intended usage, and ending when the card is replaced or withdrawn. In addition to the card itself, applications, application data, certificates, and keys which reside on the card may also be managed by the smart card product management system. In particular embodiments of the present invention, the smart card product management system may provide support for a multi-application card that has the capability to contain more than one executable application or more than one set of application data (single application smart card products may also be supported). Embodiments of smart card product management system, according to the present invention may also support existing multi-application card operating systems, as well as future operating systems. For example, embodiments of the present invention may support Java Card (with Open Platform support), multi-application operating system for smart cards (MULTOS) or Smart Card for Windows.

Furthermore, embodiments of the present invention may provide support for multiple card issuers and/or application providers, as well as the enterprises with which card issuers and/or application provides interact (e.g. registration authorities and certificate authorities).

An example of a smart card product management system according to embodiments of the present invention is illustrated in FIG. 2. As seen in FIG. 2, a smart card product management system may include a card management server 52, an application management server 54, and a key and certificate management server 56. The smart card product management server 52 may be controlled by the Card Issuer 10 and may control the operation of the other management systems. The Card Issuer 10 has the primary responsibility for card product definition, card product issuance and card product management. The application management server 54 may be controlled by the Application Provider 12 which has the primary responsibility for the application data management functions, which are utilized in the card product issuance process. The application management server 54 provides the platform for implementing the application data management functions. These servers provide access to application personalization data and assist with key management for applications. Finally, the key and certificate management server 56 may be operated by enterprises external to the Card Issuer 10 or Application Provider 12. These servers provide the functions utilized to generate and store both keys and certificates. The key and certificate management server 56 is usually operated by a Trusted Third Party for key management and a Certificate Authority for certificate management.

As is further illustrated in FIG. 2, the smart card product management system may interface with various clients 58. For example, a customer support services client 60 may be utilized by the customer support service enterprise 20, a personalization agency client 62 may be utilized by a personalization agency 16 to perform the card personalization service and a system administration client 64 may provide access to the smart card product management system to carry out administrative functions. Additionally, a card server/terminal client 66 may provide terminal functions and a registration authority client 68 may be provided to perform registration operations.

Embodiments of the smart card product management system may utilize a standard method for communication both between management systems 52, 54 and 56 and from clients 58 to the management systems. These communication methods may, for example, encapsulate a transaction request and response using a standard message format, such as a message format based on the Extensible Markup Language (XML). Thus, transactions that occur between external enterprises may have a well defined XML data format.

Referring now to FIG. 3, an exemplary embodiment of a data processing system 230 suitable for use as a server or a client in accordance with embodiments of the present invention is illustrated and may include input device(s) 232 such as a keyboard or keypad, a display 234, and a memory 236 that communicate with a processor 238. The data processing system 230 may further include a storage system 242, a speaker 244 and an I/O data port(s) 246 that also communicate with the processor 238. The storage system 242 may include removable and/or fixed media such as floppy disks, ZIP drives, hard disks or the like as well as virtual storage such as a RAMDISK. The I/O data port 246 can be used to transfer information between the data processing system 230 and another computer system or a network (e.g., the Internet). Such data processing systems may include, for example, personal computers, laptop computers, mainframe computers, pervasive computing devices such as personal digital assistants, smartphones or the like, or even embedded processing systems. The components of a particular data processing system may be conventional or custom components, such as those used in many conventional computing devices, which may be configured to operate as described herein.

FIG. 4 is a block diagram of data processing systems that illustrates systems, methods, and computer program products in accordance with embodiments of the present invention. The processor 238 communicates with the memory 236 via an address/data bus 248. The processor 238 can be a commercially available or custom microprocessor. The memory 236 is representative of the overall hierarchy of memory devices containing the software and data used to implement the functionality of the data processing system 230. The memory 236 can include, but is not limited to, the following types of devices: cache, ROM, PROM, EPROM, EEPROM, flash memory, SRAM, and DRAM.

As shown in FIG. 4, the memory 236 may contain several categories of software and data used in the data processing system 230: the operating system 252; the application program(s) 10; the input/output (I/O) device drivers 258; and the data 256. As will be appreciated by those of skill in the art, the operating system 252 may be any operating system suitable for use with a data processing system, such as OS/2, AIX or OS/390 from International Business Machines Corporation, Armonk, N.Y., WindowsCE, WindowsNT, Windows95, Windows98 or Windows2000 from Microsoft Corporation, Redmond, Wash., PalmOS from Palm, Inc., MacOS from Apple Computer, UNIX or Linux, proprietary operating systems or dedicated operating systems, for example, for embedded data processing systems.

The I/O device drivers 258 typically include software routines accessed through the operating system 252 by the application programs 254 to communicate with devices such as the input devices 232, the display 234, the speaker 244, the storage system 242, the I/O data port(s) 246, and certain memory 236 components. The application program(s) 254 is illustrative of the programs that implement the various features of the data processing system 230. Finally, the data 256 represents the static and dynamic data used by the application program(s) 254, operating system 252, I/O device drivers 258, and other software programs that may reside in the memory 236.

As is further seen in FIG. 4, application program(s) 254 may include smart card product management system application(s) 255 which may carry out some or all of the functions described herein. Furthermore, the data 256 may include smart card product definition objects 257 which, as described herein, may be utilized in a hierarchical manner to define smart card products which may be produced utilizing embodiments of the present invention. The operation of the smart card product management system application 255 and the smart card product definition objects 257 is described in detail below.

Embodiments of the present invention may provide a smart card product management system which may be defined based on the business rules and relationships established by the Card Issuer 10. As illustrated in FIG. 5, the smart card product management system 50 may provide management of smart card product deployment in utilizing one or more of three components of the smart card product management system: a definitions component 70; a management tasks component 72; and a management services component 74. The definitions component 70 contains the basic attributes for the card products that are managed by the smart card product management system 50. As seen in FIG. 5, these, definitions may include platform definitions, chip definitions, application definitions, key definitions, certificate definitions, enterprise definitions, card holder definitions, application holder definitions, device definitions, process definitions and the like. These definitions are utilized by the smart card product management system to specify and control a smart card product.

The management tasks component 72 defines the basic functions that are performed by the smart card product management system 50. Embodiments of the present invention may, in addition to other management tasks, provide one or more of three management tasks: card product issuance 76, application data management 78, and card product management 80. The card product issuance 76 function may provide for initial card issuance and reissuance while the application data management 78 and the card product management 80 functions may provide for post-issuance and multi-enterprise management support.

The management services component 74 may provide the foundation services that may be utilized by both the definitions component 70 and the management tasks component 72. Such services may include, for example, policies and rules management 82, management events 84, security, auditing and reporting 86, legacy system interfaces 88, enterprise connections 90, database interfaces 92 and transaction support 94.

As described above, smart card product management systems according to embodiments of the present invention may include a set of management systems that communicate with one another. Generally, these management systems include a data repository that contains the entities that they manage. Thus, as illustrated in FIG. 6, the smart card product management system 50 includes a data repository 94 which may be accessed by the card management server 52.

As illustrated in FIG. 6, the smart card product management server 52 may incorporated several components including the smart card product management system 50, an application server 96 and an operating system 98. The components of the smart card product management system 50 may be implemented so that they run in conjunction with an application server 96. Application servers may provide a scalable runtime environment for business applications, integration with other enterprise systems, and an environment for rapid application development. The application server 96 provides a platform that contains the runtime environment for an application's business logic. In particular embodiments, applications run as servlets and/or Enterprise JavaBeans (EJB), and communicate with clients and other applications, or application components, using HTTP and IIOP (Internet InterOrb Protocol). Servlets are protocol and platform-independent server side components which are typically written in Java. Since servlets are written in Java, they are typically more flexible and stable than CGI scripts and provide an interface that can be used on different platforms without additional porting. Enterprise JavaBeans are JavaBeans that deliver reusable, reliable, business application middleware. Enterprise JavaBeans provide a component model for server applications which allows an application to be easily partitioned into user interface and business logic. The user interface or client side of the application can be written in Java, HTML, C/C++, or Visual Basic or other suitable programming languages. Because the server side business logic is packaged as Enterprise JavaBeans, it can be deployed anywhere in the network, reused with other business applications running on different platforms, and managed from a remote console.

As is further illustrated in FIG. 6, the application server 96 may contain a set of foundation services. An application can utilize the functions provided by the foundation services, such as database and transaction support, as well as the directory and security services provided by the network infrastructure. The foundation services provide the core functionality to support the applications that are running on an application server. These services may include an HTTP server 100, database services 106, transaction services 102, and messaging services 104.

The HTTP server 100 provides basic web-based services. This may include coordinating, collecting, and assembling Web pages composed from static and dynamic content which is then delivered directly to clients. The HTTP server 100 can also provide access to applications that are implemented as servlets. The transaction services 102 may extend the functionality of the application server 96 to provide scalable and secure transaction application execution environment. The database services 106 may provide a standard interface to relational databases. For example, the database services 106 may provide an interface to DB2, Oracle, Sybase, Informix or other relational databases. The messaging services 104 may provide access to Message Oriented Middleware (MOM). These types of services may be used for messaging between applications, which can be running on clients or servers.

In addition to the smart card product management system 50 and the application server 96, the card management server 52 also includes an operating system 98. Both the smart card product management system 50 and the application server 96 may be run on top of an operating system 98 which may, in Java embodiments of the present invention, provide the services of a Java Virtual Machine (JVM). Suitable operating systems may include, for example, Windows NT, AIX, Solaris, Linux and OS/390.

FIG. 7 illustrates a particular embodiment of the present invention which may be utilized in deploying a smart card product management system 50. As seen in FIG. 7, the deployable smart card product management system 700 may include generic components 702 which may be distributed as part of a base smart card product management solution. These generic components 702 may include core components 704, which are those parts of the system that are required by all implementations of a smart card product management system. The function and content of these components do not change from one implementation to the next. An example of a core component are the definitions. All implementations of a smart card product management system will typically require a set of definitions. The type of attributes and functions associated with the definitions will typically not change based on the implementation of the smart card product management system.

The generic components 702 may also include standard extensions 706 which are built on top of the core components 704. The standard extensions 706 represent functions that will be used in most, but not necessarily all implementations of a smart card product management system. Many of the management tasks described herein may be implemented as standard extensions. An example of a standard extension is support for a specific card operating system or support for a specific Personalization Agency interface. A library of standard extensions may be provided with a basic smart card product management system. The set of standard extensions in this library may be sufficient to build a complete smart card product management system, but some of them may be enhanced or replaced by custom extensions to fulfill a specific customer requirement.

The custom extensions 708 are built on top of the core components 704, the standard extensions 706 or both. These extensions may be unique to a specific customer and will typically not be distributed as part of a basic smart card product management system. An example of a custom extension is an extension used to access data that is located outside of the smart card product management system. As an example, when a specific customer maintains their card product holder data outside of the smart card product management system, a custom extension may be used to access this data.

As described above, a core component of a smart card product management system according to embodiments of the present invention are the definition objects. The definitions are used to describe the characteristics and functionality of an object that is managed by the smart card product management system. Definitions can be compared to a template. When the template is filled in, it becomes part of the knowledge-base that is used by the smart card product management system. This knowledge-base provides the basis for issuance and management functions that are processed by the smart card product management system. An implementation of a definition may be used to create multiple instances of the object that is represented by the definition. For example, a card product definition may be used to create instances of card products, and an application definition may be used to create instances of applications. All definitions may be considered core components and, therefore, may not be changed. However, a definition extension can be used to create new definitions and enhance a core definition's function. A definition extension can be implemented as either a standard extension or a custom extension.

Each definition has a life-cycle, which is a set of states that a definition transitions through. A typical life-cycle for a definition is shown in FIG. 8. A definition will move from one state to the next when a specific event occurs. For example, when a definition is in the process of being completed, it is in the CREATED state 800. When the definition contains all of its required information and this information is saved in a definitions database, the definition moves to the DEFINED state 802. The event that triggered the state change was the completion and storage of all required information for the definition.

Definitions may also have some state transitions that can not be reversed. For example, when a definition is approved for usage, for example, by entering and exiting the TEST state 804, it will move from the DEFINED 802 to the ACTIVE state 806. Once a definition is in the ACTIVE state 806, the contents of the definition can not be changed. This means that a definition can not transition from the ACTIVE state 806 back to the DEFINED state 802. A definition is updated by creating a new version of the definition.

Thus, the life of a definition, as illustrated in the embodiments of FIG. 8, begins with creating the definition when the definition is in the CREATED state 800. When all required information has been created and saved, the definition will move to the DEFINED state 802. From the DEFINED state 802, the definition will enter the TEST state 804 where the definition is tested before activation. If modifications are need to the definition the definition may return to the CREATED state 800 for updating. When the test is complete, the definition may exit the TEST state 804 and return to the DEFINED state 802. When the definition is approved for use, it will enter the ACTIVE state 806. The definition may be temporarily suspended by placing the definition in the DISABLED state 808. From the DISABLED state 808, the definition may return to the ACTIVE state 806 or be withdrawn from usage and enter the WITHDRAWN state 810. The definition may also be withdrawn directly from the ACTIVE state 806. If the definition has been withdrawn, it may exit the WITHDRAWN state 810 and be deleted by entering the DELETED state 812. Similarly, the definition may be deleted as a result of testing and, therefore, the definition may enter the DELETED state 812 directly from the TEST state 804.

In particular embodiments, definitions may have a common set of attributes: definition ID, version number, type, description, life-cycle state, and valid usage dates. Some definitions will have additional attributes.

The definition ID attribute is a unique identifier (ID), so that a reference to a definition will not be ambiguous. The definition also include a version number attribute that may be used to update a definition's content after it has been activated and used. A new version of a definition can be created from the current version. Initially, the new version will contain the same attribute values, which includes definition references. The type attribute of definition may be used to classify or group definitions which have similar characteristics or usage. The description attribute of the definition is an explanation of the definition usage which is specified using free-form text.

As described above, definitions have a specific life-cycle. The life-cycle is a set of states that a definition can progress through. A definition will move from one state to the next when a pre-defined event occurs. The possible states for all definitions are the same. The life-cycle attribute specifies the current life-cycle state of the definition.

The valid usage date attribute defines the dates within which the definition can be used. This includes a start date and an expiration date. The start date is when the definition can transition to the ACTIVE state. The expiration date is when the definition's usage will expire. On the expiration date, the definition's life-cycle state will transition to the WITHDRAWN state, so that it can no longer be used.

In addition to common attributes, the definitions also support a common set of functions, which includes create, update, delete and query. Some definitions will require additional functions. The create function creates a new definition with a unique identifier. The update function updates the attributes of an existing definition. The delete function deletes a definition The List function lists all versions of a definition, or all definitions for a particular type of definition. The view function views the attributes of a specific definition the link/unlink function link (associate) or unlink an instance of another type of definition to a definition. When linking a definition, the definition that is being linked should be in a DEFINED state.

Definitions also share a common management process and may be stored in the database 94. Definitions may be managed through an administrative user interface that may be provided as part of the administration client 64 and is used to process functions such as create, modify, delete or list definitions. The user interface may be web-based, so that it can be run on a broad range of clients. As the definitions are created, the data associated with the definitions are stored in the smart card product management system database 94. Definitions may contain both the common attributes and definition specific attributes. Some definitions may contain references to other definitions.

Definition versioning may be used to implement change control for updates to a definition, because a definition, in the illustrated embodiments of FIG. 8, cannot be changed after it is activated. The definition versioning function may ensure that the smart card product management system can provide consistent management of the deployed card base. Updates to an existing definition may be initiated by creating a new version of the definition. When a new version of a definition is created, a copy of the definition is created with a new version number and the definition is put into the DEFINED state. All versions of a definition have the same definition identifier (ID), and new versions can be created only from the last active version. All versions of a definition are implicitly linked together. This implies that a new version of a definition must be backward compatible with all old definition versions. This ensures that instance objects that are created from an old definition version can be migrated to a new definition version, if it is required.

Backward compatibility may be accomplished by allowing only a subset of changes to a new definition version. Whereas a completely new definition can be changed in any way that is required, the changes to a new version of a definition must be restricted to ensure compatibility. For example, updates to the definitions that are associated with a new version of a definition may be restricted to adding new definitions and upgrading to new versions of the linked definitions. As an example, after a new version of a card product definition is created, a new application definition can be added to this definition and an existing application definition can be upgraded to the latest version. When these changes are approved and the card product definition is moved into the ACTIVE state, the card product objects that were created from the old definition version can be migrated to the new definition version. After the migration is completed, the new application can be requested and downloaded onto the existing card products.

Definitions may also be imported into the smart card product management system, for example, in XML format. The import function allows other enterprises to provide the information that is related to their participation in the overall scheme. As an example, a chip definition can be provided by the Card Manufacturer, and an application definition can be provided by an Application Provider. When a definition is imported into the smart card product management system, its state will be set to CREATED if the definition is incomplete, or it will be set to DEFINED if it contains all of the definition's required information.

A definition extension can be used to extend the data attributes that are associated with a specific type of definition. A definition extension is implemented as a definition. It will have all of the same characteristics as a core definition, such as an identifier and version number, but it can not be extended using a different definition extension. The primary purpose of a definition extension is to add definition attributes that are not included in the core set of definitions.

As an example, a definition extension can be used to define a card's physical appearance and layout. The definition extension contains the results of designing the card layout. The definition extension may then include the text, images (including logos), and barcodes that will be printed on the card, as well as the data that will be encoded on the magnetic stripe of the card. This type of definition extension can be associated with both the card product and the application definition. By doing this, an application can personalize the physical layout of a card if it is required. For example, a credit/debit application can be loaded onto the chip, and can encode data on the magnetic stripe in order to maintain compatibility with the existing infrastructure of magnetic stripe readers.

As shown in FIG. 9, a hierarchy of definitions may be utilized to describe a smart card product. Such a hierarchy may begin with a smart card product definition 900. The smart card product definition 900 contains the business properties that will affect the issuance and usage of a card-based product. A card product may correspond to the business product that a Card Issuer plans to market. For example, if a Card Issuer wants to issue a Corporate Traveler card, then the card product is the Corporate Traveler card and the card product definition will contain all of the information needed to issue and manage that card product.

The data associated with all of the definitions are stored in the smart card product management system database 94. The definitions may contain references to data that is stored outside of the smart card product management system database 94, such as application management, key and certificate management, and/or legacy databases. For example, the application data that is required to personalize an application may exist only in the application management database. The application definition will contain a reference to the location of the application data, and this reference will reside in the database.

As mentioned above, all of the definitions within the smart card product management system are logically associated with the card product definition 900. The smart card product definition 900, as shown in FIG. 9, contains references to other definitions. Some of the definitions that are referenced by the card product definition may contain references to additional definitions. FIG. 9 illustrates one such set of relationships between the definitions. Some definitions have a one-to-one relationship, and others have a one-to-many relationship. As an example, only one platform definition 902 is associated with the smart card product definition 900, but one or more application definitions 910 can be associated with the same card product definition.

Examples of definitions which may be associated with the card product definition 900 include a platform definition 902, a card product holder definition 904, an enterprise definition 906, chip definitions 908, application definitions 910, key definitions 912, certificate definitions 914, device definitions 916, and process definitions 918. These definitions may have a one-to-one or a one-to-many relationship with the smart card product definition 900. Furthermore, the definitions may be optional or required in a smart card product definition 900.

As is seen in FIG. 9, multiple instances of a single definition may be associated with a card product definition 900. Furthermore, these instances may be linked to other definitions so as to further define the hierarchy. Thus, for example, as seen in FIG. 9, an enterprise definition 906 is linked to the card product definition 900, a second enterprise definition 906' is linked to the chip definition 908 and a third enterprise definition 906" is linked to the application definition 910. Similarly, the process definitions 918 and 918', the certificate definitions 914 and 914', the key definitions 902 and 902', and the device definitions 916 and 916' may be linked to the card product definition 900 and the application definition 910 respectively. Thus, as seen in FIG. 9, links between instances of definitions may be utilized to further define the characteristics of the smart card product associated with the card product definition 900.

Embodiments of the present invention will now be described with respect to a hierarchy of definitions which may provide a hierarchy as illustrated in FIG. 9. As will be appreciated by those of skill in the art, different definitions may be utilized and different hierarchies established while still benefitting from the teachings of the present invention. Accordingly, the definitions and hierarchy described in detail herein are provided to illustrate exemplary embodiments of the present invention. Thus, the present invention should not be construed as limited to the definitions or hierarchy described herein.

In the particular exemplary embodiment of the present invention, the table below identifies whether a definition is optional or required and the relationship to the smart card product definition 900 for particular embodiments of the present invention.

                             TABLE 1
    Definitions Associated with a Smart Card Product Definition
        Definition         Relationship   Required or Optional
        Application           Many             Optional
        Card Product Holder     One             Required
        Certificate           Many             Optional
        Chip                  Many             Required
        Device                Many             Optional
        Enterprise             One             Required
        Key                   Many             Optional
        Platform               One             Required
        Process               Many             Optional

    Card OS Name         The card operating system on the chip. For
                         example, this could be either Java Card or
                         MULTOS.
    Card OS Version      The version number for the card operating
                         system on the chip.
    Card OS Implementor  The enterprise that implemented the card
                         operating system for this chip.
    Card OS Extensions   The extensions that are available on this
                         implementation of the card operating system.

    Chip Type              The type of chip utilized by the smart card
                           product.
    Chip Manufacturer      The manufacturer of the chip used on the
                           smart card product.
    EEPROM Size Available  The amount of storage available on the smart
                           card for application code and data.

                             TABLE 2
          Definitions Associated with a Chip Definition
          Definition    Relationship     Required or Optional
          Enterprise        One               Required
          Key              Many               Optional
          Platform          One               Required

    Link Allowed         This attribute indicates whether or not
                         another application definition can be linked
                         to this application definition. For a Java Card
                         based smart card product this attribute may
                         be required for applications such as the Card
                         Manager and Security Domain.
    AID                  An application identifier associated with the
                         application.
    ROM Size Code        The minimum ROM size required for
                         application code (used if application will be
                         put into ROM).
    ROM Size Data        The minimum ROM size required for
                         application data (used if application will be
                         put into ROM).
    EEPROM Size Code     The minimum EEPROM size required for
                         application code.
    EEPROM Size Data     The minimum EEPROM size required for
                         application data.

    Import Executable This function receives the application
                      executable code from the Application
                      Developer or Application Provider and stores
                      it securely in the database. The executable is
                      used as input to the application load process
                      (e.g. ALU generation for a MULTOS application).
    Register Application All MULTOS applications should be
                      registered with the MULTOS CA before they
                      can be loaded onto a card. Registering an
                      application does not verify or validate the
                      application code or execution, it is only used
                      to identify the application that the Card Issuer
                      10 will be allowed to load onto a card. After
                      an application is registered, it is assigned a
                      unique identifier (AID). The AID can be
                      used by the smart card product management
                      system to reference the application.

                             TABLE 3
      Definitions Associated with an Application Definition
        Definition         Relationship   Required or Optional
        Application           Many             Optional
        Application Holder     One             Required
        Certificate           Many             Optional
        Chip                  Many             Required
        Device                Many             Optional
        Enterprise             One             Required
        Key                   Many             Optional
        Platform               One             Required
        Process               Many             Optional

            Length             The key length.
            Algorithm          The key algorithm for the key.
            Modulus            The key modulus.
            Exponent           The key exponent.

                             TABLE 4
           Definitions Associated with a Key Definition
          Definition    Relationship     Required or Optional
          Key              Many               Optional
          Platform          One               Required
          Process          Many               Optional

                             TABLE 5
       Definitions Associated with a Certificate Definition
          Definition    Relationship     Required or Optional
          Key              Many               Optional
          Platform          One               Required
          Process          Many               Optional

    Name                       The name of the enterprise.
    Address                    Mail/postal address where this
                               enterprise can be contacted.
    Authorized Contact Person(s): The person(s) who are authorized to
                               be the point of contact for this
                               enterprise. The contact information
                               may include the person's name, title,
                               phone number, etc.

                             TABLE 6
    Definitions Associated with a Card Product Holder Definition
          Definition      Relationship    Required or Optional
          Connection          One              Required
          Platform            One              Required
          Process            Many              Optional

                             TABLE 7
    Definitions Associated with an Application Holder Definition
          Definition      Relationship    Required or Optional
          Connection          One              Required
          Platform            One              Required
          Process            Many              Optional

          Name        The name device where a card product or
                      application can be used.
          Version     The version of the device that is supported.

    Plastic           Defines the type of plastic that is required for
                      the card.
    Text              Defines an area on a card where a text string
                      will be printed, embossed or indented.
    Image             Defines an image and an area on the card
                      where the image should be printed.
    Magnetic Stripe   A definition of the magnetic stripe data which
                      will be encoded on the card during personalization.
    Barcode           Defines barcode data that will be used during
                      personalization.