throbber
United States Patent [19]
`Kunzelman et al.
`
`US006041357A
`[11] Patent Number:
`[45] Date of Patent:
`
`6,041,357
`Mar. 21, 2000
`
`[54] COMMON SESSION TOKEN SYSTEM AND
`PROTOCOL
`
`[75] Inventors: Kevin Kunzelman, San Francisco;
`Sterling Hutto, Sausalito, both of Calif.
`
`[73] Assignee: Electric Classi?ed, Inc., San Francisco,
`Calif.
`
`[21] Appl. No.: 08/796,260
`[22]
`Filed:
`Feb. 6, 1997
`
`[51] Int. Cl.7 ............................. .. H04L 9/00; G06F 13/14
`[52] US. Cl. ............................ .. 709/228; 380/49; 380/25;
`395/187.01
`[58] Field of Search ............................. .. 395/186, 187.01,
`395/188.01, 200.48, 200.59, 200.33, 200.57;
`380/49, 25
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6/1993 Gasser et al. ........................... .. 380/30
`5,224,163
`7/1996 Carlson et al. ..
`395/186
`5,542,046
`5,689,638 11/1997 Sadovsky ....... ..
`395/18801
`5,706,349
`1/1998 Aditham et a1.
`.. 380/257.01
`5,708,780
`1/1998 Levergood et al. .
`.. 395/200.59
`
`5,740,242
`5,774,670
`
`4/1998 Minor et al. . . . . . . . . .
`. . . . . . . .. 380/49
`6/1998 Montulli .......................... .. 395/200.57
`
`OTHER PUBLICATIONS
`
`Yoshida, H.; “The Age of Customized Web Site”, Web
`Developer (Winter 1996) Tech Spotlight, located at http://
`W3.COM/CGI—BIN/W3 CPM/PWS/W3 .
`.
`. JhbIdXBWi
`F92—XXfDgM—wZ8WXcC1mT666J, pp. 1—5.
`“IETF Hypertext Transfer Protocol (HTTP) Working
`Group” located at http://www.ecs.uci.edu/pub/ietf/http/, pp.
`1—5.
`
`A. Hutchinson, et al., “An Extension of the HTTP Authen
`tication Scheme to Support Server Groups”, located at
`http://www.ics.uci.edu/pub/ietf/ht
`ft—trommler—http—eXt—groups—00.tXt, pp. 1—10.
`PM. Hallam—Baker, et al., “Session Identi?cation URI”,
`located
`at
`http://www.es.net/pub/internet—drafts/
`draft—ietf—http—session—id—00.tXt, pp. 1—10.
`D.M. Kristol, et al., “Proposed HTTP State Management
`System”, located at http://www.research.att.com/~dmk/
`cookie—2.9.tXt, pp. 1—17.
`
`Primary Examiner—Pinchus M. Laufer
`Attorney, Agent, or Firm—Philip H. Albert; Townsend and
`Townsend Crew
`
`[57]
`
`ABSTRACT
`
`An improved session control method and apparatus includes
`a client which establishes a session with a ?rst server such
`that the ?rst server can identify the client. When the client
`wishes to migrate from the ?rst server to a second server, the
`client requests a session token from the ?rst server. The
`session token is a data element generated by the ?rst server
`which is unique over the client-server network being navi
`gated and identi?es the particular session with the ?rst
`server. The session token is preferably a dif?cult to forge
`data element, such as a data element digitally signed using
`the private key of the ?rst server. The session token is passed
`from the client to the second server to initiate migration to
`the second server. If session data is too bulky to be passed
`as part of the session token, the second server may use data
`from the session token to formulate a request to the ?rst
`server for additional data needed to handle the state of the
`session. To minimize the transmission of data, the second
`server might maintain a version of the bulk session data and
`only request an update to the version of the data indicated in
`the session token.
`
`13 Claims, 3 Drawing Sheets
`
`10
`"x
`
`Servenside
`Migration Program
`
`22
`
`Server-side
`Migration Program
`
`22
`
`Client-side
`Migration Program
`
`1
`
`EX 1016
`IPR of Pat. No. 6,892,304
`
`

`

`U.S. Patent
`
`Mar. 21,2000
`
`Sheet 1 of3
`
`6,041,357
`
`10
`"I
`
`Server-side
`Migration Program
`
`22
`
`Server-side
`Migration Program
`
`22
`
`‘E?
`Ill
`g5
`E
`iii]
`iilili?iii]
`
`16
`
`g 148
`El
`E5
`:1
`iiili ii
`nnnuiiun
`
`SERVER A
`
`\
`
`,
`
`SERVER B
`
`\\
`‘\
`
`\
`
`‘\
`
`\
`\
`\
`i
`
`+
`
`18C
`
`ll
`,’
`A205
`
`I
`
`I
`I
`I
`I
`
`+
`
`Client-side
`Migration Program
`
`CLIENT
`
`FIG. 1
`
`2
`
`

`

`U.S. Patent
`
`Mar. 21,2000
`
`Sheet 2 of3
`
`6,041,357
`
`CLIENT
`
`SERVER A
`
`SERVER B
`
`81
`I
`/ CLIENT-SERVER
`REQUEST
`4 INTERACTION ‘
`SERVICE
`‘
`I
`'
`I
`
`SERVICE
`REQUESTS
`
`'
`f
`I
`:
`l
`l
`
`l
`
`I
`l
`I
`I
`I
`I
`'
`I
`I
`I
`I
`I
`I
`
`I
`I
`I
`
`l
`
`I
`I
`
`P2
`MIGR
`URL‘
`
`I
`194
`;
`SESSION
`TOKEN
`
`I
`
`|
`
`>
`
`53
`/
`PROCESSES
`MIGRATION
`REQUEST AND
`RESPOND
`
`I
`l
`
`I
`
`l
`l
`I
`l
`l
`l
`l
`l
`I
`l
`l
`
`i I
`I
`I
`I
`
`S8
`,J
`
`RECEIVE
`
`l
`I
`l
`
`106
`H
`‘I1
`
`104-
`
`32
`H
`V
`CLIENT SELECTS
`A MIGRATION
`OPTION
`
`84
`/
`RECEIVE AND _
`PASS SESSION
`TOKEN TO B
`
`ERROR
`
`‘
`
`S12
`,1
`CONTINUE
`SESSION WITH A
`NEvv SERVER
`813
`v
`/
`REQUEST
`SERVICE
`
`‘
`
`85
`,
`
`PROCESS
`I
`' SESSION TOKEN
`
`OF-BAND DATA
`
`REQUEST
`FROMA
`
`§9
`
`PARSE
`RESPONSE
`
`v:
`ACCEP
`MIGRATION
`EQUEST'?
`Y
`S11
`,1
`PROCESS
`REQUEST&
`OPEN A SESSION
`814
`v
`/
`SERWCE
`REQUESTS
`
`‘
`'
`
`A
`
`REQUEST
`ANDREPLY
`I
`
`I
`I
`I
`I
`I
`I
`:
`I
`;
`I
`
`I
`
`I
`I
`I
`108
`IU _
`I
`'
`I
`I
`110
`\iI DENYMESSAGE N
`I
`I
`I
`112
`I
`m ACCEPT MESSAGE
`I
`I
`;
`;
`;
`I
`I
`I
`I
`I CLIENT-SERVERINTERACTION I
`I
`I
`
`I
`
`I
`
`FIG. 2
`
`I
`
`I
`
`3
`
`

`

`U.S. Patent
`
`Mar. 21,2000
`
`Sheet 3 of3
`
`6,041,357
`
`104 SESSION ID (300)
`
`SESSION INFORMATION (302)
`
`I
`SETg/ER :
`
`SESSION ‘D DIGITAL
`SEFFg/RIER SIGNATURE
`
`CREATE
`TIME
`
`EXP'RAT‘ON
`
`SE
`U R
`ID
`
`E MAIL
`—
`ADDR
`
`PHONE
`NUMBER
`
`POSTAL
`ADDR
`
`'
`
`NODE
`
`W
`PLAIN TEXT
`
`V
`CIPHER TEXT
`
`FIG. 3
`
`400
`/
`
`104
`/
`
`RDEECHIELSST
`
`SESSION TOKEN
`
`[106
`
`FIG. 4
`
`4
`
`

`

`1
`COMMON SESSION TOKEN SYSTEM AND
`PROTOCOL
`
`6,041,357
`
`2
`the ?rst server, the second server Will interrupt the naviga
`tion process to require authoriZation information from the
`client. The usefulness of hypertext documents is greatly
`diminished if a user must enter a neW login name and
`passWord each time a link is taken.
`Session control for a single document is knoWn. A URL
`for a document available in a sessionless environment might
`be a character string of the form:
`http://server.host.domain/directory/subdir/?le
`With “http:/ ” indicating the protocol, “server.host.domain”
`uniquely identifying the server, and “directory/subdir/?le”
`identifying the document to be served. Where the document
`is not to be accessible to other than an authoriZed client, the
`URL might be of a form similar to the sessionless URL:
`http://server.host.domain/dir...?le?userfred+passWord
`In the session-speci?c URL, the user’s name and pass
`Word are included in the URL. While this is useful for
`making a reference to a single document for a speci?c user,
`it is not useful for passing sensitive session information
`because, the user name and passWord being in plaintext, it is
`too easily tampered With.
`Thus, What is needed is a method and apparatus for
`maintaining a seamless and secure migration of a session
`betWeen a client and a ?rst server to a session betWeen the
`client and a second server, Where the ?rst and second servers
`are independently controlled.
`
`SUMMARY OF THE INVENTION
`An improved session control method and apparatus is
`provided by virtue of the present invention. In one embodi
`ment of the present invention, a client establishes a session
`With a ?rst server such that the ?rst server can identify the
`client. When the client Wishes to migrate from the ?rst server
`to a second server, the client requests a session token from
`the ?rst server. The session token is a data element generated
`by the ?rst server Which is unique over the client-server
`netWork being navigated and identi?es the particular session
`With the ?rst server. The session token is preferably a
`dif?cult to forge data element, such as a data element
`digitally signed using the private key of the ?rst server and
`possibly encrypted. The session token might also be
`encrypted, using public key encryption or other methods, to
`prevent the session token from being easily readable.
`The session token is passed from the client to the second
`server to initiate migration to the second server. In some
`embodiments, session data is too bulky to be passed as part
`of the session token. In such cases, the second server uses
`the session token to formulate a request to the ?rst server for
`the data needed to handle the state of the session and the ?rst
`server provides the data to the second server. To minimiZe
`the transmission of data, the second server might maintain a
`version of the bulk session data and only request an update
`to the version of the data indicated in the session token.
`In the preferred embodiment, the token is passed in a URL
`(Uniform Resource Locator). HoWever, it also might be
`passed as an HTTP “cookie”.
`A further understanding of the nature and advantages of
`the inventions herein may be realiZed by reference to the
`remaining portions of the speci?cation and the attached
`draWings.
`
`BACKGROUND OF THE INVENTION
`
`The present invention relates to the ?eld of client-server
`protocols. More speci?cally, one embodiment of the inven
`tion provides for seamless migration of a session from one
`independent cooperating server node to another.
`The global Internet has emerged as a model of a distrib
`uted netWork of netWorks. One application for Which the
`Internet is increasingly used is to interconnect hypertext
`transfer protocol (HTTP) servers to clients. The hypertext
`transfer protocol is used to serve documents containing
`hypertext references to client “browsers” on client systems
`connected to the Internet. The documents served by an
`HTTP server Will often have hypertext references embedded
`in the document Which refer to documents on the HTTP
`server or documents on a completely different server. With
`such an arrangement, millions of documents have been
`linked to form the World Wide Web, Which is an allusion to
`the fact that these hypertext links might look like a spider
`Web if a diagram of the documents and the links Were draWn.
`Hypertext, as such, Was used in other contexts, such as
`help documentation, but those uses generally connected to a
`central document repository or even a single ?le With
`references to locations internal to the ?le. What made the
`World Wide Web more interesting and complex is the fact
`that a link in a ?rst document stored on a ?rst server might
`refer to a document on a second server Where the author of
`the ?rst document and the system operator of the ?rst server
`had no editorial or system control over the second document
`or the second server.
`This independence of servers did not inhibit the naviga
`tion of a client from server to server, since the reference for
`the link to be folloWed Was fully contained in the document
`Where the reference Was made. These self-contained refer
`ences to information are referred to as “uniform resource
`locators” (URLs) because the reference Was all that Was
`needed to locate the “linked-to” document. Since the URL is
`a static data element, it is the same for every client, so the
`linked-to server could not identify Who the client Was.
`Several solutions to this shortcoming have been in common
`use.
`The most common solution is to eliminate the need to
`knoW Who the client is. If the identity of the client is not
`needed, an HTTP server Will serve documents to any client
`Which requests a page. Of course, this solution is only
`practical Where the author of the linked-to document does
`not Want to place any restrictions on Who may vieW the page.
`If the author of the linked-to page Wants to place restrictions,
`the client Will have to enter into a “session” With the server
`Where the client is ?rst authenticated prior to the server
`alloWing access to the server.
`One consequence of such an architecture is that, Without
`some session control, the clients and servers must operate in
`a “stateless” manner, i.e., not tracking client identity, or any
`other variables, from request to request. Session control,
`When used, is usually done by a server requesting a login
`name and a passWord from the client prior to serving
`documents. Where all the documents are stored on a single
`server or a centrally controlled cluster of servers, session
`control only need occur When the client ?rst visits the server.
`If a link from one document references a document on the
`same server, the session can be seamlessly continued from
`the perspective of the client. HoWever, if the link is to a
`document on a second server not commonly controlled With
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a client-server netWork With
`Which the present invention is used.
`FIG. 2 is a ?oWchart of a session migration process
`according to the present invention.
`
`65
`
`5
`
`

`

`3
`FIG. 3 is a schematic of a session token.
`FIG. 4 is a schematic of a request for out-of-band data.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`FIG. 1 illustrates an overall structure of a client-server
`network 10 With Which the present invention is used. Net
`Work 10 is shoWn comprising a client 12, tWo servers 14A,
`14B, the Internet 16, server connections 18A, 18B to Inter
`net 16 and a client connection 18C to Internet 16. As should
`be apparent, more than tWo servers might be coupled by a
`netWork to one or more clients, and the netWork need not be
`the global Internet, but can be any other netWork of coop
`erating independent servers. One alternative platform for the
`present invention is an intranet rather than Internet, Where
`the intranet is an internal netWork Within an organiZation
`using Internet protocols to communicate internal data.
`Depending on the siZe of the organiZation, the intranet might
`comprise several cooperating, but independent servers.
`In operation, server 14A interacts With client 12 via
`Internet 16 by sending and receiving data packets directed
`at, and received from, client 12. Client 12 also sends packets
`to and receives packets from server 14A via Internet 16.
`Thus, at a netWork level higher than the transport level, there
`exists a logical channel 20A connecting client 12 to server
`14A. The equivalent can be said about server 14B, Which
`connects to client 12 via a logical channel 20B.
`Server 14A and 14B are cooperative servers in that they
`both understand that client 12 might migrate from one server
`to another and facilitate that process. Unlike a centraliZed
`access control system, hoWever, servers 14A and 14B are
`separately controlled.
`An example of session migration Will noW be described
`With reference to a migration of client from a server A to a
`server B, Which might be client 12, server 14A (source
`server node) and server 14B (target server node). The
`session migration process begins When client 12 takes an
`action Which is to result in a session migration. The session
`migration moves the client’s interaction from channel 20A
`to channel 20B in a Way that is transparent to the client’s
`user, but that also maintains any necessary state, including
`state variables Which indicate a level of authoriZation for the
`client’s use of the session.
`One instance Where migration is useful is Where an
`operator of a Web server Wants to out source the operation
`of a particular aspect of their Web site. For example, a
`neWspaper might operate a site Which provides neWs, fea
`tures and classi?eds, but Will out source the management of
`the classi?eds to another operator, such as Electric
`Classi?eds, Inc., of San Francisco, Calif. (the assignee of the
`present application). A migration occurs When a user selects
`a classi?eds “button” or selection on a Web page operated by
`the neWspaper. The URL associated With the button can
`either be a direct reference to the target server or a reference
`Which causes redirection. In the former case, the page
`containing the button is presented to the user With the
`underlying HTML anchor including a session token for use
`in migration. This is possible Where the source server can
`anticipate that a migration may occur. In the latter case, the
`server need not anticipate the migration and the anchor for
`the button Will be a URL directed at the source server. The
`source server responds to the URL With a redirection URL.
`The redirection URL Would be the equivalent to the embed
`ded URL With a session token in the former case.
`A session migration using a redirection URL is illustrated
`in the ?oWchart of FIG. 2. FIG. 2 shoWs a number of steps
`
`10
`
`15
`
`35
`
`45
`
`55
`
`65
`
`6,041,357
`
`4
`identi?ed as S1, S2, S3, etc. Which are performed in ascend
`ing numerical order unless otherWise indicated. Before the
`migration process begins, the client is in a session With
`server A (step S1). The client sends requests to server A and
`server A services those requests. HoW server A services
`those requests depends on What the request is and the current
`state of the session. For example, for some requests, server
`AWill only respond to the request if the state of the session
`With the client indicates that the client is logged in as an
`authoriZed user. The state might also include variables Which
`modify the interaction With the client, such as the client’s
`user’s demographics. If the demographics indicate the geo
`graphic location of the user or the users age, gender, etc., the
`server might modify advertisements presented to the client
`accordingly. If the demographics indicate that the user is a
`sophisticated user, the server might send less help text in
`exchange for quicker transmission times. When such state
`variables are used, it should be apparent from this descrip
`tion that the server to Which the client is migrating needs to
`have the same state variables so as to present a consistent
`style across the migration. State variables might also indi
`cate What actions the client has already done, to alloW for
`activity tracking and caching. Activity tracking is useful for
`Web broWser clients, so that the navigation of the client can
`be tracked. Caching is useful for many types of clients and
`might be used to avoid sending data the server knoWs the
`client already has.
`In step S2, the client makes a selection Which server A
`determines Will be migrated. In the case of embedded
`migration (not shoWn), server AWould have anticipated the
`possible migration and included the migration information
`in an HTML anchor on the page. Server Aoptionally veri?es
`if the client is permitted to migrate and then serverAreturns
`(step S3) a session token 104 to the client as part of a URL.
`By including the session token as part of the URL, a standard
`broWser (i.e., one Which is not aWare of migration
`capabilities) can be used. The structure of a session token is
`shoWn in Table 1 and illustrated in FIG. 3.
`
`TABLE 1. SESSION TOKEN ELEMENTS
`
`. Server Node Identi?er
`. Unique Session Identi?er for the Server Node
`. Time of session creation
`. Expiration (Time-to-live) of session
`User ID
`E-mail address
`. Telephone number
`. Postal address
`. Digital Signature
`The server node identi?er can be almost any type of
`identi?er, including numerical values or ASCII strings. The
`server node identi?er might be an identi?er speci?c to
`cooperating servers or could be a unique code already in use
`by the server such as its four-byte IP address or six-byte IP6
`address. The only requirement is that no tWo cooperating
`server nodes share the same identi?er. The session is
`uniquely identi?ed by the ?rst tWo elements in the session
`token, since the second element is unique Within the source
`server node. By dividing the session identi?er into tWo
`pieces, We alloW for the decentraliZed generation of session
`identi?ers. Some of the session token elements, such as the
`e-mail address, telephone number and postal address, might
`be optional elements.
`As shoWn in FIG. 3, a session token such as session token
`104 is divided into a plaintext portion 300 containing the
`session ID and a ciphertext portion containing the encrypted
`session information 302 to alloW for more secure transport
`
`6
`
`

`

`6,041,357
`
`5
`of session token information. With public key encryption,
`the information can be made secure by digitally signing it,
`to prevent forgery, or by encrypting it, to prevent forgery and
`to prevent others from reading the session data. In Table 1,
`the encrypted session information is the third through eighth
`elements, Which are not required to uniquely identify the
`session. Therefore, these ?elds can be sent encrypted yet be
`decrypted at the target server node using an encryption
`method and key speci?c to the session. If the encryption
`method and key is the same for all session tokens from a
`particular source server node, the second element can also be
`encrypted. Encryption of the session speci?c information is
`preferred, so that unauthoriZed parties cannot vieW the
`information. In some embodiments, the information in the
`session token is not readable by the client even When the
`client is in possession of the session token. Of course, the
`user might be able to vieW his or her oWn session informa
`tion through the use of a dummy server. A dummy server
`accepts the user’s migration like any other server, but then
`does nothing more than display the session information.
`Table 1 shoWs but one example of a format for a session
`token. After reading this description, the person of ordinary
`skill Will understand that other formats are possible, so long
`as the format have certain properties. For example, session
`tokens must be unique so as to uniquely identify a session
`and must be such that they can be generated in a distributed
`environment, i.e., Without a centraliZed session token gen
`erator. They should be difficult for unauthoriZed parties to
`modify or forge. They must also be able to pass information
`about the session, or at least refer to information about the
`session, Which may then later be transferred out-of-band.
`While the system may operate Without digital signatures, the
`use of digitally signed session tokens is preferred. Adigitally
`signed session token is signed using the source server node’s
`private key so that the digital signature can be veri?ed using
`the source server node’s public key. Using a digital signature
`alloWs the authenticity of the token to veri?ed.
`Once the client receives the session token from server A,
`the client sends session token 104 to the target server node,
`server B (step S4). Server B processes session token 104
`(S5), performing the necessary veri?cation and decrypting
`of the session token. In some cases, the session token makes
`reference to “out-of-band” data, i.e., data Which is not
`contained Within the session token but Which is state infor
`mation needed for migration. Out-of-band data is used to
`keep session tokens from being too large, or for tighter
`access control. For example, the user’s postal address might
`be speci?ed as a pointer to a speci?c record of a database
`controlled by server A. Server B checks to determine if
`out-of-band data is needed (S6). If out-of-band data is
`needed, server B forms a request 106 for the data using
`session token 104 and sends request 106 to server A (S7).
`Session token 104 is part of the request so that server A can
`verify that server B is making an authoriZed request. FIG. 4
`shoWs the structure of request 106, Which is an envelope
`containing request details 400 and the session token 104. In
`some embodiments, not all the session information is passed
`to the source server node.
`When server A receives request 106, it supplies the
`out-of-band data to server B (S8) in a response 108. Server
`B parses and stores response 108 (S9) and proceeds to step
`S10. If out-of-band data is not needed, server B proceeds
`directly from step S6 to step S10. At step S10, server B
`decides Whether to accept the server migration request
`represented by session token 104. If server B decides not to
`honor the migration because the identi?ed client is not
`authoriZed to use server B, server B does not support that
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`particular migration, or any other reasons, server B sends an
`error message 110 back to the client. OtherWise, server B
`processes the information in session token 104 and out-of
`band data 108, if used, and sends an acceptance message 112
`to the client (S11). Acceptance message 112 can either be a
`server to client message or a server to user message such as
`a Welcome message. In the former case, the transition might
`be a transparent transition. The client responds (S12) by
`transitioning to the neW session and requesting services from
`server B (S13) Which server B services using the migrated
`state information (S14).
`Versioning
`To minimiZe the retransmission of data that a target server
`node already has, the target server node may choose to cache
`out-of-band data obtained from a source server node. Of
`course, in a distributed netWork, cache consistency can be a
`problem. Cache inconsistencies might occur When session
`information changes and a client is not connected to the
`target server node caching the data. It is important for those
`changes to Work their Way around to other server nodes.
`A method for doing this is to encode a version identi?er
`Within the session token such that Whenever any out-of-band
`type session information changes, the source server node
`Will change the version identi?er. Then, Whenever a neW
`session token is generated by the source server node, the
`neW version identi?er Will be passed on to a target server
`node. If the version identi?er Within the token indicates that
`other information neWer than the data that the target server
`node previously has used, the target server should request
`neW out-of-band session information from the source server
`node.
`Different granularities of version numbers may be used
`for out-of-band session information. For example, a single
`version number may represent the state of all out-of-band
`data items, or multiple version numbers may represent
`certain subsets of the out-of-band data. The granularity does
`not affect the cache updating per se. Instead, the granularity
`of versioning merely determines hoW much data must be
`re-transferred in the case of the change of session informa
`tion.
`One application for the present invention is Within the
`World Wide Web, Where session tokens are encoded Within
`URLs. When a session is to be migrated from a source server
`node to a target server node, a neW URL Will be generated
`for a session token. A client application Will then make a
`request to the target server node using this URL. The target
`server node Will then decode this session token, verify its
`authenticity (using public key cryptography) and obtain any
`necessary out-of-band session information before continu
`ing With the request. Preferably, the session token is limited
`in siZe so that most broWsers and HTTP handlers can
`correctly process the session token as a URL. A limit many
`broWsers have for URLs is 1 kilobyte. If the session infor
`mation is greater than the limit, some of the session infor
`mation is sent as out-of-band data.
`In the preferred embodiment, the encoded session token
`Will be in a modi?ed Base-64, Which is a standard encoding
`for MIME email documents (Multipurpose Internet Mail
`Extensions). A Base-64 data stream is a stream of 6-bit
`numbers represented by an alphabet of 64 alphanumeric
`characters (usually the uppercase letters A—Z, the loWercase
`letters a—Z, the digits 0—9, and the characters ‘+’ and ‘/’. For
`our purposes, We use a modi?ed Base-64 Wherein ‘—’ and
`‘i’ are used in place of ‘+’ and ‘/’ so as to generate HTTP
`compliant URL’s.
`
`7
`
`

`

`6,041,357
`
`7
`Before it is encoded into modi?ed Base-64 for transmis
`sion using HTTP, the session token has the format shoWn in
`Table 2.
`
`TABLE 2
`
`Web Session Token Format
`
`Bytes
`
`Description
`
`Token Format ID
`Session Identi?er
`Length (N) of data to folloW
`Session Data
`CRC Checksum (32 bit)
`
`The Token Format ID should be Zero. This ?eld is
`reserved as a Way to specify neW token formats should there
`be a need to change them in the future. The session identi?er
`is a 64-bit ID comprising 16 bits (2 bytes) for a server node
`ID and 48 bits (6 bytes) for a unique session ID for the server
`node. This assumes a cooperating netWork of 2316 servers or
`feWer each assigned a unique server node ID. The N bytes
`of session data is encrypted With target server node’s public
`key and digitally signed With source server node’s private
`key. Encryption is done using a public key cryptosystem
`supplied by RSA Data Security, of Palo Alto, Calif., or
`similar cryptosystem.
`Before the session data is encrypted and signed, it has the
`folloWing format, Which is very similar to the RFC 822
`electronic mail header format:
`
`In this format, a key and its associated value are separated
`by a colon (and optional Whitespace) and key/value pairs are
`separated by neWline characters. An example of session data
`is as folloWs:
`Version-Date: Fri Dec 30 10:14:46 PST 1994
`User-ID: Fred
`Email-Address: fred@fred.org
`Telephone: @123.Fred.Telephone
`Postal-Address: @123.Fred.Address
`The “Telephone:” key value, “@123.Fred.Telephone”, is
`an indirect reference to session information Which indicates
`that Fred’s telephone number is actually held at server node
`123 and should be queried from that server node, using the
`data identi?er “Fred.Telephone”. To implement the out-of
`band transferal of session information, a simple transfer
`protocol for making queries over a secure out-of-band
`channel is used. The secure out-of-band channel (depending
`upon the circumstances) may be implemented as a private,
`dedicated physical link (such as a dedicated, private T1 line),
`or may be implemented as a secure link over a public
`netWork using an encrypted tunnel (such as With SSL,
`Secure Sockets Layer).
`A querying server node Wishing to obtain session infor
`mation from a source server node Would simply open a
`connection With the source server node, identify itself (the
`querying server node), get authenticated and then make a set
`of queries to obtain session data. The folloWing is an
`example of the process Where a querying server node
`(identi?ed as server node 456 in this example) connects to
`a source server node (identi?ed as server node 123) to
`request out-of-band data:
`
`10
`
`15
`
`35
`
`45
`
`55
`
`65
`
`Ser
`
`Output
`
`123
`
`456
`
`123 Connected to server 123, please identify and
`authenticate self
`Server:
`456
`Signature REOp5XtI5XtIpWx1tBY6maOWRXuyNZ
`Server 45 6 authenticated,
`please make your requests.
`456 Fred.Telephone, Fred.Address
`123 Fred.Telephone:
`(345) 555-1212
`Fred.Address:
`12345 Main Street
`AnytoWn, USA 98765-1234
`
`456 QUIT
`123 Goodbye, server 456.
`
`In addition to the above-described applications, other
`applications can be found for the present invention. One use
`of transparent session migration is a child ?lter. If a child is
`logged into a service, that child may see different informa
`tion than if an adult Were logged into the same service. As
`the child migrates from server to server, an indication that
`the user is a child Will be included in the session information
`so that the target server node can adjust its content accord
`ingly.
`The above detailed description explains hoW to make and
`use a session migration method and apparatus according to
`the present invention. The above description is illustrative
`and not restrictive. Many variations of the invention Will
`become apparent to those of skill in the art upon revieW of
`this disclosure. The scope of the invention should, therefore,
`be determined not With reference to the above description,
`but instead should be determined With reference to the
`appended claims along With their full scope of equivalents.
`What is claimed is:
`1. In a client-server netWork having multiple independent
`servers, a method of session migration from a session
`betWeen a client and a ?rst server to a session betWeen the
`client and a second server;
`establishing a current session betWeen the client and the
`?rst server after the ?rst server has veri?ed that th e
`client is an authoriZed client of the ?rst server;
`sending a migration request from the client to the ?rst
`server;
`in response to the migration request generating a session
`token;
`sending a session token from the ?rst server to the client,
`Wherein the session token uniquely identi?es the cur
`rent session betWeen the client and the ?rst server;
`sending the session token from the client to the second
`server as a request to the second server for migration;
`verifying, at the second server and from the session token,
`the identity of the client and the ?rst server;
`requesting, from the ?rst server, data about the session,
`Wherein the request is sent from the second server;
`responding from the ?rst server to t

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.