Data processing: software development – installation – and managem – Software program development tool – Programming language
Reexamination Certificate
1999-10-21
2004-06-22
Dam, Tuan (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Programming language
C717S103000, C717S175000, C710S068000, C710S074000
Reexamination Certificate
active
06754886
ABSTRACT:
1. BACKGROUND OF THE INVENTION
1.1 Field of the Invention
The present invention relates to programming and operation of applications for use with devices having a reduced support of high-level programming concepts, particularly for use with SmartCards, it relates in particular to improvements for programming read and write operations on such devices.
1.2 Description of Prior Art
Since a chip card was introduced for public telephones in France 1984, the chip card business has been rapidly growing concerning economic and technological aspects. Until the year 2000 an annual growth of 25 percent is expected. The German Geldkarte has been issued over 40 million times. Former simple storage chipboards evolved to modern SmartCards with their own microprocessor, own operation system and over 32 Kbytes free storage for applications. Very reliable authentication, electronic signature and cryptography are tasks where SmartCards are superior to traditional technologies like magnetic stripe cards. The integrated processor allows SmartCards to operate independently and not influenced by the environment: Sensible data, e.g. a secret key, never has to leave the card. Smart cards are able to execute cryptographic algorithms or check passwords locally before releasing stored data. Electronic cash transactions can be performed this way without an expensive online connection to host systems. This is why SmartCards play an important role especially in electronic business and banking.
Another important area of applications are consumer electronics: Mobiles and set-top-boxes already adopt SmartCard technology. Finally, in some years there will be a new generation of small electronic devices, i.e. reduced resources computer device which are mass produced low cost devices for a variety of daily-life purposes each holding a processing chip and some program memory.
Common to both types of devices is that they are characterized by having a reduced support of high-level programming concepts.
At least one major obstacle impedes the propagation of such devices and in particular of SmartCards and their application development: The software development problems involved with storing and reading on/from such devices.
Storing of objects, i.e. programming objects as an element of object-oriented programming (OOP) techniques is an essential subject of object-oriented software development. Storing an object comprises both, storing the attributes describing the object, and storing the status in which (OOP) methods and algorithms are when the object is stored, in order to be able to continue the methods and algorithms easily and consistently after any reset or interruption of a program having performed any operations on the objects.
Such highly developed storing methods can hardly be used, however, on reduced resources computer devices, i.e. any devices, holding a chip which is small in size and of very limited computing power and storing capacity. Further, they cannot easily be performed on above said devices having a reduced support of high-level programming concepts.
Filesystem-oriented SmartCards are an important example for such devices. On such SmartCards any information is stored by using traditional file structures.under the close memory space and file access constraints particular for such devices. Such structure contains a collection of simple file types and corresponding file directories in order to store the application data belonging to a host application the SmartCard is used with. Data are exchanged between host computer and SmartCard by using a plurality of single instruction sequences, abbreviated commonly as APDU, which carry the data as a trail behind the respective instructions and passing into and from the SmartCards mostly through a two pole contact only.
Such file system oriented SmartCards are the most commonly used ones and are the cheapest, compared to so-called JavaCards, the development of which is not yet completed. Such JavaCards are able to store complete SmartCard applications in form of Applets, and they can even perform them autonomously. In such cards said simple data types as well as complete programming objects can be stored. Such a comfortable storing procedure is, however, only possible to be realized by the SmartCard application itself and cannot be triggered by the host application for exchanging data with the respective SmartCard application. When the host application has to store any object on a JavaCard the traditional procedure of transmitting APDUs must be performed in order to exchange data.
When, however, data are transmitted in APDUs then the application developer has to take care on data formats in order to arrange all data in an adequate form on the SmartCard. This task requires a lot of specialized skill, specific for each SmartCard filesystem architecture.
In order to illustrate said data management problem the application programmer is confronted with, a small and simple example is given next below.
An application object is deemed to describe a bank account. The class name is “BankAccount”. It has the attributes “Account” and “CreditLimit”. Apart of that the class comprises the programming methods “Withdraw ( )”, “Deposit( )” and “GetNumberOfTransactions ( )”. The application developer has now to read out the particular attributes from the object and has to store them on the SmartCard specific for the respective object each, separately. Thus, Account and CreditLimit, as well as an internal counter of the GetNumberOfTransactions-method, necessary for intermediate storing of the current number of SmartCard accesses have to be treated in that complicated way.
As the application developer has to store the particular data each separately and maybe in a plurality of different ways, each way specific for a specific SmartCard type an application developer cannot take great advantage of the software development comfort which is brought with object-oriented applications, e.g. visual programming methods, as the SmartCards only support the above mentioned simple data types. The application developer has to convert objects explicitly into the simple data types supported by the SmartCard for which the application is designed. Such tasks interrupt a quick and straight forward object-oriented software development and complicates visual programming techniques.
An alternative, to take JavaCards in order to handle complex objects on SmartCards, too, is not easy to be realized as JavaCard technology is still not ready for use, expensive and not yet sufficiently standardized. Thus, the most important SmartCard sector today is that one with traditional filesystem-oriented SmartCards.
Therefore, it is an object of the present invention to improve software development for computing devices having a reduced support of high-level programming concepts and in particular for SmartCard applications by providing an object-oriented programming access to SmartCards as well.
2. SUMMARY OF THE INVENTION
This object of the invention is achieved by the features stated in enclosed independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective subclaims.
The objects to be stored on a SmartCard or on a similar device in the above mentioned sense are output from the host application computer in a serialized form adapted to the device, particularly in form of a byte array which can easily be stored on such a SmartCard. Said serialization comprises to convert any particular object into a sequence of bytes representing the object and its current status by storing all attributes, the name of them and all further objects which are referenced by the object which is subjected to that serialization. With the total of said information said object can be principally recovered later in time or in conjunction with another host application terminal being placed at a different location including the updates which were made before. Further, the objects can be recovered in an unchanged form after any reset or interruptions which can possibly take place during usa
Merk Lothar
Stober Thomas
August Casey P
Dam Tuan
F. Chau & Associates LLC
International Business Machines - Corporation
Vo Ted T.
LandOfFree
Method and system for storing java objects in devices having... 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 system for storing java objects in devices having..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for storing java objects in devices having... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3343941