Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
2000-12-21
2004-10-19
Barot, Bharat (Department: 2155)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C709S214000, C709S229000, C709S230000, C714S738000, C714S738000
Reexamination Certificate
active
06807561
ABSTRACT:
FIELD OF THE INVENTION
The present invention is generally directed to integrated circuit cards, commonly known as “smart cards,” and other types of portable electronic devices that are capable of executing applications, such as PDAs and mobile telephones. More particularly, the invention is directed to the use of such devices for hosting services in a distributed computing system.
BACKGROUND OF THE INVENTION
As the use of portable electronic devices with integrated microprocessors becomes more widespread, and the technology pertaining to them advances, the amount and variety of information contained in such devices continues to grow, thereby expanding the potential applications for them. In this regard, one particularly interesting application constitutes the use of these devices, such as smart cards, PDAs, and mobile telephones, as hosts for services in a distributed computing system. In this context, the device stores one or more application programs, e.g., applets in the Java programming language. Each such application has a corresponding client program that communicates with the application stored on the device. Typically, the client program might be stored in a terminal in which the device is inserted, or with which the device otherwise communicates. The client programs and device applications exchange messages with one another, and thereby permit a user at the terminal to employ the services provided by the applications on the device.
Typically, in a distributed computing environment, the client and server portions of an application communicate with one another by means of a predefined set of semantics. One example of such a semantic is a procedure call. Another example of a semantic, in an object-oriented programming environment, is a remote method invocation (RMI). In the context of this latter semantic, the functions, or methods, that can be performed by the server program are published, e.g. through an application programming interface, and the client program interacts with the server program by invoking these methods, and providing any parameters that are associated with the invocation. The server program performs the operation that was requested by the client, and returns a result. This protocol facilitates the development of new client programs, since the program developer need only be aware of the published methods for the server program, and write appropriate calls to invoke those methods.
When using a portable electronic device as a host for distributed services, the device may be required to communicate with the client by means of a specific protocol. In the context of a smart card, for instance, the card and the terminal must communicate with one another in accordance with the standards that are applicable to smart cards. Specifically, ISO/IEC 7816-4 specifies that the card and the terminal communicate with a message structure known as the application protocol data unit (APDU). Messages are exchanged as a command and response pair. In the development of applications for the smart card environment, therefore, the program developer was required to be familiar with this message structure, and incorporate code into the program which conforms to the applicable protocol. For instance, the software on the smart card had to include program code which operated to decode command APDUs and encode response APDUs. On the terminal side of the application, the software had to include program code which performed the corresponding inverse operations. Consequently, the development of application programs that were designed to operate on smart cards was quite complex.
To alleviate this burden in the development of applications for smart cards, semantic frameworks have been proposed. For instance, an RMI framework enables programmers to deal with the card applications at the level of method invocations, and not concern themselves with the APDU message passing mechanism. In essence, this result is accomplished by the use of a client proxy at the terminal side of the system. When the client program invokes a method, this invocation is presented to the proxy. The proxy converts the method into the appropriate APDU message, which is then transmitted to the card. At the card, a skeleton program performs the inverse function of the proxy, and transforms the received APDU messages back into the appropriate method calls. These calls are then presented to the on-card application, which returns a corresponding result.
To facilitate the generation of the client proxy and the card skeleton in the Java programming language developed by Sun Microsystems, a programming tool such as a Stub Generator can be made available to programmers. In the context of smart cards, for example, a Stub Generator which is adapted to a subset of Java that is executed on a smart card, known as Java Card, can be employed. In the development of a service that is to be available from a smart card, the programmer develops the implementation of that service, namely, the actual steps of the program that perform the service, as well as an interface which defines entry points of the application on the card, i.e. the list of methods that are available from the implementation. The Stub Generator tool that is adapted to Java Card then generates the client proxy and the card skeleton from the definitions provided via the interface, to provide the appropriate conversions between the published methods and corresponding APDU messages. The card application, which consists of the implementation code, the interface and the card skeleton, is then installed on the card, and client programs are developed which communicate with the client proxy to invoke the methods available through the card service.
The use of the client proxy and card skeleton to facilitate the transport level communications between the terminal and the card provides a number of advantages. First, the card applications can be written in a known language, e.g. the Java programming language. The proxy and skeleton make the APDU protocol transparent to the operation of the program. Consequently, the program developer is not required to have any knowledge of this protocol. As a result, the smart card can be readily integrated into a distributed computing model, rather than having to be treated as a special device.
However, in the context of a smart card, there may be some situations in which it is desirable for the APDU messages to be handled at the application level, rather than in the skeleton. For example, one of the most significant features associated with a smart card is the security that it provides for various transactions. To provide such security, the smart card may encrypt and decrypt the APDU messages, and/or add a signature to each APDU message. To maintain the security level associated with these procedures, it may be preferable to have the encryption and decryption, and/or the validation of signatures, handled within the application itself, rather than develop a specific proxy and skeleton to handle these functions. Further in this regard, it would be difficult to employ a program generation tool, such as the Stub Generator, to automatically produce the required proxy and skeleton. Such a tool would have to be very powerful, and hence complex, since it would have to be familiar with all of the requirements of all of the applications for these types of security services, if it is to operate effectively.
In another situation, it may be the case that older, legacy terminals do not employ the services of a client proxy or an application interface. As a result, these terminals are only capable of communicating by means of the APDU messaging protocol. For instance, the GSM specification for mobile telephones is not based on the Java programming language, and therefore does not employ semantics such as remote method invocation. In such a case, an application which relies solely upon a card skeleton to provide such semantics would not be able to communicate with a legacy terminal.
To address these types of situations, various solutions can be envisioned. As on
Lagosanto Laurent
Vandewalle Jean-Jacques
Barot Bharat
Gemplus
LandOfFree
Generic communication filters for distributed applications does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Generic communication filters for distributed applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generic communication filters for distributed applications will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3281758