Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-06-22
2001-12-11
Black, Thomas (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C709S203000, C709S217000
Reexamination Certificate
active
06330566
ABSTRACT:
COPYRIGHT AUTHORIZATION
The appendix to this disclosure contains copyrighted material. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights.
FIELD OF THE INVENTION
The present invention relates to caching client information in tokens stored on a client computer, and is illustrated with reference to storing web page customization data.
BACKGROUND AND SUMMARY OF THE INVENTION
In 1989, the Counseil Europeen pour la Recherche Nucleaire (CERN) started the Internet revolution with the creation of a hypertext system to allow CERN nuclear physicists to easily transfer documents containing both pictorial and textual data. One of CERN's primary goals was to unify existing data transfer protocols under a consistent interface for accessing different document types across diverse network mediums. In 1991, CERN publicly released their hypertext system, and after another year of review and improvement, in 1993 nascent Internet browsers were developed. These browsers brought Internet connectivity to the general public, and ever since there has been a near exponential explosion of software and hardware development to provide all manner of browser-based data transfer.
Fundamental to the operation of browsers is that they (as do all World-Wide-Web applications) operate on a discrete client-server basis. A client, such as a web browser, sends a request to a server, such as a Hypertext Transfer Protocol (HTTP) based web server, and the server responds to the client's request. The system is discrete in that a stateless protocol is used. Instead of opening and maintaining a connection to the server, the client instead encapsulates all relevant data into the request, a connection is opened to the server, the request is sent, and the connection is closed. Similarly, in response to the request, the server opens a connection to the client, transfers the results of the request, and closes the connection again. The nature of discrete requests and responses allows for efficient data transfer, and efficient multiplexing of multiple client requests.
But the efficiency advantages of this stateless system quickly turned into a disadvantage for developers wishing to provide more capabilities, such as sending custom web pages to web browsers. It is advantageous to allow a server to send customized web pages in response to a client browser's connection, but this is difficult with a stateless protocol. Various methods have been developed to simulate a statefull process over a stateless connection.
One such method is to require the client to log in, allowing the server to lookup the client in a server database. Then each web page sent to the client is formatted on the fly to include hypertext links including an identifier indicating who is contacting the server. When the client selects a link, the server receives a request with embedded information identifying the client, allowing the server to track the client's actions.
But, it is inconvenient to require a client to log in each time. An alternative solution is to have the client retain an updateable token that can be associated with a server's network location (e.g., a web site), so that the token can be transmitted in lieu of multiple login requirements. This token is commonly referred to as a “cookie,” and it can be passed between a client and server to allow server tracking of client activity.
A cookie is small, having a maximum size of about 4K. Cookies are designed to be transparently placed and retrieved from a client computer. In the context of a browser, every time a client contacts a particular network address, the client browser automatically transmits any cookies related to that network address. When sending a response to a contacting client, the server can update or set new cookies to be maintained by the client. This allows the server to track client activity.
Unfortunately, cookie usage suffers from several significant drawbacks. One such drawback is that cookies are limited in size, and only a limited number of cookies can be associated with any given network address; thus, there is a small finite limit on state information that the client can retain. Another drawback is that all cookie data is transferred to a server, even when irrelevant to a particular client transaction. This is due to a cookie transmission being based on the address contacted; for any given address, all client cookies related to that address are automatically sent to the server. This gives rise to significant unnecessary overhead. For example, if a server sets 20 cookies, each 4K in size, a client faces an 80K overhead in every communication with the server; this is compounded by a likely 80K overhead in any responses from the server, since if the client is maintaining its state in cookies, an updated-cookie will be sent by the server.
Although limited storage can be overcome by increasing cookie size, client-server communications would suffer an even greater transaction cost. Here, the term “cost” is used to generally express the time and data required to track client-server interaction-states. High cost is synonymous with having high overhead in communicating with a server. Such overhead is disadvantageous when clients communicate over saturated links.
To avoid the overhead of large cookie transmissions, an alternative approach is to have a server generate a unique (preferably short) client identifier, and to embed this id in a cookie set in a response to an initial contact by a client with the server. On subsequent client contact, the server receives the cookie with embedded id, allowing the server look up the client in a local clients database. As with the previous configuration, each client HTTP request to the server includes the client's relevant cookies, but the overhead is greatly diminished since only an id is transmitted, rather than the client's entire state information. Thus, the server can track what the client has been doing.
A problem with this method, however, is now the server is entirely responsible for tracking the client's state. This may appear a relatively minor burden since database technologies afford rapid access to client data. But, since network connections allow multiple clients to simultaneously contact a server, the server can be quickly overwhelmed with service requests.
(Further information about Internet cookies can be found in
HTML & CGI Unleashed
, Sams.Net Publ. (1995);
Dynamic HTML Unleashed
, Sams.Net Publ. (1998); as well as at Internet site http://developer.netscape.com/library/documentation/-communicator/jsguide4/cookies.htm, and http://developer. netscape.com-
ews/viewsource/archive/goodman_cookies.html.)
Thus, none of the prior solutions is particularly advantageous since they either entrust all state-tracking responsibility to resource-limited client storage, or to a possibly-overwhelmed server.
In accordance with an embodiment of the present invention, the foregoing drawbacks are overcome by caching in a client-stored cookie a globally unique client id (GUID) along with a core set of user data (such as preferences) generally applicable to the user's interaction with a server. To reduce overhead in transferring the cookie, preferences can be combined and compressed. By storing the unique id, a server is able to look up and track all of the client's data in a local database, and can retrieve data specific to a particular client request. And, by storing core data, such as page formatting and content preferences (hereafter “personalization settings”), the server can tailor the client's experience without having to incur the cost of database look-ups. Additionally, a cookie-version number can be embedded to indicate how a server should interpret an incoming cookie. These features improves site performance and stability.
In such an embodiment, when a client visits a front (entry) page of a site
Black Thomas
Klarquist & Sparkman, LLP
Le Uyen
Microsoft Corporation
LandOfFree
Apparatus and method for optimizing client-state data storage does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for optimizing client-state data storage, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for optimizing client-state data storage will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2602973