Method for verifying the identity of a user for session authentication purposes during web navigation

FIELD OF THE INVENTION

[0001] The present invention is in the field of network browser navigation and authentication methods and pertains particularly to a method for site verification of a user.

BACKGROUND OF THE INVENTION

[0002] Internet browser navigation, typically referred to as “Web surfing” in the art, is well known as a mechanism enabling user access to server-stored electronic information pages on a navigable network such as the Internet network. A typical user navigating the Internet for example may be subscribed to many password-protected Web sites that offer some form of service to the user. Examples of password-protected sites may include financial service sites such as investment, mortgage, and online banking sites, travel sites, certain entertainment and music sites, news service and information sites, and so on.

[0003] Typically, a user will have a variety of different passwords and/or personal identification numbers (PIN) that must be provided to successfully log in to many of the types of sites described above. As a result, a user is frequently required to enter login information as new password protected sites or pages are navigated to. A Web browsing session embarked to conduct a large chunk of Web business, for example, may involve several logins during one Internet session. Having to remember many passwords and PIN numbers can be problematic for a user.

[0004] One way to deal with this problematic scenario that is known to the inventor has been to aggregate and manage a user portfolio of passwords and other login information at a secure proxy/portal location such that automated aggregation and automated logins, when required are performed using the appropriate stored passwords from the user profile. Although this method is secure and fairly error free, some users are never the less uncomfortable having a third party manage their security passwords and other critical information.

[0005] In prior art, a federated convention known as domain name service (DNS) exists that provides a look-up service for IP addresses on a network for navigating purposes. The service finds an IP address for a querying machine. The IP address is a temporary network address comprising numbers separated by dots. IP addresses are both allocated and assigned depending on the type of use and class of the address. Every desktop machine and network server capable of TCP/IP communication has DNS software installed. A client machine that is transient will retain the same IP address only while it is logged on to the Internet during a single network session. While DNS system can identify a specific machine during a multi-site browsing session, it cannot provide any specific user information.

[0006] It has occurred to the inventor that if the host of a password protected or otherwise secure Web site or Web function could identify a user remotely by knowing the user ID at a level that is more granular than the IP address and could validate the state of a current session from a reliable source, then it could gain efficiency by servicing the user as logged in

[0007] Therefore, what is clearly needed in the art is a distributable user verification system and service that can authenticate user to site hosts along any navigation sequence and enable the user to avoid repeated login procedures that may have otherwise been required along the navigated route.

SUMMARY OF THE INVENTION

[0008] In a preferred embodiment of the present invention a network-based software application for enabling remote authentication of a user during a network session is provided, comprising a server portion for serving session validation information and additional user information when queried, a client portion for configuring and submitting parameters constraining what and how data is to be shared with a querying entity or entities, and a distributed portion for distribution and application at various connected network nodes for enabling those nodes to recognize and interact with the server portion. The application is characterized in that the server portion generates a temporary session token after a first successful authentication by the user at a web site during a network session, the token cached at the host machine of the server portion and at the user's machine or proxy machine and wherein upon navigation by the user to a next web site or form requiring secure authentication, the token is used to identify the user and a remote call is used to validate the user session instead of requiring manual authentication procedures.

[0009] In a preferred embodiment the network is the Internet network and the session is a browser session. Further, the communication between nodes for user session validation may be XML-based, HTML-based, or RPC-based.

[0010] In preferred embodiments the first successful authentication before token generation may be a manual login procedure to a web-site. Also in preferred embodiments the first successful authentication before token generation may be a successful purchase.

[0011] In some cases the distributed portion is code that is distributed to a node from the client portion at first connection. The code may be self-installable at the receiving node.

[0012] In another aspect of the invention a method for verifying an on-line user remotely is provided, comprising steps of (a) generating a token for a user session the token containing at least one set of authentication data just entered to gain access to a first secure site or function during the session; (b) storing the generated token at the user machine or proxy machine and at the issuer site; (c) delivering the generated token from the user to the first site; (d) recognizing the generated token at the site and using the token information to validate the user as the user navigates the site; (e) delivering the token to a new site navigated to wherein the new site is hosted by a new sever; and (f) recognizing the generated token at the new site and using the token information to validate the user as the user navigates the new site.

[0013] In some preferred embodiments, in step (a), the authentication data is a username and password used to login to the site. In other preferred embodiments, in step (a), the authentication data is wallet information used to carry out a purchase. In step (b) the issuer may be an ISP for the user. In some cases, in step (c), the first site is the ISP web site. In step (d) validation may include a remote call to the issuer site of the token.

[0014] In some cases, in step (d), navigating the site includes subsequent logins and/or secure purchasing using the same sever. In step (e) the new server and site may be accessed within the same user session. Further, in step (f) the receipt of the token may provide data for identifying user name and the user's IP address as well as the issuer's machine address.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0015]FIG. 1 is a system overview of a navigable network where distributed verification services are practiced.

[0016]FIG. 2 is a process diagram illustrating a distributed user name service and verification resolution method according to an embodiment of the present invention.

[0017]FIG. 3 is a screen shot of a configuration window of the software of the present invention.

[0018]FIG. 4 is a flow diagram illustration user/system steps for verification.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] The inventor provides a novel method and apparatus for enabling remote site-verification of a user during Web surfing across multiple sites, avoiding any requirement for manual login procedures at password-protected web sites subscribed to by the user. The method and apparatus of the present invention is explained in enabling detail below.

[0020]FIG. 1 is a system overview illustrating a navigable network <b>100</b> wherein a user verification service according to an embodiment of the invention is practiced. Communications network <b>100</b> primarily consists of a data packet network (DPN) <b>102</b> labeled herein the Internet network. It may be assumed that sub-networks and COST networks are also part of network <b>100</b>. In this example, a public-switched telephone network (PSTN) <b>114</b> is illustrated as a connecting sub-network to Internet <b>102</b>. An Internet service provider (ISP) <b>110</b> is illustrated between an illustrated user <b>116</b>, and Internet <b>102</b>.

[0021] Internet <b>102</b> is represented in this example as a network cloud and also by an Internet backbone <b>101</b> extending through cloud <b>102</b>. Backbone <b>101</b> represents all of the lines connection points and equipment making up the Internet network as a whole. Therefore, there are no geographic limits to the practice of the present invention. The inventor chooses the Internet network in this example because of availability of known standard protocols and high public accessibility. In alternate embodiments, the invention could be applied to other wide-area-networks (WAN).

[0022] Within Internet <b>102</b> there are several Web servers (WS) illustrated and shown having data connectivity to backbone <b>101</b>. These are WS <b>108</b>, WS <b>103</b>, WS <b>104</b> and WS <b>105</b>. WS <b>103</b>-<b>108</b> are Internet file severs adapted to serve electronic information pages known as Web pages in the art. These servers represent any type of on-line service host that is available to users logged into and navigating the Internet. For example, server <b>108</b> may be a bank server, server <b>103</b> may be a shopping club server, server <b>104</b> may be an investment server and server <b>105</b> could be an entertainment server such as an on-line movie server. There are many such possibilities. The type of service a user accesses is not relevant to the present invention. However a goal of the invention is to enable a user to traverse password protected Web-sites during normal Web navigation and not have to log in to any of the secure sites that normally would require that the user log-in.

[0023] Servers <b>103</b>, <b>104</b>, <b>105</b>, and <b>108</b> have instances of DNS software (<b>106</b>) installed and operative therein. Each instance of DNS may be considered as identical to the others, hence one element number <b>106</b> is given for all illustrated instances. DNS software <b>106</b> functions in cooperation with at least one DNS server machine not shown here, but a part of network <b>102</b>. DNS server software <b>106</b> is adapted to provide look-up service for network addresses to querying machines connected to the Internet according to known art. Typically a first DNS server would be that of a user's ISP such as ISP <b>110</b>. However, there could be many DNS servers including root servers involved in returning a portion of or all of a network address to a querying machine.

[0024] Within ISP <b>110</b> there is illustrated a modem bank <b>113</b>. Modem bank <b>113</b> is adapted to connect users through to the Internet as is known in the art of dial-up/modem Internet connection. Modem bank <b>113</b> is connected by digital link <b>119</b> to a connection server (CS) <b>111</b>. CS <b>111</b> is connected to Internet backbone <b>101</b> by way of an Internet access line <b>120</b>. CS <b>111</b> has a unique instance of software termed user name service (UNS) software by the inventor and given the element number <b>112</b> in this example.

[0025] UNS software <b>112</b> is adapted to lookup and provide a user name to go along with the user's IP address. CS server <b>111</b> is adapted to hold pertinent user information in encrypted format in such as a database (not shown) internal to or external from CS <b>111</b>. Persistent user information would include username/password information to ISP services and possibly additional information for logging into other service sites. User information may also include contact data such as e-mail address, phone numbers, physical address, and so on. User information may further include wallet information such as a social security number, credit card numbers, and so on.

[0026] On the other side of modem bank <b>113</b> there is shown a PSTN network (<b>114</b>) and a local telephone switch <b>115</b>. Local switch <b>115</b> represents a local telephony switch such as a PBX or ACD type switch. User <b>116</b> is connected to switch <b>115</b> within cloud <b>114</b> by way of a telephone line <b>118</b>. It is noted that there are other types of Internet-connection architectures, any one of which can be used in the practice of the present invention. A dial-up connection as illustrated herein should not be construed as a limitation of the invention.

[0027] User <b>116</b> is illustrated as a PC icon in this example, however it should be noted that other types of network-capable equipment can be substituted for a PC. User <b>116</b>, also referred to herein at times as PC <b>116</b>, has a Web browser or Client Application <b>117</b> operational and adapted under the right circumstances to enable Web-browsing as known in the art. Using application <b>117</b>, user <b>116</b> can visit any reachable server in network <b>102</b>. Client application <b>117</b> has a DNS configuration control (not shown) that functions to query a DNS server for an address for navigation as is known in the art. Similarly, every machine that logs on to network <b>102</b> receives a temporary IP address from the network, typically through the connecting ISP. The addresses are temporarily assigned for transient machines (not connected at all times) and are only valid under a current network session.

[0028] Connection server <b>111</b> has an instance of the unique User Name Service (UNS) software <b>112</b> provided therein and adapted, in one embodiment, as an extension to DNS software already operating within server <b>111</b>. UNS software <b>112</b> provides an extra level of realization to DNS, being a user name or ID associated with an IP address. In this example, ISP <b>110</b> is considered the service provider that will provide the service of the present invention. In another embodiment, a third party other than ISP <b>110</b> may provide the service of the invention. All that is required to practice the invention is at least one network data source requiring authentication, an issuer to generate an authentic token and a network end node accessible from an operating data network. The end point hosting the client capability may be a proxy server of the client, a client desktop computer, an application on the desktop, or even a peripheral communication with the desktop computer. The issuer can be an ISP, or any other provider of services. In a preferred embodiment, the system of the invention is federated, meaning that users may have access to and practice the invention regardless of network access provider and method of connection.

[0029] In practice of the invention according to the instant embodiment and architecture of FIG. 1, user <b>116</b> logs in to network <b>102</b> by way of telephone line <b>118</b> through switch <b>115</b> in PSTN <b>114</b> and into modem bank <b>113</b> within ISP <b>110</b>. Connection server <b>111</b> completes an Internet connection on behalf of user <b>116</b> via access line <b>120</b> to backbone <b>101</b>. User <b>116</b> provides his user name and password at the time of access in order to obtain a browsing session first at his or her designated home page, typically served by CS <b>111</b>. It is noted that an IP address has been assigned to user <b>116</b>, which is to the user's machine.

[0030] CS <b>111</b> generates a session ID for user <b>116</b> and embeds it into a token, termed a UNS token by the inventor. In one embodiment a UNS token has the user name and password for the last manual authentication embedded therein as well as a session ID number and the IP address assigned to the user's machine <b>116</b> for the current network session. The UNS token also has the issuer information, in this case, the ISP machine address, also embedded therein. In one embodiment, the token is a reference number that can point to the information stored locally or in distributed fashion.

[0031] The UNS token is in one embodiment delivered to machine <b>116</b> and cached therein in a local browser cache. The session token is also cached at UNS provider/server CS <b>111</b>. When user <b>116</b> decides to browse to another universal resource locator (URL) that requires a password say, for example, one served by WS <b>108</b>, the user's UNS token is sent to the server hosting the URL. Server <b>108</b> recognizes the UNS token and accesses CS <b>111</b> to verify that the UNS token is valid (has not timed out, has same IP address, etc.). If the UNS token is valid, then user <b>116</b> can avoid an authentication login requirement at server <b>108</b> and he or she will be serviced as if logged in with a password.

[0032] As long as a session ID is still valid, user <b>116</b> may browse and make purchases etc, at various sites without being required to log in. XML based protocol is, in a preferred embodiment, used in machine-to-machine “paging” when verifying a user's active session. In another embodiment RPC procedures can be used. UNS resolution borrows DNS convention for typical domain lookup and adds one more level, that of user ID to the session as well as session issuer information as described above. Using this technique, user <b>116</b> may browse and access any URL hosted by servers <b>108</b>, <b>103</b>, <b>104</b>, and <b>105</b> without being required to supply any passwords and the like created or issued in accordance with the user's subscriptions. Moreover, each mentioned server can remotely page the session issuer over a secure connection for additional encrypted user information, such as credit card numbers, and so on for automated purchases. Node-to-Node communication can be XML-based, for example, Simple Object Access Protocol (SOAP), or perhaps Security Assertion Markup Language (SAML) over a secure connection, or some other machine-to-machine protocol such as RPC.

[0033]FIG. 2 is a block diagram illustrating a UNS resolution and authentication method according to an embodiment of the present invention. In this example, a user <b>200</b> is illustrated as logging in to a Web Page (WP) #<b>1</b>, which is given the element number <b>201</b>. WP#<b>1</b> is maintained within a Web server as is known in the art. A bi-directional arrow placed between user <b>200</b> and WS <b>201</b> illustrates network connection. WS <b>201</b> is assumed to be a Web server that requires user verification at a login page to enter. At login user <b>200</b> provides a username and password to WS <b>201</b>. Server <b>201</b> uses DNS to resolve network addresses from domains typed in by the user into his or her browser software. This is illustrated by a region labeled DNS Domain, and given the element number <b>205</b>. Within DNS domain <b>205</b> there are machines <b>202</b> and <b>203</b> illustrated and labeled .com and xxx.com. The inventor simply illustrates that more than one machine may be involved in resolving a machine address from a domain name.

[0034] In this example, user <b>200</b> has to manually log in to access WP#<b>1</b>. This is because user <b>200</b> has not yet received his or her UNS token. A UNS service provider <b>211</b> is provided and adapted to generate and return a UN S token upon a first request on behalf of a user subscribed to the service of the invention. In one embodiment, provider <b>211</b> is a user's ISP and server <b>206</b> is a connection server analogous to CS <b>111</b> described with reference to FIG. 1 above.

[0035] In an embodiment wherein the user's ISP is also the UNS service provider, user <b>200</b> will already have a UNS token to send at login at WP#<b>1</b>. The connection server would have generated it at the time of ISP login. In some embodiments, a user may have WP#<b>1</b> (<b>201</b>) configured as a first home page (the first page the user sees). In this case, the ISP login procedure is transparent to user <b>200</b> (remembered at user station), but manual login is required at WP#<b>1</b>. In any case, a UNS token must be requested, generated and sent by a UNS service provider <b>211</b> during a successful manual login (for authentication purposes) regardless of where the login occurs in order to establish a UNS session that enables user <b>200</b> to avoid subsequent login and other form population requirements. It is noted herein that the term manual login includes not only user-name and password submission sessions, but also may include authentication protocols using Web certificates, public key infrastructures, and biometric authentications such as retinal scans or fingerprint scans. For the purposes of this specification, manual login shall include any type of authentication procedure wherein a user must actively and physically participate.

[0036] A Web page (WP#<b>2</b>) is illustrated herein and given the element number <b>204</b>. WP#<b>2</b> (<b>204</b>) represents a subsequent login page navigated to some time after WP#<b>1</b> (<b>201</b>) was visited. It is assumed herein that user <b>200</b> visits WP#<b>2</b> during the same Internet session. WP <b>204</b> is maintained in the same or in a different server than the server hosting WP <b>201</b>. When user <b>200</b> accesses WP#<b>2</b> he or she already has UNS token <b>210</b> to deliver to the login server. After receiving UNS token <b>210</b> at the server hosting WP#<b>2</b>, the server makes a connection to the token issuer, UNS service provider <b>211</b>. UNS server <b>206</b> has UNS token <b>210</b> also in cache locally. The verification call can be of an XML-based, HTML based, SOAP-based, RPC-based, or any other machine-to-machine protocol.

[0037] A Web page (WP)#<b>3</b>, also given the element number <b>209</b>, is illustrated as yet another subsequent Web page visited by user <b>200</b> during the same session using UNS token <b>210</b>. WP#<b>3</b> receives UNS token <b>210</b> and verifies the session by calling Server <b>206</b> as was described with reference to page #<b>2</b> above. As long as the session is still valid according to server <b>206</b>, which is the generator and issuer of UNS token <b>210</b>, user <b>200</b> will not have to provide a username, password or other identifying code to be treated as logged in to WP #<b>3</b>.

[0038] During navigation of WP #<b>3</b>, user <b>200</b> may select, for example, something to buy, and be served a WP#<b>4</b>, also designated <b>207</b>, and labeled BUY. Normally, a secure form (WP#<b>4</b>) would be served to user <b>200</b> in order that user <b>200</b> may enter his or her wallet and access order information. However, because the hosting server now has UNS token <b>210</b> and has already validated the session at log-in, it can simply contact server <b>206</b> at provider site <b>211</b>, obtain the appropriate wallet information and re-validate the session if need be during the same transaction. User <b>200</b> would, instead of getting an order form, get an order confirmation, barring some error in the automated processing, in which case an error message would be served.

[0039] It is noted herein that if service provider <b>211</b> is an ISP and server <b>206</b> is a connection server, and if user <b>200</b> connects to WP#<b>1</b>-<b>4</b> using server <b>206</b>, then the server hosting WP#<b>1</b> will receive UNS token <b>210</b> at the time of login and user <b>200</b> will not have to input any login data. However, if service provider <b>211</b> is a third party not hosting user access to the Internet, then WP#<b>1</b> would require a manual login and UNS token <b>210</b> would verify user <b>200</b> according to username and password used at WP#<b>1</b>. User <b>200</b> configures the type and amount of information that he or she is willing to provide any Web sites or only certain Web sites. More about user configuration options is described below.

[0040]FIG. 3 is an exemplary user configuration window <b>300</b> according to an embodiment of the present invention. Window <b>300</b> is a user configuration window that resides on, or is downloaded to, a user desktop to enable user interaction. Window <b>300</b> is adapted to configure user information such that he or she wants Web sites to have upon request. Window <b>300</b> contains a section <b>301</b> that is adapted for accepting user-personal wallet information. Reading from top left to bottom right, there are sub-sections labeled First Name, Int. (Initial) and Last Name. In a second row are sections labeled Address, Birth Date, and SS# (social security).

[0041] In a third row within section <b>301</b> are sub-sections labeled Mother's Maiden (Name), CC Info/Exp. (Information and Expiration date), and Employer (Information). Section <b>301</b> may contain further sections for inputting additional information without departing from the spirit and scope of the invention. Furthermore, section <b>301</b> may have sections that are prioritized. For example, primary credit card information may be included as well as secondary or alternate card information.

[0042] Immediately below section <b>301</b> is a section <b>302</b> adapted for inputting Web site type and item of information to make available to a specific site. For example, a user may wish that all of his information except his social security number be given to a certain type of Web site upon request. Typically, the information would be transferred when a user makes an on-line purchase or the like. Perhaps all financial Web sites have authorization to request and receive certain user information while entertainment sites cannot request the same. A section <b>303</b> is provided and adapted to enable a user to apply a certain data-share configuration to all sites listed as favorites. A section <b>304</b> is provided for inputting other types of profile data such as hobbies, interests and so on. A submission button <b>305</b> is provided and adapted to enable submission of configuration data to the service provider for application.

[0043] Window <b>300</b>, when configured, tells the service provider exactly what information can be shared with which Web sites. UNS software is also provided as an extension to DNS software installed on every machine in the network. In one embodiment, Web entities may subscribe to the UNS service of the invention. In this case they may have UNS software applications provided and installed locally. In another embodiment, the UNS service is activated at any Web server by sending an executable code from the provider to a particular server, wherein the executable installs itself to DNS software and executes in accordance with client interaction within the server.

[0044] As an example, when the client using UNS accesses a login page, UNS on the server will recognize the client and look for a token. If the server finds the UNS session token, then it can call the service provider to validate the session, and will not have to require manual login procedures. If the server does not get the token from a UNS client, then manual login procedures commence and a token is then generated at the service provider using the last entered username and password.

[0045]FIG. 4 is a flow diagram illustrating user/system steps for client verification. At step <b>401</b> a user running UNS software logs into a Web site hosted by a Web server. The hosting server may be an ISP-maintained server that is part of a user ISP subscription, or it may be a third party server hosting any Web site. At step <b>402</b>, the server looks for a UNS token, and if found, places a remote call to the issuer of the token to validate the user session. If no token is sent to the server at step <b>402</b>, then one must be generated at the service provider. The instant user name and password input into login can be used as security data for the generated session token.

[0046] If a UNS token already exists and is verified at step <b>402</b>, then at step <b>403</b> manual login is bypassed and the user is serviced as secure and logged in. At step <b>404</b>, the user clicks on a buy icon or other secure function. Step <b>404</b> assumes that the purchase or data-access option activated by the user is part of the same Web site and host server that already has the user's UNS token. At step <b>405</b>, the UNS token is re-validated and additional user information is requested from the service provider site. The information shared is sufficient to make the purchase or other secure function such that no manual data input is required of the user.

[0047] At step <b>406</b>, the user navigates to a server hosting a new Web site that requires a login procedure. It is noted herein that the same server may also host the new site or it may hosted by a different server. In the case of a same server hosting the site, the server already has the UNS token. In the case of a new server, the user sends the UNS token once connected to the new site in step <b>407</b>. The new site verifies the token as was described in step <b>402</b> with a remote call to the service provider site. The process ensues with step <b>403</b>.

[0048] In one embodiment, once servers have retrieved a UNS token, they may cache the token so that additional remote calls to verify the owner of the token are not required. This is true as long as the user is still within the server domain of the original access and token transfer. However, the token may expire and have to be re-activated if it expires while the user is still in session. In one embodiment, this can be avoided by embedding a token re-activation module in HTML of visited Web pages in the server. In this embodiment, a re-activation of the user session occurs on a periodic basis wherein the period configured for the purpose is less than the expire-time of the token. There are many possibilities.

[0049] It will be apparent to one with skill in the art that the process described with reference to steps <b>401</b>-<b>407</b> may be practiced in conjunction with the current DNS convention such that the additional level of User ID can be leveraged to facilitate verification at the application level of Internet protocols. It should also be apparent that there may be more or fewer steps comprising the UNS process without departing from the spirit and scope of the invention. The process may be slightly altered dependent upon which entity provides the UNS service, be it an ISP or a third party. The method and apparatus of the invention may be adapted to use existing IP address format in a session token when identifying a machine. In one embodiment, a unique identifier could be an e-mail address with the name up front for incorporation into a unique session token. There are many such possibilities.

[0050] The method and apparatus of the present invention should be afforded the broadest scope under examination considering all possible embodiments, said examination conducted according to accepted patent law. The spirit and scope of the present invention is limited only by the following claims.