In-line sign in

[0001] The invention relates to computer networks. In particular, the invention relates to signing into a network server on the computer network.

[0002] With the increasing popularity of the Internet, more network servers require users to sign in thereto. Signing in has numerous benefits for both the user and the network server. The network server benefits by gaining information about the user. Such information may include the user's email address, name, geographical region, and commercial and/or personal preferences, etc. Accordingly, the network server may use such information in a variety of commercially beneficial ways.

[0003] The user benefits by having a more dynamic and personalized user experience. In this sense, the network server, as presented to the user in the form of a web page, may have a different look and feel or different advertising based on the user's preferences, past experiences, etc. Thus, the site displays information more relevant to the user.

[0004] At least in some instances, a network server (first network server), when signing in a user, chooses to use another network server's (second network server) sign in methodology. This alleviates the first network server from creating and maintaining its own sign in process and allows the second network server to generate revenue through licensing its sign in methodology. However, a user attempting to sign into the first network server which is using the sign in methodology of the second network server, has heretofore been presented with a sign in screen that has the look and feel of the second network server and not of the first network server. This unexpected and potentially misleading situation may be upsetting to the user and detracts from the first network server's user experience. As a result, such situation can deter the first network server from using the second network server's sign in methodology.

[0005] Therefore, a need exists for a method and an apparatus for allowing a first network server to use the functionality of a second server's sign in methodology yet still maintain the look and feel of the first server during such sign in. That is, a need exists for an in-line sign in method.

[0006] The present invention satisfies the aforementioned need by providing a method of in-line sign in that allows a user to sign into a first server based on a sign-in methodology of a second server. The method allows the first server to use, within its own user interface, the functional sign-in methodology of the second server. Such method provides a seamless and effective sign-in process for the user by not detracting from the user experience provided by the first server.

[0007] In the method, an authentication response, including an address of the second server and an executable script, is received from the first server at a computing device of the user. The executable script is then executed in the computing device. Executing the executable script includes issuing a request to the address of the second server for state information and receiving such state information from the second server. Then, based on the state information, the computing device determines whether the user is authenticated to the second server.

[0008] If the user is authenticated to the second server, the computer device issues a request to the second server for vouching information for authenticating the user at the computing device to the first server. If the user is not authenticated to the second server, the computer device displays a login module to collect login information to authenticate the user to the second server. The login module is presented to the user within the context of the look and feel of the first server web page. When the user enters their login information into the login module of the computer device, then the computer device will POST (HttpRequest) the information to the second server. Accordingly, the user is not startled or upset by the sudden appearance of a foreign web page such as that from the second server.

[0009] Other features of the invention are further apparent from the following detailed description of the embodiments of the present invention taken in conjunction with the accompanying drawings, of which:

[0010] FIG. 1 is a block diagram of an exemplary networking environment in which aspects of the present invention may be implemented;

[0011] FIG. 2 is a flowchart illustrating the process of a user signing in to a first server using the authentication methodology of a second server in accordance with one embodiment of the present invention; and

[0012] FIG. 3 is a block diagram illustrating the process of a user signing in to an affiliate server using the signing in methodology of an authentication server in accordance with one embodiment of the present invention.

[0013] In the present invention, a first server authenticates a user based on state information from a second server. In particular, a user at a computing device requests content from a first server. The user first receives an authentication response from the first server. The authentication response from the first server includes an address of the second server and an executable script. The computing device of the user, typically through a web browser, parses the authentication response and, in doing so, executes the executable script. Executing the script includes issuing a request to the second server for state information and receiving the state information from the second server. After receiving such state information, the computing device/browser determines, based on such state information, whether the user is authenticated to the second server.

[0014] If the user is authenticated to the second server, the computer device/browser issues a request to the second server for vouching information for authenticating the user to the first server. If the user is not authenticated in the second server, the computer device/browser displays a login module for collecting login information for authenticating the user to the second server. Importantly, the login module is presented to the user within the context of the look and feel of the first server web page. Accordingly, the user is not upset by the sudden appearance of a foreign web page such as that from the second server.

[0015] FIG. 1 illustrates an exemplary network environment in which aspects of the invention may be implemented. A client computer system 100 is coupled to a network 102. In this example, network 102 is the Internet (or the World-Wide Web). However, the teachings of the invention can be applied to any data communication network. Multiple affiliate servers 104, 106, and 108 are coupled to network 102, thereby allowing a user at a computing device or user computer system 100 to access web servers 104, 106, and 108 via the network. Affiliate servers 104, 106, and 108 are also referred to as web servers and network servers. An authentication server 110 is also coupled to network 102, allowing communication between the authentication server and user computer system 100 and web servers 104, 106, and 108. Although referred to as an authentication server, authentication server 110 is also a web server capable of interacting with web browsers and other web servers. In this example, data is communicated between the authentication server, user computer system, and web servers using the Hypertext Transfer Protocol (HTTP), a protocol commonly used on the Internet to exchange information. Other protocols may be used without departing from the scope of the present invention.

[0016] An authentication database 112 is coupled to authentication server 110. The authentication database 112 contains information necessary to authenticate users and also identifies which elements of the user profile information should be provided to a particular affiliate server when the user accesses the affiliate server. Although the authentication database 112 is shown separately from the authentication server 110, in other embodiments of the invention, the authentication database 112 is contained within the authentication server.

[0017] The term affiliate server is defined herein as a web server that has registered or otherwise established a relationship or affiliation with the authentication server 110. Each affiliate server 104, 106, and 108 includes a code sequence (not shown) that allows the affiliate server to share information with the authentication server 110 when a user (who is also registered with the authentication server) requests access to the affiliate server. Each affiliate server is assigned a unique ID, which the affiliate server transmits to the authentication server, thereby identifying itself to the authentication server.

[0018] FIG. 2 is a flowchart illustrating the process of a user signing in to an affiliate server 104 using the authentication methodology of an authentication server 110 in accordance with the present invention. According to the present invention, at step 200, a client requests content from the affiliate server 104. Typically, content is requested by the user at the computer system 100 by either typing a URL of a network server or clicking on a hyper link associated with such URL.

[0019] The affiliate server 104 determines locally whether the user is already authenticated at such affiliate server 104 at step 205. In one embodiment of the present invention, if the user is authenticated at the affiliate server 104 using the authentication methodology of the affiliate server 104, the user may access the affiliate server 104 at step 210. However, if the user is not authenticated at the affiliate server 104, the affiliate server 104, in response to the user's request for content, sends the user's computer system an authentication response at step 215.

[0020] The authentication response may be in the form of an HTML page or a portion thereof, and may include, in pertinent part, a JavaScript tag and at least one executable script. The JavaScript tag includes an address of the authentication server 110 (whose authentication methodology is to be used by the affiliate server 104) having state information concerning the user. The at least one executable script may include or refer to an Application Program Interface (API) provided to the affiliate server 104 by the authentication server 110 and may contain at least one information segment. The information segment receives the state information for the user from the authentication server as will be described below.

[0021] After receiving the authentication response, the browser or the like on the user's computer system parses the authentication response. In doing so, at step 220, the browser encounters the JavaScript tag that directs the user's computer system 100 to the authentication server 110 to retrieve state information concerning the user. At this point, the computer system 100 passes state information to the authentication server 110. The state information is retrieved from the authentication server 110 and is sent to the user's computer system 100. The user's computer system 100 at step 225 receives such state information from the authentication server 110 and appropriately places the state information in the information segments in the executable script.

[0022] Importantly, and in accordance with one embodiment of the present invention, the affiliate server 104 incorporates the JavaScript tag and the executable scripts into the authentication response in any manner. In particular, the authentication response from the affiliate server 104 may be embodied within a web page having the look and feel of the affiliate server 104, even though information is being sent to and received from the authentication server 110. Thus, the affiliate server 104 can use the functionality of the authentication methodology of the authentication server 110, in any manner desired. To the user, the user experience does not change because the affiliate server 104 always maintains control of the user experience through the HTML page. As a result, a seamless sign-in process is provided to the user, i.e. the user is not displayed a screen from the authentication server 110 having a different look and feel. Therefore, to the user, it appears that the user's computer system 100 never left the affiliate server 104 even though the user's computer system 100 has contacted the authentication server 110 and employed the authentication methodology thereat on behalf of the affiliate server 104.

[0023] After the computer system 100 receives the state information from the authentication server 110, the browser of the computer system 100 executes the executable script using such state information. In one embodiment of the present invention, the executable script employs the received state information as input to functions associated with the aforementioned API's, where the functions result in an output that signifies whether the user is indeed authenticated by the authentication server 110. Such authentication is described more fully in U.S. patent application Ser. Nos. 09/349619 and 09/350018, which are hereby incorporated by reference in their entirety. Notably, an appropriate authentication process may be employed by the authentication server 110 and the executable script at the computer system 100 without departing from the scope of the present invention.

[0024] In one embodiment of the present invention, if the browser of the computer system 100 determines the client is indeed authenticated, the executable script may direct the user computer system 100 to the authentication server 110 to retrieve vouching information at step 230. The vouching information serves to represent to the affiliate server 104 that the user is in fact authenticated by the authentication server 110. In one embodiment, the vouching information is written by the authentication server 110 according to a secret shared with the affiliate server 104. The secret may be any appropriate secret without departing from the scope of the present invention.

[0025] Upon receipt of the vouching information, the browser of the computer system 100 forwards the same to the affiliate server 104 at step 235. As may appreciated, the affiliate server 104 employs the vouching information and the secret shared with the authentication server 110 to read the vouching information and after doing so the affiliate server 104 in fact signs in the user thereto. The aforementioned U.S. patent application Ser. Nos. 09/349619 and 09/350018, already incorporated by reference herein, describe the process as performed by the affiliate server 104 in more detail.

[0026] If the user is not authenticated at the authentication server 110, the executable script may direct the user computer system 100 to display a login screen for the user to input user information with regard to such authentication server 110, as at step 240. As may be appreciated, the inputted user information includes such items as a user identification and password with regard to the authentication server 110, and is forwarded by the browser on the computer system 100 to the authentication server 110.

[0027] The computing device 100 may then receive an acknowledgement from the authentication server 110 that the user is authenticated to the authentication server 104. In one embodiment the present invention, the acknowledgement is in the form of cookies or the like. However, other forms of acknowledgement may be used without departing from the scope of the present invention. Thereafter, the browser of the computer system 100 may direct the user computer system 100 to the authentication server 110 to retrieve vouching information and forwards the same to the affiliate server 104, in the manner of steps 230 and 235 as discussed above, and the affiliate server 104 signs in the user thereto. Once the user is logged into the authentication server 110, the affiliate server 104 may then send the content to the user in response to the user's original request.

[0028] As shown in FIG. 3, the method of FIG. 2 is shown in terms of the flow of data between the servers 104, 110 and the computer 100. As seen, a user at client computer system 100 requests content from the affiliate server 104 at step 300. If the user is authenticated at the affiliate server 104 then the user may enter a domain operated by the affiliate server 104. If not, and the affiliate server 104 determines the user needs to be authenticated, then at step 305, in response to the request for content, the affiliate server 104 sends the user's computer system 100 an authentication response as part of an HTML page.

[0029] The user computer system 100 parses the HTML page. In doing so, the JavaScript tag within the authentication response directs the user's computer system 100 to the address of the authentication server 110 at step 310 to retrieve state information concerning the user. The state information is then sent by the authentication server 110 to the client computer system at step 315. The client's computer system 100 receives state information from the authentication server 110 and executes the executable scripts based on the state information to determine if the user is already logged on to the authentication server 110. If the client is already logged on the authentication server 110, the user computer system 100 is directed by the executable script to the authentication server 110 at step 320 to retrieve the vouching information as at step 325.

[0030] If the client is not already logged on the authentication server 110, and in one embodiment of the present invention, the executable script causes the web browser to display a login screen for the user to input login information. Importantly, the login screen is constructed within the context of the look and feel of the site as operated by the affiliate server 104. The information collected through the use of the login screen is sent by the browser of the computer system 100 to the authentication server 110 at step 330 and the authentication server 110 returns the state information at step 335.

[0031] Thereafter, the browser requests vouching information from the authentication server at step 340 and receives the vouching information at step 345. The vouching information is then forwarded by the browser to the affiliate server at step 350 and the affiliate server 104 logs the user therein. The affiliate server 104 returns the information as originally requested by the user at step 355 which may be substantive in nature or may be an introductory splash screen or the like.

[0032] In the present invention, and as seen in FIG. 3, the affiliate server 104 and the authentication server 110 never communicate directly, at least when logging in the user to the affiliate server 104. Instead, all communications are through the user computer system 100. As may be appreciated, such an arrangement facilitates the use of cookies that are stored on the computer 100 to identify the user to both servers 104, 100. Nevertheless, the servers 104, 110 may communicate directly without departing from the scope of the present invention.

[0033] In the present invention, the in-line sign in process is characterized by the executable script and related items as sent by the affiliate server 104 to effectuate all communications between the computer system 100 and the authentication server 110. Thus, the user need not be bothered with such tasks and is in fact unaware that such communications are taking place. Thus, such sign in with the affiliate server 104 is seamless or nearly so, even with the involvement of authentication server 110. Moreover, even if the user must input information to be sent to the authentication server 110 as at step 240 of FIG. 2, such information is inputted into a page constructed to have the look and feel of the site operated by the affiliate server 104 so that the page is a view associated with the affiliate server 104 and the user is not started to see a different view from the authentication server 110 which has a different look and feel.

[0034] The programming necessary to effectuate the processes performed in connection with the present invention is relatively straight-forward and should be apparent to the relevant programming public. Accordingly, such programming is not attached hereto. Any particular programming, then, may be employed to effectuate the present invention without departing from the spirit and scope thereof.

[0035] As should now be understood, the present invention provides a method of in-line sign in that allows a user to sign into a first server based on state information from a second server. The method allows the first (affiliate) server to use, within its own user interface, the functional sign-in methodology of the second (authentication) server. Changes could be made to the embodiments disclosed above without departing from the broad inventive concepts thereof. For example, the invention could be practiced on two unaffiliated servers rather than an authentication server and an affiliate server. It is understood, therefore, that the present invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.