`
`PC T/GB98/0053 1
`
`More specifically, this public key stored on the card will allow the
`
`individual card to verify data signed with the CA’s private key. The public key of the
`
`CA, which is stored on the card, is used only for determining if the data sent to the card
`
`was signed with the proper CA private key. This allows the card to verify the source of
`
`any message coming from the CA.
`
`Step 205 inserts a card enablement key in a secure portion of EEPROM in
`
`the card to facilitate card specific confidentiality during enablement, and step 207 inserts
`
`a card identifier in EEPROM of the card. The identifier, which can be accessed by any
`
`terminal, will allow the system to determine the identity of the card in later processes.
`
`10
`
`The identifier is freely available and will not be used to authenticate messages.
`
`Step 209 stores the operating system code in ROM on the card including
`
`any primitives which are called or supported by the operating system. The primitives are
`
`written in native language code (e.g., assembly language) and are stored in ROM. The
`
`primitives are subroutines which may be called by the operating system or by
`
`15
`
`applications residing on the card such as mathematic functions (multiply or divide), data
`
`retrieval, data manipulation or cryptographic algorithms. The primitives can be executed
`
`very quickly because they are written in the native language of the processor.
`
`Afier the IC cards are manufactured, they are sent to a personalization bureau
`
`(“PB”) to enable and personalize the card by storing card personalization data in the
`
`20
`
`memory of the card. The terms enablement and personalization are used interchangeably
`
`herein to indicate the preparatory steps taken to allow the card to be loaded securely with
`
`-10..
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01313
`
`Page 01313
`
`
`
`W0 98/37526
`
`PCT/G B98/0053 1
`
`an application. The individual cards are preferably manufactured in batches and are sent
`
`to a personalization bureau in a group for processing.
`
`flag Eggblgmgnt/PersgnalizgtjQ1;
`
`Figure 3 shows the steps of the card enablement process when the card
`
`arrives at a personalization bureau. The personalization bureau may be the card issuer
`
`(e.g., a bank or other financial institution) or may be a third party that performs the
`
`service for the card issuer. The personalization bureau configures the card to a specific
`
`user or user class.
`
`Figure 3 specifically shows the steps taken to enable and personalize each
`
`10
`
`IC card which will work within the system. The cards can be placed in a terminal which
`
`communicates with IC cards and which reads the card identifier data (previously placed
`
`on the card during the manufacturing process -- see step 207). This card identification
`
`data is read from the card in step 301. The terminal will effectively send a “get
`
`identification data" command to the card and the card will return the identification data to
`
`15
`
`the terminal.
`
`The PB typically processes a group of cards at the same time, and will first
`
`compile a list of IC card identification data for the group of cards it is personalizing. The
`
`PB then sends electronically (or otherwise) this list of identification data to the
`
`Certification Authority ("CA”) which creates a personalization (or enablement) data
`
`20
`
`block for each card identifier. The data block includes the card personalization data
`
`organized in a number of identity fields and an individual key set for the card, discussed
`
`below. These data blocks are then encrypted and sent to the PB in step 302. By using the
`
`_ 11 -
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01314
`
`Page 01314
`
`
`
`WO 98/37526
`
`PCT/GB98/00531
`
`card identification data, the PB then matches the cards with the encrypted data blocks and
`
`separately loads each data block onto the matched card. To insure that the CA controls
`
`the identity of the card and the integrity of the system, the PB never obtains knowledge of
`
`the content of the data blocks transferred. Some aspects of the personalization are
`
`requested by the card issuer to the CA in order to affect their preferred management of
`
`the cards they issue. The following additional steps are performed.
`
`Step 303 first checks to see if an enablement bit stored in EEPROM of the
`
`card has been already set. If it already has been set, the card has already been configured
`
`and personalized and the enablement process will end as shown in step 304. A card
`
`10
`
`cannot be enabled and personalized twice. If the bit has not been set, then the process
`
`continues with step 305.
`
`In step 305, the individualized card key set for the card being enabled
`
`(which key set is generated at the CA) is stored on the card. The keys can be used later in
`
`off—card verification (i.e., to verify that the card is an authentic card). This verification is
`
`15
`
`necessary to further authenticate the card as the one for which the application was
`
`intended.
`
`Step 307 generates four different MULTOS Security Manager (MSM)
`
`characteristic data elements (otherwise referred to herein as personalization data) for the
`
`card at the CA which are used for securely and correctly loading and deleting applications
`
`20
`
`fi'om a particular card. The MSM characteristics also allow for the loading of
`
`applications on specific classes of identified cards. (These MSM characteristics are
`
`further described in connection with Figure 5.)
`
`-12-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01315
`
`Page 01315
`
`
`
`WO 98/37526
`
`PCT/GB98/0053 1
`
`Other data can also be stored on the card at this time as needed by the
`
`system design such as an address table or further subroutines.
`
`Step 311 sets the enablement bit in EEPROM of the card which indicates
`
`that the enablement process has been completed for the particular card. When this bit is
`
`set, another enablement process cannot occur on the card. This ensures that only one
`
`personalization and enablement process will occur to the card thus preventing illegal
`
`tampering of the card or altering the card by mistake. In the preferred embodiment, the
`
`enablement bit is initially not set when the card is manufactured and is set at the end of
`
`the enablement process.
`
`10
`
`15
`
`Figure 4 shows an example of a block diagram of an IC card chip which
`
`has been manufactured and personalized. The IC card chip is located on an IC card for
`
`use. The IC card preferably includes a central processing unit 401, a RAM 403, a
`
`EEPROM 405, a ROM 407, a timer 409, control logic 411, an I/O ports 413 and security
`
`circuitry 415, which are connected together by a conventional data bus.
`
`Control logic 411 in memory cards provides sufficient sequencing and
`
`switching to handle read-write access to the cards memory through the input/output
`
`ports. CPU 401 with its control logic can perform calculations, access memory locations,
`
`modify memory contents, and manage input/output ports. Some cards have a coprocessor
`
`for handling complex computations like cryptographic algorithms. Input/output ports
`
`20
`
`413 are used under the control of a CPU and control logic alone, for communications
`
`between the card and a card acceptance device. Timer 409 (which generates or provides a
`
`clock pulse) drives the control logic 411 and CPU 401 through the sequence of steps that
`
`_ 13 _
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01316
`
`Page 01316
`
`
`
`WO 98/37526
`
`PCT/GB98/0053 1
`
`accomplish memory access, memory reading or writing, processing, and data
`
`communication. A timer may be used to provide application features such as call
`
`duration. Security circuitry 415 includes fusible links that connect the input/output lines
`
`to internal circuitry as required for testing during manufacture, but which are destroyed
`
`(“blown”) upon completion of testing to prevent later access. The personalization data to
`
`qualify the card is stored in a secured location of EEPROM 405. The comparing of the
`
`personalization data to applications permissions data is performed by the CPU 401.
`
`Figure 5 shows the steps of generating and loading the four elements of
`
`the card personalization data into the memory of the IC cards, and Fig. 5A shows a
`
`10
`
`schematic of bit maps for each identity field residing in the memory of an IC card
`
`containing personalization data in accordance with the present invention. Each data
`
`structure for each identity field has its own descriptor code. Step 501 loads the data
`
`structure for the identity field “card ID" called “msm_mcd_permissions_mcd_no." This
`
`nomenclature stands for MULTOS system manager _ MULTOS card device _
`
`15
`
`20
`
`petmissions__ MULTOS card device number. Although this number is typically 8 bytes
`
`long as shown in Fig. 5A, the data could be any length that indicates a unique number for
`
`the card. In the preferred embodiment, 2 bytes are dedicated as a signal indicator, 2 bytes
`
`comprise a MULTOS Injection Security Module ID (MISM ID) indicating which security
`
`module injected the card with its injected keys when it was manufactured, and 4 bytes
`
`comprise an Integrated Circuit Card (ICC) serial number which identifies the individual
`
`card produced at the particular MISM.
`
`-14-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01317
`
`Page 01317
`
`
`
`\V()98t37526
`
`PCT/GB98/0053 1
`
`Step 503 loads the data structure for the identity field “issuer ID” called
`
`“msm_mcd_permissions_ mcd_issuer_id.” This nomenclature stands for a MULTOS
`
`card device issuer identification number. Each card issuer (such as a particular bank,
`
`financial institution or other company involved with an application) will be assigned a
`
`unique number in the card system. Each IC card in the MULTOS system will contain
`
`information regarding the card issuer which personalized the card or is responsible for the
`
`card. A card issuer will order a certain number of cards fi'om a manufacturer and perform
`
`or have performed the personalization process as described herein. For example, a
`
`regional bank may order 5,000 cards to be distributed to its customers. The
`
`10
`
`“mcd_issuer_id” data structure on these cards will indicate which issuer issued the cards.
`
`In the preferred embodiment, the data structure is 4 bytes long (as shown in Fig. 5A at
`
`503A) to allow for many different issuers in the system although the length of the data
`
`structure can vary with the needs of the card system.
`
`Step 505 loads the data structure for the identity field “product ID” called
`
`15
`
`“msm_mcd_perrnissions_mcd_ issuer_product_id.” This nomenclature stands for
`
`l\/IULTOS card device issuer product identification number. Each card issuer may have
`
`different classes of products or cards which it may want to differentiate. For example, a
`
`bank could issue a regular credit card with one product ID, a gold credit card with another
`
`product ID and a platinum card with still another product ID. The card issuer may wish
`
`20
`
`to load certain applications onto only one class of credit cards. A gold credit card user
`
`who pays an annual fee may be entitled to a greater variety of applications than a regular
`
`credit card user who pays no annual fee. The product ID field identifies the card as a
`
`-15-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page01318
`
`Page 01318
`
`
`
`W0 98/37526
`
`PCT/GB98/0053 1
`
`particular class and will later allow the card issuer to check the product ID and only load
`
`applications onto cards which match the desired class.
`
`Another way to differentiate products is by application type, such as by
`
`categorizing the application as financial, legal, medical and/or recreational, or by
`
`assigning particular applications to a group of cards. For example, one card issuer may
`
`have different loyalty programs available with different companies to different sets of
`
`card users. For example, a bank may have an American Airlines® loyalty program and a
`
`British Airways® loyalty program for different regions of the country dependent on
`
`where the airlines fly. The product type allows the issuer to fix the product classification
`
`10
`
`of the card during the personalization process. When loading applications onto the card,
`
`the product type identification number on each card will be checked to make sure it
`
`matches the type of card onto which the issuer desires to load. The product type data
`
`structure is preferably an indexing mechanism (unlike the other personalization data
`
`structure) of 8 bits (as shown at 505A in Fig. 5A) but could be any length depending
`
`15
`
`upon the needs of the card system. In the illustrated embodiment, the resulting
`
`instruction would be to locate the second bit (since the byte’s indicated value is 2) in the
`
`array to be searched (see discussion of step 809 below).
`
`Step 507 loads the data structure for the identity field data called
`
`“msm_mcd_permissions_mcd_ controls_data_ date.” This nomenclature stands for the
`
`20
`
`MULTOS card device controls data date or, in other words, the date on which the card
`
`was personalized so that, for example, the application loader can load cards dated only
`
`after a certain date, load cards before a certain date (e.g., for application updates) or load
`
`_15_
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01319
`
`Page 01319
`
`
`
`WO 98/37526
`
`PCT/GB98/0053 1
`
`cards with a particular data date. The information can include the year, month and day of
`
`personalization or may include less information, if desired. The data_date data structure
`
`is preferably 1 byte in length (see 507A in Fig. 5A) although it could be any length
`
`depending upon the needs of the particular card system used.
`
`Once all of the personalization data structures are loaded and stored in the
`
`card, the card has been identified by issuer, product class, date and identification number
`
`(and other data fields, if desired), and the card cannot change its identity; these fields
`
`cannot be changed in the memory of the card. If a card user wants to change the
`
`product_id stored in the card to gain access to different applications available to another
`
`10
`
`product type, a new card will have to be issued to the user containing the correct
`
`personalization data. This system is consistent with a gold card member receiving a new
`
`card when the classification is changed to platinum.
`
`Afler the card has been enabled and personalized by storing its individual
`
`card key set, MSM personalization characteristics and enablement bit as described in Fig.
`
`15
`
`3, the card is ready to have applications loaded into its memory.
`
`Loading Applications
`
`The application loading process contains a number of security and card
`
`configuration checks to ensure the secure and proper loading of an application onto the
`
`intended IC card. The application loading process is preferably performed at the
`
`20
`
`personalization bureau so that the card will contain one or more applications when the
`
`card is issued. The card may contain certain common applications which will be present
`
`_on every card the issuer sends out, such as an electronic purse application or a credit/debit
`
`-17-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01320
`
`Page 01320
`
`
`
`W0 98/37526
`
`PCT/GB98/00531
`
`application. Alternatively, the personalization bureau could send the enabled cards to a
`
`third party for the process of loading applications. The multiple application operating
`
`system stored in the ROM of each card and the card MSM personalization data is
`
`designed to allow future loading and deleting of applications after the card has been
`
`5
`
`issued depending upon the desires of the particular card user and the responsible card
`
`issuer. Thus, an older version of an application stored on the IC card could be replaced
`
`with a new version of the application. An additional loyalty application could also be
`
`added to the card after it has been initially sent to the card user because the application is
`
`newly available or the user desires to use the new application. These loading and deleting
`
`10
`
`functions for applications can be performed directly by a terminal or may be perfonned
`
`over telephone lines, data lines, a network such as the lntemet or any other way of
`
`transmitting data between two entities. In the present IC card system, the process of
`
`transmitting the application program and data ensures that only IC cards containing the
`
`proper personalization data and which fit on application permissions profile will be
`
`15
`
`qualified and receive the corresponding application program and data.
`
`Figure 6 shows the preferred steps perfonned in loading an application
`
`onto an IC card in the MULTOS IC card system. For this example, the personalization
`
`bureau is loading an application from a terminal which enabled the same card. Step 601
`
`performs an “open command” initiated by the terminal which previews the card to make
`
`20
`
`sure the card is qualified to accept the loading of a specific application. The open
`
`command provides the card with the application’s permissions data, the application’s
`
`size, and instructs the card to determine (1) if the enablement bit is set indicating the card
`
`-13-
`
`SUBSTITUTE SHEET (RULE 25)
`
`Page 01321
`
`Page 01321
`
`
`
`W0 9'8/37526
`
`PCT/GB98/0053 1
`
`has been personalized; (2) whether the application code and associated data will fit in the
`
`existing memory space on the card; and (3) whether the personalization data assigned to
`
`the application to be loaded allows for the loading of the application onto the particular
`
`card at issue. The open command could also make additional checks as required by the
`
`card system. These checking steps during the open command execution will be described
`
`in detail in conjunction with Figure 7.
`
`Afier the open command has been executed, the application loader via the
`
`terminal will be advised if the card contains the proper identification personalization data
`
`and if enough room exists in the memory of the card for the application code and related
`
`10
`
`data. If there is insufficient memory, then a negative response is returned by the card and
`
`the process is abended (abnormally ended). If the identification personalization data does
`
`not match the applications permissions data, a warning response is given in step 603, but
`
`the process continues to the load and create steps. Alternatively, if there is no match, the
`
`process may automatically be abended. If a positive response is returned by the card to
`
`15
`
`the terminal in step 605, the application loader preferably proceeds to next steps. The
`
`open command allows the application to preview the card before starting any transfer of
`
`the code and data.
`
`Step 607 then loads the application code and data onto the IC card into
`
`EEPROM. The actual loading occurs in conjunction with create step 609 which
`
`20
`
`completes the loading process and enables the application to execute on the IC card afier
`
`it is loaded. The combination of the open, load and create commands are sent by the
`
`terminal, or another application provider source, to the IC card to perform the application
`
`_ 19 _
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01322
`
`Page 01322
`
`
`
`WO 98/37526
`
`PCT/GB98/00531
`
`_
`
`A
`
`loading process. The operating system in the IC cards is programmed to perform a
`
`specific set of instructions with respect to each of these commands so that the IC card will
`
`communicate with and properly carry out the instructions from the terminal.
`
`Step 609 performs the create command which at least: (1) checks if an
`application load certificate is signed (encrypted) by the CA and therefore authenticates
`
`the application as a proper application for the system; and (2) checks the card
`
`personalization data stored on the card against the permissions profile for the application
`
`to be loaded to qualify the card for loading. It may do other checks as required. If one of
`
`the checks fails, then a failure response 610 is given and the process aborts. The
`
`10
`
`application afier it has passed these checks will be loaded into the memory of the card.
`
`Figure 7 shows the various steps of the open step 601 of Fig. 6 in more
`
`detail. Step 701 determines if the enablement (i.e., control) bit is set. This bit is set when
`
`the card has completed its personalization process and has been assigned its
`
`personalization data. An application can be loaded on an IC card in the card system only
`
`15
`
`if the card contains the personalization data. If the enablement bit is not set, the card has
`
`not been personalized and therefore the card returns a negative response 703 to the
`
`terminal. If the enablement bit is set, then the card has been enabled and the test
`
`conditions continue with step 711.
`
`Step 711 checks if there is sufficient space in the memory on the card to
`
`20
`
`store the application code and its associated data. Applications will typically have
`
`associated data related to their functions. This data will be used and manipulated when
`
`the applicationis run. Storage space in the memory of an IC card is a continuing concern
`
`_ 20 _
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01323
`
`Page 01323
`
`
`
`WO 98/37526
`
`PCT/GB98/00531
`
`_
`
`‘
`
`due to the relatively large physical space required for EEPROM and how it fits in the
`
`integrated circuit which is desired to be small enough to fit on a credit card sized card.
`
`An example of the size of a preset EEPROM on an IC card is 16K bytes although the
`
`actual size varies. Applications can range from 1K byte or less for a very simple
`
`5
`
`application up to the size of available memory for a more sophisticated application.i The
`
`data associated with an application can range from no data being stored in the card
`
`memory to a size constrained by the amount of available memory. These varied sizes of
`
`application code and data continually increase as applications become more advanced and
`
`diverse.
`
`10
`
`MULTOS as an operating system is not limited by the number of
`
`applications and associated data it can store on the card. Thus, if five applications can fit
`
`in the available memory of the card, the card user will have greatly increased
`
`fiinctionality than if one or two applications were stored on the card. Once a card’s
`
`memory is filled to its capacity, however, a new application cannot be loaded onto the
`
`15
`
`card unless another application including its code and data of sufficienr size can be
`
`deleted. Therefore, checking the amount of available space on the card is an important
`
`step. If there is not sufficient space, then an insufficient space response 713 will be
`
`retumed to the terminal. The application loader can then decide if another existing
`
`application on the card should be deleted to make room for the new application. Deletion
`
`20
`
`depends upon the card issuer having an application delete certificate from the CA. If
`
`there is sufficient space on the card, then the process continues with step 715.
`
`-21-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01324
`
`Page 01324
`
`
`
`wo 9'8/37526
`
`PCT/GB98/0053 1
`
`An example of the testing of memory spaces in step 711 is now described.
`
`The numbers used in this example in no way limit the scope of the invention but are used
`
`only to illustrate memory space requirements. An IC card may have 16K available
`
`EEPROM when it is first manufactured. The operating system data necessary for the
`
`operating system may take up 2K of memory space. Thus, 14K would remain. An
`
`electronic purse application’s code is stored in EEPROM and may take up 8K of memory
`
`space. The purse application’s required data may take up an additional 4K of memory
`
`space in EEPROM. The memory space which is free for other applications would thus be
`
`2K (16K-2K-8K-4K=2K). If a card issuer wants to load a credit/debit application whose
`
`10
`
`code is 6K bytes in size onto the card in this example, the application will not fit in the
`
`memory of the IC card. Therefore, the application carmot load the new application
`
`without first removing the purse application from the card. If a new credit/debit
`
`application was loaded into EEPROM of the IC card, then it would have to overwrite
`
`other application’s code or data. The application loader is prevented from doing this.
`
`15
`
`Figure 8 shows the steps performed in determining whether the card’s
`
`personalization data falls within the permissible set of cards onto which the application at
`
`issue may be loaded. These steps are preferably performed during the execution of the
`
`“create” command. However, these steps may be performed at any time during the
`
`loading or deleting of an application. As described previously, the card is personalized
`
`20
`
`by storing data specific to the card (MSM personalization data) including: a card ID
`
`designation specific to an individual card, the card issuer number indicating the issuer of
`
`the card, the product type of the card, such as a gold or platinum card, and the date the
`
`-22..
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01325
`
`Page 01325
`
`
`
`W0 98/37526
`
`PCT/GB98/00531
`
`card was personalized. This data uniquely identifies the card apart from all other IC cards
`
`in the system.
`
`Accordingly, applications can be selectively stored on individual cards in
`
`the IC card system on virtually any basis, including the following. An application can be
`loaded selectively to cards containing one or more specific card numbers. An application
`
`can be selectively loaded on one or more cards containing a specified card issuer ID.
`
`Moreover, an application can be loaded only upon one type of product specified by the
`
`particular card issuer, and/or the application can be loaded only on cards which have a
`
`specified date or series of dates of personalization. Each of the personalization data
`
`10
`
`allows an application to be selectively loaded onto certain cards or groups of cards and
`
`also ensures that cards without the prop er permissions will not receive the application.
`
`Personalization data types in addition to the four described can also be used as needed.
`
`The selection of IC cards upon which a particular application may be
`
`loaded is made possible by the use of “applications permissions data” which is assigned
`
`15
`
`to the application and represents at least one set of cards upon which the application may
`
`be loaded. The set may be based on virtually any factor, including one or more of the
`
`following: card numbers, card issuers, product types or personalization dates. Although
`
`the individual card’s personalization data typically identify one specific number, one card
`
`issuer, one product type and one date, the application’s permissions data may indicate a
`
`20
`
`card numbers or a blanket permission, a card issuer or a blanket permission, and a
`
`number of product types and dates.
`
`_ 23 _
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01326
`
`Page 01326
`
`
`
`W0 9+8/37526
`
`PCT/GB98/00531
`
`For example, a fi'equent loyalty program may be configured to allow its
`
`loading and use on cards in different product classes belonging to one card issuer. In
`
`addition, the application permissions data may indicate that the loyalty program can be
`
`used on gold and platinum product types if the card was issued afier May, 1998. Thus,
`
`the MSM permissions check will determine if the card’s individual personalization data is
`
`included in the allowed or permissible set of cards upon which the application may be
`
`loaded. If it is, the application will be loaded.
`
`To expedite the comparison process, an alternative embodiment may
`
`include setting one or more permissions data at zero representing a blanket permission for
`
`10
`
`that particular data. For instance, by placing a zero for the “card number" entry in the
`
`application permissions data or some other value indicating that all cards may be loaded
`
`regardless of their number, the system knows not to deny any cards based on their card
`
`number. Moreover, if a zero is placed in the application’s permissions data “issuer ID,”
`
`then all cards similarly will pass the “issuer” test comparison. This feature allows greater
`
`15
`
`flexibility in selecting groups of cards. The zero indicator could also be used for other
`
`permissions data, as required.
`
`Referring to Figure 8, each of the permissions data is checked in the order
`
`shown, but other orders could be followed because if any one of the permissions fails, the
`
`application will be prevented fi'om being loaded on the IC card being checked. The
`
`20
`
`permissions are preferably checked in the order shown. Step 801 checks if the
`
`application permissions product type set encompasses the card’s product type number
`
`stored in the memory of the card. Each card product type is assigned a number by the
`
`_ 24 ..
`
`SUBSTlTUTE SHEET (RULE 26)
`
`Page 01327
`
`Page 01327
`
`
`
`W0 >98/37526
`
`PCT/GB98/00531
`
`system operator. The product types are specified for each card issuer because different
`
`card issuers will have different product types. The cards are selectively checked to ensure
`
`that applications are loaded only on cards of authorized product type. The application
`
`permissions product type set can be 32 bytes long which includes multiple acceptable
`
`product types or can be a different length depending upon the needs of the system. Using
`
`data structure 505A as an example, the operating system would check bit number 2 in the
`
`256 bit array (32 bytes x 8 bits per byte) resulting from the 32 byte long application
`
`permissions data structure. If the permissions check fails, then the card returns a failure
`
`message to the terminal in step 803. If the product type check passes (for example, the
`
`10
`
`value of bit no. 2 being 1), then the process continues with step 805.
`
`Step 805 checks if the application permissions allowable card issuer
`
`number set encompasses the card’s issuer number stored in the memory of the card or if
`
`the application permissions issuer data is zero (indicating all cards pass this individual
`
`permissions check). Each card issuer is assigned a number by the system operator and
`
`the cards are selectively checked to ensure that applications are loaded only on cards
`
`distributed by authorized card issuers. The application permissions card issuer number
`
`set can be 4 bytes long if one issuer is designated or can be longer depending upon the
`
`needs of the system. If the issuer check fails, then the card returns a failure message to
`
`the terminal in step 807. If the check passes, then the process continues with step 809.
`
`Step 809 checks if the application permissions date set encompasses the
`
`15
`
`20
`
`card’s data date stored in the memory of the card. The date that the IC card was
`
`personalized will be stored and will preferably include at least the month and year. The
`
`-25 ._.
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 01328
`
`Page 01328
`
`
`
`WO 98/37526
`
`PCT/GB98/00531
`
`cards are selectively checked to ensure that applications are loaded only on cards with the
`
`authorized personalization date. The application permissions date set can be 32 bytes
`
`long which includes multiple dates or can be a different length depending upon the needs
`
`of the system. If the date permissions check fails, then the card returns a failure message
`
`to the terminal in step 81 1. If the date check passes, then the process continues with step
`
`813.
`
`Step 813 checks if the application permissions allowable card number set
`
`encompasses the card’s ID number stored in the card memory or if the application
`
`permissions allowable card number data is zero (indicating all cards pass this individual
`
`10
`
`permissions check). The testing of the permissions is performed on the card during the
`
`execution of the open, load and create commands. The application permissions card
`
`number data set can be 8 bytes long if one number is designated or can be longer
`
`depending upon the needs of the system. If the card number check fails, then the card
`
`returns a failure message to the terminal in step 815. If the check passes, then the process
`
`15
`
`continues with step 817.
`
`ma
`
`of
`
`rd
`
`ste
`
`’s
`
`oce
`
`Figure 9 shows the components of the system architecture for the card
`
`initialization process of an IC card in a secure multiple application IC card system. The
`
`system includes a card manufacturer 102, a personalization bureau 104, an application
`
`20
`
`loader 106, the IC card 107 being initialized, the card user 109 and the certification
`
`authority 111 for the entire multiple application secure system. The card user 131 is the
`
`_.26..
`
`SUBSTITUTE SHEET (RULE 25)
`
`Page 01329
`
`Page 01329
`
`
`
`WO 98/37526
`
`PCT/GB98/00531
`
`person or entity who will use the stored applications on the IC card. For example, a card
`
`user may prefer an IC card that contains both an electronic purse containing electronic
`
`cash (such as MONDEXTM) and a credit/debit application (such as the MasterCard®
`
`EMV application) on the sa.me IC card. The following is a description of one way in
`
`which the card user would obtain an IC card containing the desired applications in a
`
`secure manner.
`
`The card user would contact a card issuer 113, such as a bank which
`
`distributes IC cards, and request an IC card with the two applications both residing in
`
`memory of a single IC card. The integrated cir