Apparatus and method for optimizing client-state data storage

[0002] 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.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] (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-/news/viewsource/archive/goodman_cookies.html.)

[0015] 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.

[0016] 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.

[0017] In such an embodiment, when a client visits a front (entry) page of a site, entry code on that page checks whether the client's connection software (e.g., a web browser) provided a cookie containing the client's personalization settings. If the cookie was not automatically provided to the server (or the version number is too old), but the user has been assigned a GUID, the entry code calls a generation routine to generate a cookie. Note that if there are no cookies, browser serial number, or other identifier for the client, the client may be prompted to enter identification information in one or more dialog boxes. (It is understood that references to calling a routine includes any method of generating such a cookie, such as by a procedure, function, ASP file, Active X control, D/COM, Java, J/Script, D/HTML, plug-in, etc.) The generation routine is used to retrieve the relevant set of personalization settings from the database, build the compressed cookie, and pass it to the user's browser. Similarly, when the user completes a personalization session, or if the server wants to update the client state, a save settings routine is activated to update the client cookie.

[0018] If the client does not yet have any personalization settings, a cookie is created with value “0” (or some other value indicating an empty cookie). The server can then immediately redirect the client to a personalization routine so that a non-empty cookie may be defined, or personalization can be deferred. If deferred, on subsequent contact with the server the empty cookie will be transferred, indicating to the server that it needs to personalize the new client.

[0019] If the client does have personalization settings stored in a server database, a compressed cookie can be created by retrieving the core settings and setting them into a cookie for storage by the client.

[0020] A cookie can be formatted as a string containing multiple substrings, each delimited by a separation character (e.g., a “!” or other character). These substrings can contain data in different formats, such as simple strings, comma-delimited string lists, compact Boolean arrays, and encoded numeric arrays. Formatting choices are made to minimize data size, as well as to minimize data decoding time on the server. In some cases, this means the code stores data in non-canonical formats. (“Decoding time” refers to the time necessary to decompress stored data.)

[0021] For example, an entry page may be personalized to display a user's name. This data can be stored in a cookie as [First Name]{[space][Last Name]}[possessive suffix] (e.g., “John Doe's”). Therefore, the work to determine whether there is a last name, and what possessive suffix to use, is only done once at cookie creation time. (Note that although plain-text is shown in this example, the text representation can be compression-encoded into a shorter (but unreadable) ASCII sequence.) Similarly, a web page may provide other information (e.g., stocks, news, sports, etc.) that the client has requested be displayed on entry to the page. Preferences, such as which stocks to display, can be stored as a comma-delimited list, or in some other format for direct submission to a third-party information-retrieval system.

[0022] To reduce cookie size, a cookie creation routine encodes numeric data in the range 0-63 as a single character, the ASCII character corresponding to N+48. Base64 or other schemes can also be used to encode numeric data. However, N+48 is preferable because it can be quickly encoded and decoded, and it is not necessary to protect it against character transformation (i.e., the characters are interpreted on the same kind of system that generated them).

[0023] Cookie size is further optimized by representing configuration information as a compressed series of Boolean (yes/no) values. For example, one could use a single bit to track whether a client prefers to receive news listings at the top or the bottom of a personalized page. Other personalization choices can be concatenated into a long bit sequence, and the entire sequence then compressed. First, collections of Boolean values are grouped into 6-bit runs and then N+64 encoded. For example, (True, True, False, False, True, True) is mapped to 110011, which is ⁵¹₁₀. 51+48=99, which corresponds to the ASCII character ‘c’. Storing Boolean information in this manner is significantly more compact than storing strings such as “Sports=on” or by storing a Boolean string-array “110011”.

[0024] A further optimization is to truncate superfluous delimiters corresponding to empty values. Thus, rather than creating a cookie containing “05!John Doe's!sea!01000!!KING!!!00000!00000!00000!*!*!*!*!*”, instead only “05!John Doe's!sea!01!!KING” is stored. Such a reduction is possible when the cookie interpretation code assumes default values for unspecified information. Note that the leading “05” corresponds to version control. The cookie creation routine adds a version number to the beginning of the cookie, so that the cookie interpretation code can determine what format the cookie is in. This allows the server to utilize different format/compression schemes depending on the types of data the server expects to present to the client.

[0025] Other features and advantages of the invention will be apparent from the detailed description and accompanying drawings.

[0026] FIG. 1 is a block diagram of a computer system that may be used to implement a method and apparatus for manipulating compressed cookies.

[0027] FIG. 2 is a flowchart showing the user personalization process.

[0028] FIG. 3 illustrates the data flow between a client contacting a server.

[0029] FIG. 4 shows an exemplary cookie having compressed and uncompressed fields.

[0030] FIG. 5 is a flowchart of steps required to generate the FIG. 4 cookie.

[0031] FIG. 6 shows a first exemplary personalized entry-page.

[0032] FIG. 7 shows a second exemplary personalized page.

[0033] Prior art systems either store all client configuration information on a client, or they store all information in a server database. Storing all data on the client results in large amounts of data being unnecessarily sent to a server, as the client needs to pass along its state with each communication to the server. The alternative is to store a client identifier on the client, and to use it as a database retrieval key. Unfortunately, this server-based storage subjects page generation speeds to the vagaries of database retrieval speeds. The present embodiment combines the best of both methods to avoid long transmission times of state information, as well as long database retrieval times, and provides further enhancement. Frequently used data is cached in a client cookie in a compressed format, while all client data is stored in a server database.

[0034] The invention has been incorporated into the MSNBC web site marketed by Microsoft Corporation of Redmond, Washington, and is designed to work in tandem with Internet browsing software. Briefly described, Internet browsing protocols (e.g., the Hypertext Markup Language (HTML)) are stateless, and the invention provides compressed tokens (“cookies”) which are used to track client state information over stateless protocols.

[0035] Using compressed cookies allows client preferences to be compactly stored in a cookie so that an HTTP web page may be quickly presented in a custom format to the client, without the overhead of having to retrieve all client preferences from a server database. Local storage of preferences allows compiled-type programs (ActiveX, Java, etc.) to immediately arrange the client's viewing environment (window locations, introductory music/video, etc.) according to locally-stored preferences and configuration data, while simultaneously seeking a connection to the server. Thus a client will not have completely inactive sessions while awaiting server access.

[0036] FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. While the invention will be described in the general context of computer-executable instructions of a computer program that runs on a personal computer, those skilled in the art will recognize that the invention also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The illustrated embodiment of the invention also is practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. But, some embodiments of the invention can be practiced on stand alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0037] With reference to FIG. 1, an exemplary system for implementing the invention includes a computer 20, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The processing unit may be any of various commercially available processors, including Intel x86, Pentium and compatible microprocessors from Intel and others, the Alpha processor by Digital, and the PowerPC from IBM and Motorola. Dual microprocessors and other multi-processor architectures also can be used as the processing unit 21.

[0038] The system bus may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of conventional bus architectures such as PCI, AGP, VESA, Microchannel, ISA and EISA, to name a few. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within the computer 20, such as during start-up, is stored in ROM 24.

[0039] The computer 20 further includes a hard disk drive 27, a magnetic disk drive 28, e.g., to read from or write to a removable disk 29, and an optical disk drive 30, e.g., for reading a CD-ROM disk 31 or to read from or write to other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, etc. for the computer 20. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk and a CD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like, may also be used in the exemplary operating environment.

[0040] A number of program modules may be stored in the drives and RAM 25, including an operating system 35, one or more application programs (e.g., Internet browser software) 36, other program modules 37, and program data 38.

[0041] A user may enter commands and information into the computer 20 through a keyboard 40 and pointing device, such as a mouse 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

[0042] The computer 20 is expected to operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be a web server, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 20, although only a memory storage device 50 has been illustrated in FIG. 1. The computer 20 can contact the remote computer 49 over an Internet connection established through a Gateway 55 (e.g., a router, dedicated-line, or other network link), a modem 54 link, or by an intra-office local area network (LAN) 51 or wide area network (WAN) 52. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0043] In accordance with the practices of persons skilled in the art of computer programming, the present invention is described below with reference to acts and symbolic representations of operations that are performed by the computer 20, unless indicated otherwise. Such acts and operations are sometimes referred to as being computer-executed. It will be appreciated that the acts and symbolically represented operations include the manipulation by the processing unit 21 of electrical signals representing data bits which causes a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in the memory system (including the system memory 22, hard drive 27, floppy disks 29, and CD-ROM 31) to thereby reconfigure or otherwise alter the computer system's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, or optical properties corresponding to the data bits.

[0044] FIG. 2 shows the user personalization process, or preference election process, that results in generating a compressed cookie. The illustrated personalization process corresponds to an initial contact by a client with a server, such that the server needs to generate client personalization data which will be remembered and used to generated web pages in accord with the client's indicated interests.

[0045] While a database will likely remain a primary repository of user settings, the compressed cookie caches settings required to build a personalized front page. FIG. 2 corresponds to the process for creating the compressed cookie, and shows the flow of data related to the cookie through the personalization processes. This cookie creation process is dependent on the settings written to the user property database by the Active Server Page (ASP) code in supporting ASP functions EXITSAVE and SAVESET (see FIG. 5 discussion). ASP functions are used to allow server-side data processing. Generally, ASP pages contain a combination of HTML, server-side scripting languages (i.e. VBScript, JScript, REXX, or Python), and server-side components (i.e. Collaboration Data Objects (CDO) or databases). ASP code is interpreted on a server, and the results sent to a client; this allows the processing steps to be hidden from the client. Output to the client can be HTML, a revised ASP page for interpretation by a client browser, or some other format. ASP pages can also be embedded into ActiveX (or other) objects, providing further abstraction (and hiding) of server processing activity.

[0046] Note however, that Internet client software usually allows a client to automatically reject cookies; for the purposes of the discussion herein, it is assumed that ASP pages can not or do not override a browser's refusal to accept cookies, and therefore a client's browser is configured to accept such cookies. Also note, however, that a browser serial number embedded within each browser can be used to supplant portions of a cookie in the advent that cookies are being rejected or accidentally deleted. Additionally, the server could store a copy of the client's current cookie definition, and use the serial number to retrieve the cookie if it was accidentally deleted; thus avoiding the client having to re-initialize (re-elect) preferences.

[0047] As shown, initially a client contacts 100 a server with Internet client software. A first test 102 is made to determine whether the client automatically sent the server a client cookie. If so, the server verifies that the client exists 104 in a local clients-database, and retrieves 106 configuration information about the client. The server can also modify 106 the client's cookie before sending 110 it back to the client in an HTTP response from the server.

[0048] If, however, the initial tests 102, 104 fail, indicating the client did not initially send a cookie, or that the client was not found in the client database (for example, the cookie may have been corrupted by cookie management software), then a new database record is created 112 for the client, and a new cookie initialized (generated) 114. This cookie is then sent 110 to the client so that a personalized page can be generated 116 for the client.

[0049] Note that there can be a case where the client sent in enough data to allow the server to recognize the client, but that the cookie contents were otherwise incomplete or damaged. Under such a circumstance, cookie generation can simply become a matter of retrieving client data from the server database and generating a cookie from that data.

[0050] FIG. 3 shows the overall relationship between client and server. Not shown is the client's Internet browser (or equivalent) software that is requesting the DEFAULT.ASP web page from the server. Shown are two ASP scripts 130, 132 which are involved in compressed cookie creation and interpretation. STRPXCODE.ASP 134 is included within both ASP files, and contains support code to create and manipulate compressed cookies. When a client requests the entry page (DEFAULT.ASP 146) and does not have a compressed cookie, a Property Database 136 is queried to see whether the user has personalized. If they have, then StrPxFromPropertyDatabase (a support routine to retrieve database information) is called to create the cookie; this routine takes the Property Database object 136 as an optional parameter (if one is not provided, a new database is created). StrPxFromPropertyDatabase retrieves 138 client preferences from the client property database, assembles the cookie 140, and then adds it to an outgoing HTTP header 142 through a Response.Cookie (set cookie) mechanism. Since the cookie value will be moderately large (typically 80-100 characters), preferably its path is set so it is only sent from the client when pulling the personalized front page (DEFAULT.ASP 146), and not on any other HTTP request. However, reducing the number of times the cookie is sent by the client needs to be balanced against unnecessary cookie proliferation.

[0051] During the preference selection process, client preferences are also recorded 144 in the Property Database 136. Consequently, the code that sets the cookie based on first-time interaction with the client, can also to handle setting the cookie after an update-personalization session. In particular, when a client has no cached-settings cookie, but does have a database entry, StrPxFromPropertyDatabase generates a cookie based on Property Database 136 settings. When the client changes a setting on the site, the Property Database is updated, and then StrPxFromPropertyDatabase updates the cookie. And, if the cookie is strategically pathed, it may be seen by related sites. Thus, on visiting a related site, the cookie could be inspected, possibly updated (e.g., the version is old), while also allowing the related site to create its own cookie based in part on the cookie from the related site.

[0052] PFPCODE.ASP 146, included in the DEFAULT.ASP 148 file, contains client-side code for interpreting the compressed cookie. PFPCODE.ASP parses the cookie contents 150 and generates 152 a personalized page from the cookie values. DEFAULT.ASP then uses the passed cookie to construct the personalized page. Preferably, when it is known that the page to display is complex, buffering is turned off so that the client sees partial page-loading; this increases the apparent speed of the system by allowing a personalized page to be viewable while loading.

[0053] When a server buffers output, the server is assembling data in server memory, and then transmitting the web page when it is complete. An advantage to such buffering is that server-side code, such as an ASP file, can modify generated data (such as revising an HTTP header) based on the content of the generated data (since nothing has yet been transmitted). The disadvantage to this arrangement is that no data is being transmitted to the client until the entire page is completed. Turning off buffering for complex pages (i.e. pages which may take extended periods of time to generate) results in content being sent to the client as soon as it is generated, thereby giving the appearance of speedier access to a server that is otherwise busy completing the generation of the requested data.

[0054] Note that in order for the compressed cookie process to work properly, it is necessary that the client support cookies. If the client does not support cookies, then personalization is not possible. However, this system can be mimicked if the client software has a readable serial number or other unique identification. If a serial number is available, it can be used to retrieve a cookie from a server database and presented to DEFAULT.ASP for generating a personalized page. In addition, the serial number may be embedded in all links, buttons, etc. of dynamically generated pages, allowing an alternative to requiring cookies.

[0055] Also, if a compressed cookie appears to be invalid (see FIG. 2, step 104), one can walk through the Step-by-step personalization process to evaluate where an error in the cookie resides.

[0056] FIGS. 4 and 5 illustrate cookie creation. FIG. 4 shows an exemplary cookie having reference numbers identifying portions of a cookie generated by correspondingly numbered steps in FIG. 5. An interface (via a web page form, menu, control, etc.), not shown, presents exemplary preference choices, and the client elects particular preferences which are then forwarded to the server. These preferences are stored in a database, as well as encoded into a cookie. It is understood that the following preferences are exemplary, and that other preferences may presented and tracked. The interface is presented to the client after the client's initial contact with the server entry page reveals the client is a new client. It is assumed that the entry page is ASP based, but other equivalent formats are possible. It should also be noted that some implementations of the FIG. 4 cookie may require the cookie to contain control code sequences rather than certain characters in the sequence. For example, the space in John Smith's name may be encoded as the HTTP control “&nbsp”, or the “!” delimiters may instead be represented by a numeric index into a character set.

[0057] It is presumed in the following discussion that a generated web page has the following sections: general entry page information, News (local and traffic, national, international, Meeks column, Moran column), Commerce (Bowermaster column, Byron column, Crockett column, Huus column, Thomas column, Weaver column), Sports, Technology (Internet; Tech Policy; Tools, Toys and Talk; Crimes, Errors, and Annoyances) Living (Healthy Adam, Healthy Eve, Movie Reviews, Celebrity Bar), Opinions, Chat, On Air, and Personal Topics. It will be understood by those skilled in the art that these page sections are merely exemplary, and that sections may be added or removed according to the type of page being developed.

[0058] The overall process is that (assuming a client did not send a proper cookie on contacting the server) the client is redirected to an initialization page to start entering the client's personalization preferences (FIG. 2, step 114). When personalization completes, the settings are written to a server user-property database. The settings are read back by a cookie generation subroutine and used to generate the compressed cookie. The compressed cookie is included in a response-page header when an HTTP response is generated to the initial client contact request is made for the entry page. Code within the response page (an ASP file) disassembles the cookie and uses its contents to generate the page according to user preferences stored in the cookie.

[0059] Thus, at step 200 of FIG. 5 a version number is added to the cookie. Tracking a version number allows the system to know when the client has become out of date, and it also allows the system to know what cookie-format to expect when processing a pre-existing cookie.

[0060] At step 202 a cover name is added to the cookie. This name represents what the client desires to be called at the top (or some other location) of generated web pages. These cover names consist of the client's name in proper possessive form. That is, by default a client named Bob Smith will get a cover name of “Bob Smith's”, and a client named “Bob Jones” will get a cover name of “Bob Jones'”. This allows a page title of “Bob Smith's Web Page” or “Bob Jones' Stock Quotes” to be easily generated. This also highlights a general design goal of the invention, in that as much processing as possible is front-loaded in the initial construction of the cookie. Information such as proper possessive form, which is likely relevant knowledge for multiple web pages, is determined at cookie creation time. This avoids having to make this determination at a later time, and increases the apparent responsiveness of dynamic web page creation.

[0061] At step 204, weather selections are added to the cookie. Preferably the user interface (e.g., a web page) is presented to the client, allowing the client to select from a list of possible weather locations. This field, if defined, contains at least a 3-character name for the client's preferred weather location. Weather information from this city is presented in a personalized web page according to indicated preference. That is, the client is allowed to select where on the page the weather display should be, and this selection is recorded in the cookie, as well as stored in the client's database record. (All client data is stored in the database, allowing a cookie to be entirely reconstructed if necessary.)

[0062] At step 206, Fast Bits are set. The Fast Bits contain a compressed array of Boolean values, corresponding to the “on/off” properties selected by the client in the preferences election stage. For the purposes of this description, the bits are presumed broken into two regions, the second region referenced herein as More Bits. The advantage to multiple bit regions is that, as described below, trailing 0's are truncated. Thus, a region of all zeros is an empty region, requiring no storage space within the cookie (except for region boundary markers). Multiple regions provide more opportunity to truncate a particular region, and the number of such regions necessarily depends on the data arrangement chosen by the web site designer.

[0063] A cookie is defined to have a restricted character set; consequently at the present time only 6 bits are required to encode all possible cookie character values. Consequently, a preferred bit packing scheme is to take 6 bits out of a bit region, and to interpret those bits as a binary representation of a character within the cookie character set. It is understood that this packing scheme is extensible to an n-bit representation if at some future time the character set is expanded. The character stored is the ASCII character 48 (which is the zero character) plus the 6-bit number. This configuration allows storing all possible printable values, while also mapping empty bit ranges to the “0” character. To further compress cookie entries, trailing 0's are truncated, as it is understood that a missing value represents 0, which is 6 consecutive off values.

[0064] In a claimed embodiment of the invention, each bit sequence is thirty bits long. The five-character Fast Bits 206 correspond to the following preferences:

[0065] As a compression optimization, empty preferences are truncated to reduce unnecessary overhead. If it turns out that the last 12 bits are 0, then the two characters corresponding to those bits are not stored in the cookie. With careful planning, such as by locating common preferences early in the bit sequence, and by placing mutually exclusive options in different 6 bit runs, significant storage savings can result.

[0066] At step 208, traffic preferences are set. Traffic is shown in the Local News section. The currently possible values are 0=do not present traffic information, 1=Atlanta, 2=Boston, 3=Chicago, 4=Cincinnati, 5=Houston, 6=Los Angeles, 7=Minneapolis/St. Paul, 8=Paris, France, 9=Philadelphia, 10=Phoenix, 11=Pittsburgh, 12=San Antonio, 13=San Diego, 14=Seattle, and 15=Washington, D.C. Other traffic locations can be designed. Although this discussion may speak to assigning numeric values to preferences, it is understood that the numeric values may be encoded to reduce storage space. That is, a single character from the available character set can be used as an index into a table of preference values. For example, using a N+48 mapping (see Background and Summary), “10=Phoenix” becomes a “:”, “11=Pittsburg” becomes “;”, “12=San Antonio” becomes “<”, etc.

[0067] At step 210, astrological preferences are set. Horoscopes are shown in the Living section. The available signs are 0=do not present astrological information, 1=Aries, 2=Taurus, 3=Gemini, 4=Cancer, 5=Leo, 6=Virgo, 7=Libra, 8=Scorpio, 9=Sagittarius, 10=Capricorn, 11=Aquarius, 12=Pisces. Future embodiments may also add entries for astrological related matters. (As with step 208, and other steps, the values can be encoded into a single character.)

[0068] At step 212, Local News affiliates (FCC) are selected. Preferably the field is encoded with the FCC ID of preferred local news affiliates. This information is only included in the cookie if the client has chosen to have local news on their personalized front page.

[0069] At step 214, stock and index symbols are selected. In this step, the client can directly enter a list of stock symbols into an appropriate field, or the client may be presented with a list of all possible stock symbols to choose from, or the client may receive a page showing popular stocks and be provided opportunity to lookup or search for other symbols. This field of the cookie contains a comma-delimited list of the user's preferred stock symbols and index choices. Index choices are added as symbols to the list just like stocks. The available selection of stock and index symbols is generated from available local and third-party resources (e.g. the DOW, SP500, NASDAQ, AMEX, and RUS2000).

[0070] To increase the efficiency of dynamically adding stock symbols to a generated page, the format of the stock listing is stored in a format suitable for direct sending of the field to a quoting service without (significant) manipulation during generation of the page. When generating the client's page, the cookie field is sent to a quoting service as a query, and the results placed into the generated page. To reduce overhead, however, a selection of the most commonly inspected symbols are cached in a memory of the server. The cached information is used before retrieving data from the quoting service.

[0071] Alternatively, to avoid the overhead of dynamically retrieving data from the quoting service, the server instead could maintain a periodically updated cache of all stock values, from which the client directly retrieves information. This configuration would also allow the client to obtain data when the quoting service is temporarily offline. Such local data could be presented as stale data, if it is more than some time period old (say 15 minutes), and updates are not available. Server caching can also be used for other data requiring third party (or slow database, e.g., SQL) retrieval, such as real-time information for ticker headlines, weather data, sports scores, chat schedules, On Air schedules, local headlines, and astrology information.

[0072] At step 216, user Keywords are identified and stored. This field contains a comma-delimited list of the user's personal keywords. These keywords are client selected and can be used to search local or third-party resources to find particular topics of interest to the client. If defined, bit 11 of the Fast Bits is set to on, and personal topics included in the entry page.

[0073] At step 218, a second compressed array (More Bits) of Boolean values are determined. As with the Fast Bits, the More Bits contains 30 bits represented by 5 characters. As discussed above, different bit fields, and the regions within the fields, are preferably arranged to maximize opportunity to truncate field contents. In the exemplary embodiments, for example, user preferences have been divided into “Quick Setup” features (stored in the Fast Bits array), and other preferences which are stored in the More Bits array. If a user only performs a quick setup of user preferences, much or all of the More Bits will remain 0 (empty). The bits in this field correspond to the following properties:

[0074] At step 220, Individual preference bits are set. The Individual bits also contain a compressed array of Boolean values, encoded like the Fast bits field. The bits in this field relate to news clipping categories. In the FIG. 4 and FIG. 5 embodiments, these categories are supplied by a third party to illustrate the ability to seamlessly integrate the invention with third-party data resources. The categories are stored in a UPD property (record) in a database on the server. Presently, there are UPD properties IND1 through IND22, corresponding to:

[0075] However, it is understood that these are exemplary categories and other categories may be represented in such a compressed format.

[0076] At step 222, On Air bits are set. The On Air bits contain a compressed array of Boolean values, encoded in the same way as the Fast bits field. The bits in this field correspond to on air programs (programs being aired on television/cable systems). Note the absence of OASCHED3. OASCHED3 corresponds to a program that has been canceled, or otherwise relocated to another position within the bit field. (One might re-order the program list, for compression/truncation purposes.) As with other missing values, lack of a definition corresponds to a default 0/empty value.

[0077] As with the news clipping categories, the on air programs are stored in the UPD property of the server-side database. When a client completes a personalization process, and selects such some or all of the programs, matching entries in the server-side database are then added to the dynamically generated cover/entry page to a web site (this can be applied to any generated web page). Typically a retrieved database entry specifies the time and date of the next instance of the program, along with information about topics to be covered, or guests to be interviewed. However, other data, such as reviews or commentary regarding the program, or cross-references between the program and other programs or Internet resources, may also be supplied to the client.

[0078] Presently, there are UPD properties OASCHED1 through OASCHED28 , corresponding to:

[0079] At step 224, MLB, NFL, NHL, and NBA bits are set. Preferably broken into separate fields, each field governs the generation of a scoreboard on a personalized page. Each field is either empty to indicate that no scores should be displayed, or containing an asterisk (“*”) to indicate that all scores should be displayed, or containing a compressed array of Boolean values specifying which team scores should be displayed. As noted above, the client is presented with an interface to select preferences. Thus, for this field, an HTTP form can be generated with a series of check boxes, allowing the client to indicate what information is to be tracked. An all-inclusive option may be presented to indicate tracking all (“*”) options.

[0080] When generating a dynamic page, team inclusion is tested on the serer. The league bit arrays are expanded, where as discussed above, a single bit of each bit of each field corresponds to a particular team. So, for example, the first bit of the NFL field can correspond to Boston, the second bit to Buffalo, the third to Calgary, etc. For each selected team, the dynamically generated page will present news or game information related to the team. In addition, the server may also cross-reference information. So, if a client only requests information concerning Calgary, but Calgary happens to be playing against Boston, then the server can include information about the Boston-Calgary game. Similarly, any other Boston-related information that might be of interest to a Calgary fan, such as a player-trade, can also be presented to the client.

[0081] Note that in a preferred embodiment, personalization is effected through a graphical user interface (such as a web-page) that allows a client to directly navigate to different personalization interests. Thus, it is not required for a user to navigate the steps of FIG. 5 strictly in the order shown. If the client jumps to a particular personalization step, and then saves and exits from personalization, then the remaining personalization options have blank/empty values, and will be interpreted according to the default values for the missing information. It is also understood that the ordering of the steps of FIG. 5 is for example only, and that a different ordering may be imposed by a web page developer. Software code used in an exemplary embodiment is attached as Appendix A.

[0082] Thus, according to the teachings of FIG. 5, the contents of the FIG. 4 cookie corresponds a client having made the following personalization elections:

[0083] FIG. 6 shows a first exemplary personalized entry-page 250. Since web pages do not have a fixed page size, shown is two sections of the same page. At the top of the page 250 is a header section 252 common to all pages. Although not required, it is expected a common header will be provided at the top of an entry page, and customized page data will follow, or be intermixed with other default page content. If personalization has been performed, preferably the header will be modified to contain some personalization information, such as the client's name 254 (note use of proper possessive form, which was computed once during personalization), or an active marquee 256 (e.g. content can cycle over time) highlighting personalization data.

[0084] After the general header 252, a banner heading 258 such as “Personal Front” is used to demark the start of personalized web page data. In this particular example, the client requested that the personalized page include current weather 260, a four-day weather forecast 262, and international news 264 headings.

[0085] Also shown as item 266 is a personalization button. Selecting this button (it is understood that references to a button includes other activation methods as well, including image hot-spots, hypertext-links, etc.) initiates the personalization routines, and allows one to create or revise personalization settings in accord with the teachings of FIG. 5.

[0086] FIG. 7 shows a second exemplary personalized page. This second example was generated by selecting the personalization button 266 of FIG. 6. Selecting the button causes a preferences-selection box to be displayed, in which both linear and direct-access navigation methods are provided. In the linear method, the steps of FIG. 5 are presented in order, allowing the client to review all personalization options. In the direct-access method, a table of personalization buttons are presented for directly jumping to a personalization page for each available option category (e.g., weather, stocks, local new, international news, etc.).

[0087] As with FIG. 6, after the general header 252, the Personal Front banner demarks the start of personalized web page data. In this particular example, during the re-personalization process, the client has changed the weather personalization to display weather 270 and four-day forecast 272 for Seattle, Wash. instead of Portland, Oreg. And, instead of displaying international news, the client has elected to instead receive domestic news coverage 274.

[0088] From the foregoing, it will be recognized that the illustrated embodiment of the present invention minimizes communication between the web browser and server, while speeding generation and presentation of user-customized web pages.

[0089] Having described and illustrated the principles of my invention with reference to an illustrated embodiment, it will be recognized that the illustrated embodiment can be modified in arrangement and detail without departing from such principles. Accordingly, I claim as my invention all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.

[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]



[Inline image omitted. See PDF.]