Registers – Records – Conductive
Reexamination Certificate
2001-10-30
2004-07-13
St.Cyr, Daniel (Department: 2876)
Registers
Records
Conductive
C235S487000
Reexamination Certificate
active
06761319
ABSTRACT:
RELATED APPLICATIONS
This application is related to U.S. patent application Ser. No. 09/076,551 filed on May 12, 1998 entitled “Secure Multiple Application Card System and Process,” which is incorporated herein by reference.
BACKGROUND OF INVENTION
Integrated circuit cards are becoming increasingly used for many different purposes in the world today. An IC card typically is the size of a conventional credit card on which a computer chip is embedded. It comprises a microprocessor, read-only-memory (ROM), electrically erasable programmable read-only-memory (EEPROM), an Input/Output(I/O) mechanism and other circuitry to support the microprocessor in its operations. An IC card may contain one or more applications in memory. MULTOS™ is a multiple application operating system which runs on IC cards, among other platforms, and allows multiple applications to be executed on the card itself. This allows a card user to run many programs stored in the card (for example, credit/debit, electronic money/purse and/or loyalty applications) irrespective of the type of terminal (i.e., ATM, telephone and/or POS) in which the card is inserted for use.
IC cards typically have limited storage capacity due to the size and cost restraints of locating memory o n the card. Applications for multi-application smart cards are written in a programming language and are typically stored in the EEPROM whose contents can be changed during the lifetime of the card. One example of a programming language used in IC cards is the Multos Executable Language (MEL™). The MEL program instructions are read from EEPROM when they are executed and are interpreted by the operating system stored in ROM.
The ROM on the IC card includes the operating system written in assembler language code for the particular integrated circuit configuration (native language type code). The operating system code stored in ROM is fixed when the ROM is initially written and the information stored in ROM will not change for the life of the card.
Also present in ROM can be subroutines called primitives written in a native language code for the microprocessor which can be called by either the operating system itself or by applications when they are executed. Primitives are written in native language (i.e. assembler language) so that they can be executed very quickly and minimal interpretation of the instructions is necessary for execution. These primitives are collections of instructions which typically perform a desired function, such as a mathematical or cryptographic function. The instructions are never changed during the lifetime of the card. Any data used or accessed by the primitives are stored in EEPROM so that the contents of the data elements can change as necessary.
Also capable of being stored in ROM are “codelets,” which are sets of instructions written in a programming language (not native language code). These codelets can be stored in ROM so as to maximize the usage of memory and allow ROM to store complete applications as well as primitives. The codelet can be as small as one instruction or as large as will fit into the remaining ROM memory space. For example, the purse application described above can be stored in ROM when the card is initialized in order to free up space in EEPROM for additional applications which can be loaded at any time.
Once data is stored in ROM, the data can never be modified or deleted and new data cannot be added after ROM is set. Moreover, in prior art systems, when the chip card is manufactured, a primitive address table is stored on the card which allows the operating system to locate the memory address of a primitive. This address table in ROM is also permanently set.
In this system, described in an application copending with this one (see Ser. No. 09/076,551, incorporated herein by reference), subsequent to card manufacture (at which time the ROM is fixed), the card is “personalized.” This personalization step takes place either shortly after the card is made or anytime thereafter, up to a period of months or more. In the meantime, before the card is personalized, cards remain “blank” (i.e., unassigned to an individual user or group) and typically will be held at the card manufacturer or card issuer until needed. During this stage, because the cards have not yet been personalized, there is a greater risk that the cards would be improperly used.
The personalization step—in which the cards are assigned to a particular user or group—takes place at a location different from the card manufacturer generally under control of the card-issuer (i.e., the bank issuing the card) or some other personalization bureau (“PB”). A separate and preferably centrally located Certification Authority, which oversees the cards' interaction, provides the usually remote PB with appropriate security data, discussed below, to allow the PB to personalize (i.e., enable) the card, and to allow an application provider to load (either at the time of enablement or later) an application program, such as a purse application, onto the card.
One of the problems confronting multi-application card designers is how to address the situation where after the primitive or codelet is masked or otherwise stored in the ROM at the time of manufacture (and thus cannot thereafter be changed), the primitive or codelet needs to be replaced, modified or updated to fix a bug or to take advantage of a more efficient or effective routine. Another concern is to insure that the original primitives and codelets masked into ROM are not capable of use until the card is personalized, i.e. enabled for a particular user or group, with individual keys and identifiers. Accordingly it is an object of the invention to provide a method and system which solves these problems.
SUMMARY OF THE INVENTION
The applicant here has determined that one way to achieve these objectives is by loading in EEPROM at the personalization step and not at the manufacturing step an address table assigning to each primitive and/or codelet a name and corresponding address identifying where the primitive and/or codelet can be found in memory. In this manner, if the primitive masked in ROM at the time of manufacture needs to be changed, only the address for that primitive needs to be changed to point to the location in which the updated primitive sits. In addition, since neither an application nor the operating system will know where the primitive is located without a stored address table, the primitives cannot be called and the card cannot run until the primitive address table is loaded at the personalization step. This prevents use of the card until it is enabled at the personalization step.
REFERENCES:
patent: 4214230 (1980-07-01), Fak et al.
patent: 4218582 (1980-08-01), Hellman et al.
patent: 4259720 (1981-03-01), Campbell
patent: 4302810 (1981-11-01), Bouricius et al.
patent: 4305059 (1981-12-01), Benton
patent: 4321672 (1982-03-01), Braun et al.
patent: 4341951 (1982-07-01), Benton
patent: 4405829 (1983-09-01), Rivest et al.
patent: 4408203 (1983-10-01), Campbell
patent: 4423287 (1983-12-01), Zeidler
patent: 4442345 (1984-04-01), Mollier et al.
patent: 4453074 (1984-06-01), Weinstein
patent: 4467139 (1984-08-01), Mollier
patent: 4498000 (1985-02-01), Decavele et al.
patent: 4536647 (1985-08-01), Atalla et al.
patent: 4578530 (1986-03-01), Zeidler
patent: 4605820 (1986-08-01), Campbell, Jr.
patent: 4629872 (1986-12-01), Hällberg
patent: 4630201 (1986-12-01), White
patent: 4650978 (1987-03-01), Hudson et al.
patent: 4669596 (1987-06-01), Capers et al.
patent: 4705211 (1987-11-01), Honda et al.
patent: 4709136 (1987-11-01), Watanabe
patent: 4709137 (1987-11-01), Yoshida
patent: 4727243 (1988-02-01), Savar
patent: 4727244 (1988-02-01), Nakano et al.
patent: 4731842 (1988-03-01), Smith
patent: 4734568 (1988-03-01), Watanabe
patent: 4736094 (1988-04-01), Yoshida
patent: 4742215 (1988-05-01), Daughters et al.
patent: 4745267 (1988-05-01), Davis et al.
patent: 4746788 (1988-05-01), Kawana
patent: 4748557 (1988-05-01), Tamada et al.
patent: 4748668 (1988-05-01), Shamir et al.
patent:
Peachman Anthony David
Simmons Ian Stephen
Baker & Botts L.L.P.
Mondex International Limited
St.Cyr Daniel
LandOfFree
Configuration of IC card does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Configuration of IC card, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Configuration of IC card will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3192087