Registers – Records – Conductive
Reexamination Certificate
2001-08-31
2004-08-24
Tremblay, Mark (Department: 2876)
Registers
Records
Conductive
C705S065000
Reexamination Certificate
active
06779732
ABSTRACT:
BACKGROUND
1. Field of the Present Invention
The present invention generally relates to the field of smart cards and more particularly to an improved smart card and method for resolving unresolved references within converted applet files loaded into a smart card.
2. History of Related Art
Most consumers are familiar with and use credit cards, debit cards, automatic teller machine (ATM) cards, stored value cards, and the like. For many types of transactions, however, the current trend is away from these types of cards and into a class of devices generally referred to as smart cards. A smart card is a plastic, credit-card sized card that includes an electronic device (chip) embedded in the card's bulk plastic. Rather than only employing a magnetic strip to store information, smart cards employ a microprocessor and a memory element embedded within the chip.
Because they have a chip, smart cards can be programmed to operate in a number of varied capacities such as stored value cards, credit cards, debit cards, ATM cards, calling cards, personal identity cards, critical record storage devices, etc. In these varied capacities, a smart card may be designed to use a number of different application programs. Smart cards are compliant with Standard 7816 Parts 1-10 of the International Organization for Standardization (ISO), which are incorporated by reference herein and referred to generally as “ISO 7816.” Smart cards are resource-constrained devices, and as such, have minimal memory configurations typically on the order of 1K or 2K of random access (volatile) memory (RAM), 16K or 32K of non-volatile read/write memory such as an electrically erasable programmable read only memory (EEPROM), and 24K of read only memory (ROM). The term “EEPROM” is used throughout to broadly refer to non-volatile (i.e., persistent) memory, including flash memory. Initially, application program development for smart cards was essentially proprietary. That is, each smart card's software was specific to the design of its embedded microprocessor; with the end result being an extremely limited ability for the development of applications that could run on cards produced by different manufacturers. As a result, smart card application development was limited to a relatively small group of developers who either worked for the smart card manufacturers or the smart card issuers.
In recent years, however, smart card application development has evolved so that it is no longer proprietary. Through the adoption of open architectures for application development, it is now possible to develop applications that can run on smart cards from different manufacturers as well as other resource constrained devices that, like smart cards, have small amounts of available memory or other devices for the storage of data (i.e., storage devices). Java Card technology is an example of one such open development architecture. It uses the Java™ programming language and employs the Java Card runtime environment (JCRE). The JCRE conforms to ISO 7816 and defines a platform on which applications written in the Java programming language can run on smart cards and other resource-constrained devices. Applications written for the JCRE are referred to AS applets.
Before an applet can be loaded onto a smart card for execution, however, the source code of the applet must be converted into a corresponding binary representation of the classes making up the applet. This corresponding binary representation is referred to as a CAP file (converted applet file) and is the file format in which applications are loaded onto smart cards utilizing the JCRE. The CAP file is typically loaded as a block of bytes occupying contiguous space in the non-volatile read/write memory of the smart card by an installer module located on the smart card.
Each CAP file may contain calls to various symbolic or unresolved code references which must be resolved prior to execution. The terms “call” or “calling” are used throughout to broadly describe a relationship between two pieces of code in which one piece invokes the other. Commands, functions, definitions, etc. may typically be invoked by having code within the application call another piece of code, with the latter piece of code residing within the application itself or in a library of functions present on the smart card. The process of resolving these calls to unresolved code references is generally referred to as linking or resolution and involves looking-up the symbolic reference in a corresponding table present in memory (constant pool) or other storage device or calculating the unresolved relative code reference and replacing the reference with the actual memory address or an internally accessible symbolic reference at which the particular command, function, definition, etc. is stored. While the linking or resolution process typically applies to unresolved references in computer code, the process may be applied to any construct used for storing or manipulating data (i.e., data structures) with unresolved references contained therein. The terms “resolve,” “resolution,” and “resolving” are used throughout to broadly describe the foregoing process of replacing the unresolved code or symbolic reference within the code or data structure with an internally accessible symbolic reference or actual memory address.
Linking is traditionally accomplished on-card by the card's installer module utilizing non-volatile read/write memory. As noted above, the non-volatile read/write memory of a smart card typically consists of EEPROM. Characteristics of EEPROM technology result in an access and write to EEPROM requiring a significantly greater time than a corresponding access and write to RAM. Further, EEPROM's have a limitation on the number of times they may be written (typically on the order of tens or hundreds of thousands of times). Consequently, performing the required linking process for the CAP file in EEPROM is time consuming and impacts the operational life of the EEPROM. Accordingly, it would be beneficial to implement an apparatus and method for the efficient linking of CAP files that minimizes the number of writes to the EEPROM.
REFERENCES:
patent: 5734822 (1998-03-01), Houha et al.
patent: 5999732 (1999-12-01), Bak et al.
patent: 6338160 (2002-01-01), Patel et al.
patent: 0 964 370 (1999-12-01), None
patent: 0964370 (1999-12-01), None
patent: WO 99/49392 (1999-09-01), None
patent: WO 00/46667 (2000-08-01), None
“Sun Rises over Smart Cards” 1998 Advanced Card Technology Sourcebook, Faulkner & Gray, 1997, pp. 150-154.*
Fodor, O. et al. “JavaCard and OpenCard Framework :a tutorial” Emerging Technologies and Factory Automation, 1999. Proceedings. ETFA '99.1999 17th IEEE International Conference, Barcelona, Spain Oct. 18-21 1999, Piscataway, NJ, USA, IEEE, US, Oct. 18, 1999.
International Search Report in PCT/US02/25650 dated Feb. 3, 2003 (5 pages).
Burianne Yannick
Krishna Ksheerabdhi
Wilkinson Tim
Batzer William
Jansson Pehr B.
Ryberg John J.
Schulumberger Malco, Inc.
Tremblay Mark
LandOfFree
Method and apparatus for linking converted applet files does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for linking converted applet files, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for linking converted applet files will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3342516