Electrical computers and digital processing systems: multicomput – Network-to-computer interfacing
Reexamination Certificate
1999-11-15
2004-06-15
Caldwell, Andrew (Department: 2151)
Electrical computers and digital processing systems: multicomput
Network-to-computer interfacing
C902S026000, C235S380000
Reexamination Certificate
active
06751675
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer systems. More particularly, the present invention relates to moving set data communications.
2. Background
A virtual machine is an abstract computing machine generated by a software application or sequence of instructions that is executed by a processor. The term “architecture-neutral” refers to programs, such as those written in the Java™ programming language, which can be executed by a virtual machine on a variety of computer platforms having a variety of different computer architectures. Thus, for example, a virtual machine being executed on a Windows™-based personal computer system will use the same set of instructions as a virtual machine being executed on a UNIX™-based computer system. The result of the platform-independent coding of a virtual machine's sequence of instructions is a stream of one or more bytecodes, each of which is, for example, a one-byte-long numerical code.
The Java™ Virtual Machine is one example of a virtual machine. Compiled code to be executed by the Java™ Virtual Machine is represented using a hardware- and operating system-independent binary format, typically stored in a file, known as the class file format. The class file is designed to handle object oriented structures that can represent programs written in the Java™ programming language, but may also support is several other programming languages. The class file format precisely defines the representation of a class or interface, including details such as byte ordering that might be taken for granted in a platform-specific object file format. For the sake of security, the Java™ Virtual Machine imposes strong format and structural constraints on the instructions in a class file. Any language with functionality that can be expressed in terms of a valid class file can be hosted by the Java™ Virtual Machine. The class file is designed to handle object oriented structures that can represent programs written in the Java™ programming language, but may also support several other programming languages. The Java™ Virtual Machine is described in detail in Lindholm, et al., “The Java™ Virtual Machine Specification”, April 1999, Addison-Wesley Longman, Inc., Second Edition.
Resource-constrained devices are generally considered to be those that are relatively restricted in memory and/or computing power or speed, as compared to typical desktop computers and the like. By way of example, other resource-constrained devices include cellular telephones, boundary scan devices, field programmable devices, personal digital assistants (PDAs) and pagers and other miniature or small footprint devices.
Smart cards, also known as intelligent portable data-carrying cards, are a type of resource-constrained device. Smart cards are made of plastic or metal and have an electronic chip that includes an embedded microprocessor or microcontroller to execute programs and memory to store programs and data. Such devices, which can be about the size of a credit card, have computer chips with 8-bit or 16-bit architectures. Additionally, these devices typically have limited memory capacity. For example, some smart cards have less than one kilo-byte (1K) of random access memory (RAM) as well as limited read only memory (ROM), and/or non-volatile memory such as electrically erasable programmable read only memory (EEPROM).
A Java™ virtual machine executes virtual machine code written in the Java™ programming language and is designed for use with a 32-bit architecture. It would be desirable to write programs that use the full implementation of the Java™ Virtual Machine for execution on resource-constrained devices such as smart cards. However, due to the limited architecture and memory of resource-constrained devices such as smart cards, the full Java™ Virtual Machine platform cannot be implemented on such devices. Accordingly, a separate Java Card™ (the smart card that supports the Java™ programming language) technology supports a subset of the Java™ programming language for resource-constrained devices.
Turning now to
FIG. 1
, a typical apparatus for installing applications on a Java Card™ technology enabled device
120
is presented. In Java Card™ technology, a Java Card™ converter
100
takes regular class files
105
as input and converts them to a CAP (converted applet) file
110
. The CAP format supports a subset of the class file information. Each CAP file
110
contains all of the classes and interfaces defined in one Java™ package. After conversion, the CAP file
110
is copied to a card terminal, such as a desktop computer with a card reader peripheral. Then an installation tool
115
on the terminal loads the CAP file
110
and transmits it to the Java Card™ technology enabled device
120
. An installation application
125
on the Java Card™ technology enabled device
120
receives and processes the data from the terminal to install the application on the Java Card™ technology enabled device
120
.
Due to resource-constrained nature of a typical Java Card™ technology enabled device
120
, only a relatively small amount of memory is available for data communication. Thus, the communication between the terminal and the Java Card™ technology enabled device
120
typically consists of multiple application data units (APDUs)
135
sent from the terminal to the Java Card™ technology enabled device
120
. An APDU
135
is data packet having a data portion that ranges in size from 32 bytes to 256 bytes. Data that is sent from the terminal is encapsulated in one or more APDUs
135
before being sent to the Java Card™ technology enabled device
120
.
Since the size of the multiple data values encapsulated varies, the data values are frequently split between multiple APDUs
135
. Table 1 illustrates the data portion of an APDU
135
. Table 2 shows data to be encapsulated in an APDU
135
.
TABLE 1
TABLE 2
If the data shown in Table 2 were encapsulated in an APDU
135
represented by Table 1 while preserving the relative order of the data, there would be insufficient room for the second sixteen-bit integer, resulting in a “data split” problem. This data split problem is typically handled by processing the data on the terminal side to guarantee the data will not be split. This processing on the terminal side may include by way of example, changing the size of the APDU
135
to prevent a data split, or reordering the data within APDUs before sending them to a Java Card™ technology enabled device
120
. Each of these solutions has disadvantages.
Changing the size of the APDU
135
and reordering the data within the APDU
135
requires complex negotiation between the terminal and the card. The terminal must transform the data and provide the card with enough information to reconstruct the data. The card must receive the information from the terminal, reconstruct the data and provide a response to the terminal. Making the terminal and card applications data-dependent as such increases processing overhead. This data dependency also increases memory overhead, both in terms of program size and the amount of RAM required to store buffered data.
Putting intelligence on the terminal side also raises security concerns. Knowing whether a data split problem exists requires that the terminal know the size of each data item being sent. This size information is related to the data type. This information is not available if the data is encrypted. Thus, the terminal must decrypt encrypted data before it interprets the data to determine the size of each data unit. Once the data is decrypted, the terminal has access to private information. In some applications, only the card is meant to interpret the data, not the terminal.
Accordingly, a need exists in the prior art for a method and apparatus for data communications between a terminal device and a smart card that requires relatively little processing and memory overhead on terminal and smart card applications. A further need exists for such a method and apparatus that is relatively secure.
SUMMARY OF THE I
Caldwell Andrew
Schaub John P.
Sun Microsystems Inc.
Thelen Reid & Priest LLP
LandOfFree
Moving set packet processor suitable for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Moving set packet processor suitable for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Moving set packet processor suitable for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3326690