Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1999-09-27
2003-02-11
Eng, David Y. (Department: 2155)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
Reexamination Certificate
active
06519627
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to the use of service contracts in disconnected transactions. Specifically, this invention relates to specifying contracts that enforce rules of interaction with a product/service application for pervasive computing devices while disconnected from a server.
BACKGROUND OF THE INVENTION
There has been a substantial increase in the use of pervasive computing (e.g., hand held) devices to conduct electronic commerce over the last few years. Consequently, there is a need for systems that support disconnected transactions or transactions which, in part, are executed in a disconnected mode. Because pervasive computing devices are most often disconnected from a network (and, thus, any server), system features are required that enable the successful completion of these transactions upon reconnection to an application or resource provider server. Among other functionality, these features must provide for adherence to a set of rules in a pre-established service contract so as to enable the transaction as disclosed in U.S. patent application Ser. No. 09/148,618, filed Sep. 4, 1998, now U.S. Pat. No. 6,148,290 and assigned to the present assignee which is hereby incorporated by reference.
FIG. 1
depicts a conventional client-server interaction system model. The clients (
101
,
102
), being any type of computer system, are connected to a server or servers
140
via a network
130
such as the Internet or an intranet. In this model, the clients (
101
,
102
) execute a part of an application logic where the associated application code is either pre-installed in the clients (
101
,
102
) or downloaded from the server
140
prior to execution. The overall application is designed by appropriately partitioning the application logic across the clients (
101
,
102
) and the server
140
. Periodic upgrades may also be shipped by the server
140
to the clients (
101
,
102
). In any case, the clients are equipped with a program or client code (
111
,
112
) that executes locally and provides a responsive interface for interaction with the server
140
. The client code (
111
,
112
) establishes contact with the server
140
through the network. For example, a simple client interface could be provided by the client code (
111
,
112
) for interacting with several applications on the server, e.g., a VM Client application can be used to interact with several server applications like Email, HR forms etc. The client code (
111
,
112
) makes method invocations to the server
140
and receives responses therefrom. For state-keeping purposes, the interactions could be logged at the client and/or the server depending on the features and logic of the client code. Examples of such distributed client-server applications are distributed file systems, transaction processing, and groupware.
FIG. 2
depicts a conventional dynamic client system, where the client code
201
is dynamically downloaded to the client
200
when the client establishes a connection with the server
230
, rather than being statically pre-installed at the client and used for several interactions. That is, the interfaces provided to the user are composed at the server
230
and presented to the client
200
as a program that executes on the client. This code
201
is downloaded at run-time and, after the interactions, the code is deleted from the client. An example of this scenario is an Applet that is downloaded via the network
220
onto the client
200
and executes thereon by interacting with the server
230
making method invocations and receiving responses in return. The Applet is not permitted to write to the client's file system and has certain other security restrictions. Another example of this model could be an HTML form that shows up on the client's web browser when it opens a connection to the server. In both cases, the interactions are synchronous so that any disconnection with the server
230
would put the state of the interactions in an inconsistent state, unless the server
230
deploys mechanisms for logging and providing reliability and fault-tolerant functions. For example, a user at a client
200
may attempt to purchase goods through the web and a shopping cart may be filled with the user's selections. In this scenario, the state of the interactions could be lost if the connection to the server
230
is broken at some instance prior to completing the purchase. However, in this model, if the server
230
maintained the state of interactions, the interaction could be resumed by synchronizing the client state to the server state. This server state maintenance, of course, requires the connected nature of the transaction.
Under a model of pervasive computing, clients may follow a mode of disconnected operation and periodic synchronization.
FIG. 3
a
depicts an example of this model where client code
302
is downloaded from a database
306
of a server
305
and installed on a client
301
via a network
303
. The client
301
can be any pervasive (or mobile) computing device such as a hand held device, a notebook computer or some other pervasive electronic device with processing capability, storage, I/O mechanisms and a communication system. At some subsequent time, the client
301
is disconnected from the server
305
and the client continues to operate on data in a disconnected mode. When the client
301
executes the code
302
in the disconnected mode as shown in
FIG. 3
b,
a log
313
of all disconnected operations or actions is created by the client. Thus, in this pervasive computing model, the state of the disconnected operations is maintained on the client only. The client
301
periodically connects back to the server
305
, as shown in
FIG. 3
c,
to synchronize the client and server states in order to commit the transaction. In other words, the log
313
of the disconnected actions is uploaded to the server
305
, and the server
305
executes each of these actions resulting in a change to its database resources
306
. If these actions are completed successfully by the server
305
, then the transaction is successfully completed. But due to changes in the state of the server
305
, some of the actions will not be executed by the server
305
and the transaction will, therefore, fail. For instance, in the event that the data on the server is shared and accessed by more than one client, the data is free to change according to the actions that the other clients might perform. An example of this might be a movie ticket database which might be downloaded by a client. There may be clients that also have downloaded this database and reconnected in order to book tickets. In that case, if seats are sold on a First-Come-First-Served basis, when the client tries to commit a transaction for a seat which has been booked by some other client, the transaction fails because the data on this client is no longer current or, in other words, the data or the state at the server has changed. Thus, the client
301
would then have to re-attempt the transaction by receiving the current state of the server
305
.
Therefore, pervasive computing clients currently download data and attempt to execute transactions on the data without an understanding of the changes taking place at the server when they are disconnected. Thus, there is no guarantee of the validity of the data and the success of a transaction until the transaction is sent to the server and committed. Furthermore, users can tamper with data in the disconnected mode so that, upon reconnection, the transaction is erroneously completed. For instance, the price of a product could be adjusted so as to reduce the cost to the user. Thus, due to the disconnected nature of transactions in the pervasive computing arena and the associated characteristics that make transaction and data validity questionable, there is a need for a system and method for validating actions taken in the disconnected mode.
Service contracts can be used to facilitate the outcomes of transactions by requiring adherence to the guidelines o
Dan Asit
Dias Daniel Manuel
Janakiraman Pradeep
Eng David Y.
Zarick Gail H.
LandOfFree
System and method for conducting disconnected transactions... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for conducting disconnected transactions..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for conducting disconnected transactions... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3160270