Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-04-29
2004-08-03
Jung, David (Department: 2134)
Data processing: database and file management or data structures
Database design
Data structure types
C711S100000, C707S793000, C707S793000
Reexamination Certificate
active
06772171
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to a method and a device for creating an object in a non-persistent memory. More particularly, the coexistence of persistent and temporary objects in a runtime system for object-based languages is proposed, more particularly for implementation in a virtual machine in a resource-constrained environment such as a smartcard, particularly a smartcard offering a Java environment, such as a Javacard. Furthermore a method is proposed which maintains accessibility of non-persistently stored objects even for several methods of an applet.
TECHNICAL FIELD AND BACKGROUND OF THE INVENTION
As one area of application for the invention, the area of smartcards is suitable, which herein is used henceforth to exemplify the concepts. One of the uses of a smartcard is to store long-life data. Therefore a smartcard contains primarily persistent storage (ROM, EEPROM) and only a limited amount of temporary storage (RAM). The ROM is used to store constant data and code which is valid during the lifetime of a smartcard. Applications can either be stored in ROM during the production process or can be loaded into EEPROM.
As soon as a card is inserted into a device providing power, clock, and communication lines, which device is also called the “terminal”, the card is powered on and the runtime environment takes over the control of the system and waits for input from the terminal. The terminal starts a communication with an application by sending a command to the runtime environment, i.e. a select-command, to select an application for further interaction, the so-called “target application”. After that, the runtime environment forwards all incoming data to the selected application by invoking the application with the given data. The application processes the data and might create data for the response to the terminal. After the application has finished processing the incoming data, control returns to the runtime environment which sends the response to the terminal. The terminal can now send again data to the selected application. The terminal can also close the communication with the current selected application by sending a new select-command to the runtime environment. The runtime environment informs the currently selected application thus allowing cleanup operations to be performed and afterwards selects the new application. New messages are again forwarded to the newly selected application by invoking the application with the message as argument. The number of selections and messages during a session are not limited. Both the interaction pattern between terminal and card, as well as the separation into runtime and application on the card are important to maintain the integrity of a card running multiple applications. If this separation were not in place, applications could possibly interact in malign ways, e.g. by checking the messages originally intended for other applications.
During a message-driven invocation by the runtime environment as outlined above, an application must be able to create, manipulate and store objects. If an object is desired to be available in an application between different selections, the application needs to store this object in persistent memory, thus making the object accessible after a card insertion in a terminal at a later time.
If transient memory is also available, the system has to provide a functionality to support transient objects therein. The common use of EEPROM as storage technology for transient objects is disadvantageous in several respects. First, modifying-operations on objects in EEPROM are very slow compared to write-operations into RAM. Second, due to technology, the guaranteed number of successful write-operations to a cell in EEPROM is limited. Third, objects in the persistent memory can more easily be scrutinized, since they continue to reside on the card even after power down, thus leading to potential security vulnerabilities.
Object-based applications running inside extremely resource-constrained execution environments, such as smartcards, should be able to create and manipulate persistent and temporary objects. In this context, persistent objects are objects which keep their state between different hardware activations, also called “sessions” and are therefore protected from the effects of (sudden) power down. An e-cash application, for example, may use a persistent object to store the available amount of money between sessions.
In contrast, temporary objects are allocated in temporary memory and are lost at power down. The use of temporary objects increases the performance of an application and provides additional security. The first is due to the vastly reduced access-time to temporary memory as opposed to persistent memory. Secondly, temporary objects containing security-sensitive data are cleared automatically at power down. Therefore, this data cannot be examined after the device has been removed from its power supply.
Conventional systems supporting some form of coexistence of persistent and transient objects typically tend to be complex and accordingly require many resources. Particularly in a resource-constrained environment, it is crucial to reduce this, even when the functionality is thereby reduced. One known mechanism allows to create only certain types of temporary or transient objects, i.e. in form of simple types like short arrays or byte arrays. This reduced functionality is however too restrictive for a number of applications, especially for object-oriented applications.
OBJECT AND ADVANTAGES OF THE INVENTION
A mechanism for supporting persistent and temporary objects in a resource-constrained environment is the proposed solution for the above described problem.
It only requires minimal support by the runtime system, while still providing a simple programming model for both temporary- and persistent object allocation. Moreover, it supports the maintenance of temporary objects between multiple invocations of an application during one session without using persistent memory. It also enables an application to ensure its integrity in case of an unexpected power down.
It is an object of the invention according to claim
1
and
11
, to provide a method and a device for creating an object in a non-persistent memory which offers a bigger flexibility in the choice of the object type and at the same time is suited to be implemented in a resource-constrained environment, such as a smartcard, particularly a smartcard offering a Java environment.
Another advantage is the reduced complexity in the allocation of temporary and persistent objects.
The above mentioned objects are met by a method according to claim
1
and a device according to claim
11
. Regardless of whether the interpreter, also called “virtual machine”, is implemented in software or in hardware, the above problems are solved.
The setting of a sort of marker, i.e. calling a first function which effects the choice of a non-persistent memory as the memory where in a following step an object is created, offers a simple way of switching between the persistent memory and the non-persistent memory.
The use of a function of a bracket-open type is advantageous because a function with a similar functionality, i.e. marking the beginning of a phase or state and marking the end of this phase or state, for other purposes is already known, such that the handling of the bracket function is facilitated by corresponding know-how. The additional complexity to implement the recognition of this function and the correct handling of its meaning, thereby is kept at minimum.
The counterpart is the third function which handles the resetting of the mark. This exploits all advantages of the first function and completes the set of functions such that hence deliberate switching of the storing location for the objects is made possible. Also for this function the advantage counts that a function with a similar functionality, i.e. marking the beginning of a phase or state and marking the end of this phase or state, for other purposes is already known, such that t
Baentsch Michael
Buhler Peter
Eirich Thomas
Hoering Frank
Oestreicher Marcus
Aker David
Herzberg Louis P.
Jung David
LandOfFree
Method and device for creating an object in a non-persistent... 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 device for creating an object in a non-persistent..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device for creating an object in a non-persistent... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3344061