Title of Invention

"METHOD AND COMPUTER DEVICE FOR DYNAMIC MEMORY MANAGEMENT OF DATA OBJECTS"

Abstract

A method and device for dynamic memory management of data objects (10,12) in SmartCards (8), in particular in JavaCards, are the subject of the invention. It is proposed to implement an object and methods for individual memory objects (10,12) on the SmartCard which are capable of managing memory in full during the runtime of a card program, in particular a Java applet. This memory management includes the conventional functions such as writing, reading, editing, memory allocation, deallocation and' - as an additional, optional feature - memory defragmenting. In a preferred embodiment of the present invention, the memory or data objects (10, 12) created by the above-mentioned dynamic memory management are no longer used for detailed logical structuring of the data, but only for a rough logical structuring of 'all data objects of one applet or several. Within the data objects the data {14, 16, 18, 21, 22) are administered with a logical directory system.

Full Text

Field of the invention: The invention relates to method and computer device for dynamic memory management of data objects. Description Of The State Of The Art And Its Disadvantages: The devices mentioned at the beginning are primarily devices for general usage having, in comparison with a desktop computer, only a low level of computing power and not programmed with the support of advanced programming concepts. For the purpose of disclosure of the present invention the examples cited are SmartCards-that is cards on which a small memory chip with its own microprocessor is mounted. On the chip data can be stored which enable a wide variety of business processes in conjunction with a host application- for example the cash dispenser program in a cash machine. The level of acceptance of these chipcards is very high, and their possible applications and the fields in which they can be applied are growing rapidly. There are two sort of SmartCards: firstly the file system-oriented SmartCards, which use the ISO 7816-4 interface as their protocol for communication with host applications and on which a directory system precisely structuring and specifying the memory for data of the host application which accesses the SmartCard is created when the card is initialized. A directory system of this kind manages the entire memory available on the SmartCard. The disadvantage of; these so-called ISO SmartCards, however, is that assembler code needs to be used to program the application's 'which access the memory. This is highly inconvenient for the programmer, and advanced programming techniques cannot be applied to applications' for such cards. Secondly, there are object-oriented SmartCards, which meet the need for storage on the SmartCard even of small application programs which are run when the card is inserted into a SmartCard reader. These programs, which work independently of the host application, are capable of executing individual, minor business processes autonomously depending on the field of application. These applications are written in the Java programming language, which is why the cards are called JavaCards. JavaCards support object-oriented programming, which opens up the interface to modern programming techniques. Ultimately, by means of these modern techniques applications can be written in a highly efficient way, application code can be reused, and standardized interfaces utilized. Nonetheless, the memory capacities and computing power of SmartCards especially remain generally limited. Matching the rising demand for JavaCard applications, the need to accommodate more than just one application on a card has also become greater. Consequently, the trend is toward so-called 'Multi-Application1 SmartCards. In response to that trend, a number of service providers are increasingly working together in order to relieve customers of certain tasks, to create special incentives for them, or to enable special services. Examples include the way airlines are collaborating with car hire companies and/or hotel chains to offer customers a special level of service based on specific discounting systems and forward reservation facilities. This does, however, require that the logical links between the application programs of all the companies involved should as far as possible be stored on one SmartCard, and that the collaboration between the companies does not demand three separate SmartCards. Data exchange from one card to another in such a system would be highly inconvenient, and not acceptable to customers. If, in the course of the increasing convergence of corporate services, a new version of an existing SmartCard is to be issued to support and interact with the services offered by two new companies in terms of the services outlined above, an upgrade of the card is essential. Such upgrades, or expanded memory requirements, occurring only during the runtime of a Java applet are very inconvenient to perform on state-of-the-art Java SmartCards, since the JavaCards only store programs, and the sizes of the individual data fields accessed by the application programs on JavaCards - the so-called Java applets - are statically allocated as soon as the applet is loaded onto a JavaCard. Such static allocation of memory is very inflexible in the event of changes or memory upgrades. Moreover, the memory taken up by the data objects is statically fixed regardless of the size of the data stored in the data objects. This means, firstly, that a large amount of memory is left unused when small volumes of data are stored in a large data object at the preset locations during the runtime of the applet. On the other hand, the stored data are logically structured only by way of the allocated data objects, a feature which is disadvantageous for programming of applets, since each individual data field must have a unique, separate name to be accessed by the applet. This is shown in Fig. 1 based on personal data records. In the separate circles the diagram presents data objects of a JavaCard applet on which the address data of two people can be stored - namely, memory locations for the name of a person: Namel, Name2; for the telephone number: Tel.l, Tel.2; or the address data: Str.l, Str.2, Adr.l, Adr.2. The size of these data objects must be set at the time of creation of the applet. The memory is allocated regardless of whether all Objects are required during the runtime or not. The data objects are defined separately, independently of each other, as is indicated by the individual, unconnected circles in the SmartCard schematic. A further disadvantage is that a Java applet is not able to access data of another Java applet, because each applet protects its own data. Consequently, if two applets require two identical data records they must be stored in duplicate on the card. This means memory is not being utilized efficiently. The object of the task at hand is therefore to program JavaCards in such a way that the memory available on a JavaCard for data is managed dynamically and efficiently and that data records can be addressed by several different applets. 3. SUMMARY AND ADVANTAGES OF THE INVENTION The objects cited are fulfilled by the characteristics set out in the independent Claims Advantageous enhancements of the invention result from the respective subclaims. The fundamental concept of the present invention is based on the idea of combining the benefits of directory system-oriented SmartCards and of JavaCards in order to fulfill the object set out above. This is realized in accordance with the invention in that the particular advantage of JavaCards - namely their facility to implement objects and associated methods- on SmartCards - is utilized to produce the advantage of the directory system-oriented SmartCards: Consequently, following an aspect of the present invention for object-oriented SmartCards, it is proposed to implement an object and methods for individual memory objects on the SmartCard capable of managing memory fully within the runtime 6f a card program, in particular a Java applet. This memory management includes the conventional functions such as writing, reading, editing, memory allocation, deallocation and - as an additional, optional feature - memory defragmenting. A further additional feature of the present invention is the facility to render the same memory management object addressable for all applets on the JavaCard. In a preferred embodiment of the present invention the memory or data objects created by the above-rnentioned\,,dynamic memory management are no longer used for detailed logical structuring of the data, but only for a rough logical structuring of all data objects of one applet or for access by several. Within the data objects, the data are administered with a logical directory system which resides on the JavaCard as code in the form of a so-called memory management object with associated methods, according to a preferred embodiment of the inventive concept adapted to object-oriented SmartCards. Depending on application requirements, the code for management of the directory system is coded in the applet itself, but may also be stored in the card's operating system or at another location, and be called up by one or more applets. By transferring the inventive concept to ISO file system cards, use of the resultant flexible file system within data Objects thus also solves the problem of dynamic generation of layouts, i.e. the,, formatting of the complete memory system on those cards, by the host application or 'Off-Card1 application. This is essential in particular in the case of dynamic, object-oriented applications in which tne card layout is only generated during the runtime from so-called high-level objects. These high-level objects form a universal component of the interface between the host application program and card application program, and, represent placeholders for data and Command exchange operations which are not filled out with concrete implementations by the corresponding data or commands until during the runtime, and then generate the memory requirements, which occur more or less spontaneously during the runtime of an applet. The advantages of the inventive concepts can therefore be summarized as follows: An "automatic memory management' function is enabled within data objects of an applet by means of the directory system. As a result, memory is dynamically available at the locations at which it is required during the runtime of the applet. Consequently less memory is taken up than in conventional static memory management methods. Furthermore, at the applet programming stage not all data structures need to be filed in object structures. Some can be added at a later stage, able in effect to "install themselves" after data input, to the extent only the rough memory formatting permits. Also fewer data objects are required, resulting in less need for object administration. Lastly, it is made possible for applications and tools to define their data structures, e.g. card layouts in the data objects, only after initialization of the JavaCard during the runtime of an application. 4. DRAWINGS An embodiment of the invention is represented in the drawings and is described in more detail in the following. In the drawings: Fig. 1 shows a schematic view of the storage of data objects of a Java applet for storing address data and card/applet data according to the state of the art. Fig. 2 shows a schematic view of the storage of data in directory systems within data objects of a Java applet in accordance with the present invention. Fig. 3 shows a schematic block diagram setting out the key steps of the memory management method in accordance with the invention during the runtime of a Java applet. 5. DETAILED DESCRIPTION OF THE EMBODIMENT OF THE INVENTION With reference to Fig. 2, in a specimen situation in which it appears necessary to produce an upgrade of SmartCards the dynamic memory management enhanced by the present invention is described. In this situation a specific JavaCard series issued by an airline and already distributed to a group of customers is to be assigned additional functionality, for example resulting from the new collaboration agreement between the airline and a hotel chain. One of the consequences of the new functionality is the need to accommodate two new sets of personal master data in the existing memory of the card, as well as the need to access an existing set of personal master data, for example of the cardholder. In accordance with the invention the card series can now be updated easily and flexibly to the new status. As a result, when the new card is formatted a specific, larger memory area will be reserved in advance for data objects. The new layout based on the present invention is then produced from Fig. 2. The example in Fig. 2 shows a schematic of a SmartCard 8 with two data objects on it: Data object 10 is a data object for personal data and data object 12 is a data object for card/applet management data. This rough formatting of the memory for data objects on the one hand and applet application code on the other is produced during initialization of the card. In the present example the above-mentioned new functionality for the SmartCard is to be implemented in practice by dialog with a host application program on any terminal on the card. By inserting the card into the SmartCard reader of the terminal this host application is launched. It then backs up all the data stored on the SmartCard, buffers them and initializes them for a new write operation to the card. The host application then executes the rough formatting for data objects and application code outlined above, and writes the new required applets entailed by the expanded functionality to corresponding memory areas as well as writing the old data already existent on the card to new memory locations in a matching data object. In the present case, for example, the existing data record of the cardholder 14 is written to a directory system in the data object 10 for personal data. The invention further stipulates that the above-mentioned 'memory management object' is stored on the card together with the conventional memory management methods, such as memory allocation, memory deallocation, memory defragmenting and reading from/writing to the memory. Thereafter the SmartCard is reprogrammed and its expanded functionality can be utilized by the user. The user withdraws the card from the reader and so has an updated card, and can then experience its benefits, for example, by inserting the card into one of the airline's readers and calling up accommodation offers and hotel addresses based on the new collaboration between the airline and the hotel chain. As an additional feature, the user himself should also be required to enter an additional set of personal master data in order to be able to utilize the new functionality of the card in full. As represented schematically (and for the sake of clarity only by way of an extract) in Fig. 3, the user inserts his SmartCard in a terminal, the applet starts - step 110 - and the user is prompted - step 120 - to enter his new set of personal master data. As soon as he does so, for example by way of the card terminal, and has supplied data - step 130 -after an 'Input correct?' check 140 with an opportunity for correction, decision 140 - NO branch, after passing through the YES branch the memory management object in accordance with the invention for storage of the data based on the dynamic memory management method set out in the invention is called up - step 150. The object receives the necessary parameters, such as the number of characters in the entered name and the characters themselves, and during the runtime of the applet generates the new memory structure 16 in Fig. 2 in the same directory tree as was used for storage of the personal data 14 of the cardholder himself - step 160. Thus in a preferred mode of operation the memory management object is called up only once for each data record. Alternatively, it may however also be called up separately for each name or for each data field. In either case, by calling up the relevant allocation method and transferring the associated parameters it allocates only as much memory as is necessary to store the entered data. After additional actions performed by the user or the applet (see the dots in Fig. 3) the applet is then terminated - step 170 - and the SmartCard is withdrawn from the terminal. Thus memory has been allocated during the runtime of the applet, producing greater flexibility in the handling and programming of the SmartCards. Beyond the process represented in Fig. 3, however, a large number of other processes can all be implemented with the memory management concept presented by the invention. The procedure is repeated in Fig. 2, such as after input of the first data record, for a second personal master data record 18 for example (no longer shown in Fig. 3). Then the user selects an available function to view the newly entered data on the display of the host application for checking purposes. The check reveals that the second name was entered incorrectly and the correct spelling requires two more letters. Consequently the user needs to correct the name, and enters the new name correctly. The new input again calls up the memory management object, which releases the memory allocated to the incorrectly spelt name and writes the new name in a consecutive block to a different location in the memory. At the same time the released memory location is marked as available memory. After a freely selectable period of time a third partner - a car hire company - joins the collaboration agreement between the first two companies. The customer's card therefore needs to be equipped once again with expanded functionality - and a new applet issued by the new partner company. The new applet written to the card must be able to access the existing data on the card, and additional memory requirements for the Storage of additional personal data records result. In this situation the benefit of the memory management method presented by the invention is again shown: It enables the new applet with its ID, as described above, to be loaded into the card and incorporated into the relevant applet directory of the data object 12 after the existing applet ID entry 21 as a new entry 22, which then in turn can be called up. During the runtime of the new applet, the new, customer-specific personal master data records required can be entered as described above. In this process the memory is utilized much more effectively and efficiently than on state-of-the-art SmartCards, because the memory area in which the data object for personal master data is located is known right from the start. That means the bit positions marking 'the beginning and end of the said memory area can be made known to the new applet. The new applet in turn calls up the memory management object in order to read and display the existing data records on the card and to store new data records. A further advantage of the method in accordance with the invention becomes clear on observation of the applet programming itself. Because the applet 'being programmed only needs to know the structure of one data record, but not the size of the data fields of the data records already in use, in order to access them and to be able to create additional data records of the same structure. A new data record is simply stored as a new 'directory' with the associated data fields as a subordinate structure. This simplifies applet programming. Furthermore, the object of the present invention can be realized in hardware, in software, or in a combination of the two. Any kinds of computer system or computer devices are suitable to execute the method in accordance with the invention in whole or in part. A feasible hardware/software Combination would be a standard computer with a computer program which - when loaded and run - controls the computer s:uch that it executes the method in accordance with the invention in whole or in part. Such a program could also run on the host side and control the memory management of the SmartCard. The present invention may also be embedded in a computer program product which contains all the features permitting implementation of the methods described herein, and which - when loaded into a computer system - is capable of executing the said methods. "Computer program systems" and "computer programs" in the present context refer to any expressions in any language or notation or in any code of a set of instructions designed to cause a (system "yith information processing capability to execute one of the following functions either directly or consecutively, or both of the following functions: a) Translate into a different language or notation or a different code; b) Reproduce in a different material form. We Claim: 1. A method for management of memory on computer devices (8) with limited support for higher-level programming concepts in a data object, characterized by the step: use (150,160) of a memory management object with associated memory management methods for dynamic management of memory during the runtime of an applet, wherein the data object (10,12) for storage of data records (14,16,18,21,22) has memory than is required to store one data record. 2. The method as claimed in claim 1, wherein the logic circuit which implements the memory management object resides on the computer device (8). 3. The method as claimed in preceding claims, wherein a majority of data records (14,16,18,21,22) are managed in a directory structure within the data objects (10,12). 4. The method as claimed in claim 2 or 3, wherein the computer devices are object-oriented SmartCards (8), in particular a JavaCard.. 5. Computer device (8) for limited support for higher-level programming concepts as claimed in claim 1, wherein implementations of code segments are created to utilize a memory management object with associated methods for dynamic management of memory during the runtime of a program implemented on the device (8). 6. Computer Device as claimed in claim 5, wherein the logic circuit which implements the memory management object resides on the computer device (8). 7. Computer Device as claimed in claim 6, wherein the device (8) is an object- oriented SmartCard, in particular a JavaCard. 8. SmartCard as claimed in claim 4 or 7, characterized in that the memory space on the smartCard (8) contains at least one data object (10,12) which for storage of data records (14,16,18,21,22) in directory structure has more memory than is required to store one data record.

Documents:

723-del-2000-abstract.pdf

723-del-2000-claims.pdf

723-del-2000-complete specifiction (granted).pdf

723-del-2000-correspondence-others.pdf

723-del-2000-correspondence-po.pdf

723-del-2000-description (complete).pdf

723-del-2000-drawings.pdf

723-del-2000-form-1.pdf

723-del-2000-form-19.pdf

723-del-2000-form-2.pdf

723-del-2000-form-3.pdf

723-del-2000-form-5.pdf

723-del-2000-gpa.pdf

723-del-2000-petition-138.pdf

abstract.jpg