METHOD AND SYSTEM FOR PROVIDING AN ONLINE INDUSTRY HUB

Abstract: A method and system for commingling proprietary information and presenting it to a user (300). The user (300) is only able to view information from hub participants with whom he has an active account. The present invention allows a user (300) to access proprietary information from several distinct entities through a single sign-on. The user (300) enters his user authentication information once. After signing on with one server (310), the user (300) can access resources on a second server (320, 340, 350) without signing on again. The first server (310) generates an URL string containing user authentication information that is provided to the second server (320, 340, 350). The user (300) can access the resources on the second server (320, 340, 350) seamlessly. The user (300) is able to view commingled information (210) through the system of the present invention using a persistent navigator bar to move to the websites of hub participants. The system of the present invention generates a cross-reference list of hub participants and hub-enabled users in order to determine which information is available to users.

Description: METHOD AND SYSTEM FOR PROVIDING AN ONLINE INDUSTRY HUB BACKGROUND OF THE INVENTION Field of the Invention The present invention relates to conducting commerce utilizing the Internet, and more particularly to a method and system that integrates the major producers of goods and services within an industry on the Internet into one "network" targeting the same customer audience. The system of the present invention provides an "industry hub" that enables users to navigate seamlessly between the websites of hub participants in a single sign-on session. Background of the Invention Advances in computer processing power and network communications have made information from a wide variety of sources available to users on computer networks. Computer networking allows network computer users to share information, software applications and hardware devices and internetworking enables a set of physical networks to be connected into a single network such as the Internet. Today, computers connected to the Internet have almost instant access to information stored in relatively distant regions. Moreover, computers connected to networks other than the Internet also have access to information stored on those networks. The World Wide Web (Web), a hypermedia system used on the Internet, enables hypertext linking, whereby documents automatically reference or link other documents located on connected computer networks around the world. Thus, users connected to the Internet have almost instant access to information stored in relatively distant regions. A page of information on the Web may include references to other Web pages and may include a broad range of multimedia data including textual, graphical, audio, and animation information. For example, a website resource can be a PDF document, an image file, a CGI program with interactive forms, or a Java applet. Currently, Internet users retrieve information from the Internet, through the Web, by 'visiting' a website on a computer that is connected to the Internet. A website is, in general terms, a server application that displays information stored on a network server computer. The website accepts connections from client programs, such as Internet browser applications. Browser applications, such as Microsoft Explorer ™ or Netscape Internet Browser ™, allow Internet users to access information on the website. Most browser applications display information on computer screens and permit a user to navigate through the Web using a mouse. Like other network applications, Web browsing uses the client-server paradigm. When given the Uniform Resource Locator (URL) of a document, the browser application becomes a client and it contacts a server application specified in the URL to request the document. After receiving the document from the server application, the browser application displays the document for the user. When the browser application interacts with the server application, the two applications follow the Hyper-Text Transport Protocol (HTTP). HTTP allows the browser application to request a specific article, winch the server application then returns. To ensure that browser applications and server applications inter-operate unambiguously, HTTP defines the exact format for requests sent from the browser application to the server application as well as the format of replies that the server application returns. As the number of physical networks connected to the Internet continues to grow, the number of websites that are accessible to Internet users likewise increases. Use of the Internet has grown significantly, and millions of users ranging from individuals to corporations now use permanent and dial-up connections to use the Internet on a daily basis. This significant increase in Internet access and use has resulted in a new method of conducting business - electronic commerce. Many Web servers have been developed through which vendors advertise and sell services and products. Providers of products and/or services use the Internet to offer better and faster services to consumers. In addition to increased Internet usage, there has also been an increase in the use of corporate Intranets. An Intranet uses similar protocols and has a similar user interface as the Internet, however, an Intranet is a private network that is contained within an enterprise. An Intranet may restrict or refuse access to its network by users outside of a defined group, such as users who are not employees of a corporation. An Intranet may consist of many interlinked local area networks (LAN) and may also use a wide area network (WAN). Typically, an Intranet includes connections through one or more gateway computers to the outside Internet. Hereinafter, any description of the Internet is also applicable to Intranets, unless otherwise specified. The Internet maintains an open structure in which exchanges of information are generally made cost-free without restrictions. The free access format inherent to the Internet, however, presents difficulties for those information providers requiring control over their Internet servers. For example, a company may need to share confidential information with a specific group of users, or a company may want to provide specific services over its Internet server only to customers having service contracts or accounts. Without means for identifying each client, a website cannot provide information on the network on a confidential or preferential basis. Different websites require different levels of security. For example, some websites contain only public, cost-free documents. Anyone can access documents on such a non-secure site. Some websites may contain public information, which anyone can access, along with proprietary information, which only selected users can access. Other websites may require all users to register or have an account before any type of access is permitted. Typically, these secure sites require users to enter user authentication information, such as username and password, each time the user enters the site. Every application or site that requires a username/password as a way of authenticating a user has its own rules for creating this user authentication information. Some applications make users pick their own username, others use email addresses or some combination of the user's first and last names to create a username. Some applications may require a password of at least 8 characters, while others will allow shorter passwords, so frequently users will have to use different passwords for different sites. With all of the different possible combinations of usernames and passwords, users usually end up with multiple usernames/password combinations for the different websites they use. In addition to security concerns, some sites may track users or may store customized information about users. For example, a document may be displayed to the user having customization options relating to news, sports, entertainment, etc. Based on the options the user selects, the document only displays content related to those selected options. The site may retain the user-selected options so that the customized information is re-displayed when the user re-accesses the resource at a later time. Storing information relating to user activity or storing customization information for a user is called "tracking" a user. Using HTTP, each request for a Web page is independent of all other requests. For this reason, the Web page server has no memory of what pages it has sent to a user previously or anything about previous visits. A "cookie" is a mechanism that allows the server to store its own information about a user on the user's own computer. A cookie is information for future use that is stored by the server on the client side of a client/server communication. Typically, a cookie is a small piece of information sent by a Web server to store on a Web browser so it can later be read back from that browser. For example, a cookie may record user authentication information and preferences when using a particular site. Typically, cookies are only used to track users in non-secure areas. They may be also used to store user authentication information, such as username and password, for secure sites. By storing user authentication information, cookies may allow users to navigate multiple Web servers within the same domain without re-entering user authentication information. As the websites for a single company (or other entity) are typically all located on the same domain, it is possible to save user authentication information in a cookie for that entity. In this manner, users will only have to enter user authentication information a single time when accessing that entity's websites. However, websites that have different domain addresses cannot share a cookie, and therefore to navigate between secure websites on different domains, the user must separately enter user authentication information for each website. In addition to cookies, other various systems have been developed to control access to networks and simplify user authentication. For example, U.S. Pat. No. 5,708,780 to Levergood et al. shows a system that allows clients to access all controlled files within a protection domain without requiring further authorization. In this system, when a user requests an access-controlled file, the server subjects the request to a secondary server that determines whether the client has authorization or a valid account. While this system may be advantageous in centralized authentication models where networks of sites can be locked into a single authentication process, it does not work in a distributed authentication model. With the growth of electronic commerce, especially business-to-business electronic commerce, customers want to be able to easily compare goods and services offered by many different providers within the same industry. For example, in the financial services market, major financial services dealers, such as Goldman Sachs, Morgan Stanley Dean Witter and Salomon Smith Barney, have their own secure websites that provide a broad array of financial services and products to its customers. Institutional investors and brokers use the websites of these major financial services dealers to obtain research and trading information. Typically, each of these dealers has different investment strategies and information available. Therefore, brokers frequently have accounts with, and use the websites of, several major financial services dealers, rather than using the services of just one dealer. Currently, to compare the information and products offered by competitors in the financial services market, the customer must separately sign-on to each website and manually compare information. This requires the customer to maintain a separate account with each dealer, each with its own sign-on information. Additionally, as all of the websites are separate, it is very difficult to compare price and research information while online. For example, in the bond market, some dealers may specialize in High Yield bonds while others focus on municipals. In the bond market, information exchanges do not exist. Therefore, the customer tends to shop around for the best price. Most institutional investors have relationships with multiple dealers. The bond market (and financial services industry in general) is only one example of the type of environment where the customer has to manually sift through information gathered from many different sources in order to choose a dealer for his specific needs. For example, in the raw paper or chemical supplies industry, customers typically use many dealers to fulfill their requirements. Other such industries will be known to these skilled in the art, and are within the scope of this invention. Users quickly grow tired of entering user authentication information for every website they visit. In addition, a user may have different user authentication information for each website used, and remembering several different user names and passwords can be tedious. For users interested in purchasing products or services, the comparison process is very difficult, as they will have to manually visit each website to obtain the needed information. This can be detrimental to the dealers in that industry, as a user may only visit one or two sites before making a purchase, rather than visiting the websites of every dealer within that industry. Growth of the Internet demands a closer integration of websites that target the same customer audience. Therefore there is a need for a system that allows customers to seamlessly navigate related websites and use their resources. Such a system should only require a user to enter user authentication information once, while still providing proprietary information from diverse websites without requiring the user to re-enter user authentication information for each website. In addition, there is a need for a system that can provide the user with an integrated view of the information available from the dealers that participate in the system. SUMMARY OF THE INVENTION The present invention has been made in view of the above circumstances and solves these problems by providing an industry hub that allows users to easily navigate between proprietary websites and commingle the content, through a single sign-on session. One object of the present invention is to provide users with a single sign-on system that acts as an industry hub by allowing users to view resources on every server with whom they have accounts without signing on to each individual server. Another object of the present invention is to allow a first trusted server to pass user authentication information to a second trusted server so that the user does not have to enter additional sign-on information to use the resources on the second server. Another object of the invention is to provide a method of authenticating a user to use resources on at least two access-controlled servers through a single sign-on session. A further object of the present invention is to provide a data structure for the URL used to authenticate users in the disclosed single sign-on system. A further object of the present invention is to provide a system that commingles proprietary information and presents the commingled information to the user, such that the user is only presented with information from the entities with which he has an active account. Yet another object of the present invention is to provide a navigator that is persistently displayed to the user as the user moves to various websites within the system of the present invention. Yet another object of the present invention is to provide a method for creating a cross-reference list that identifies the hub participants with whom a user has an active account. Additional objects and advantages of the invention will be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. To achieve these and other objects, and in accordance with the purposes of the invention, as embodied and broadly described herein, one aspect of the invention includes a method for a first server to authenticate a user who is authenticated to use the resources on the first server to use the resources on at least a second server, by receiving a request to use resources on the second server from the user; generating a URL string identifying the requested resource on the second server that contains authentication information for the user; and transmitting the request to the second server. Another aspect of the invention includes a method of authenticating a user to use resources on at least two access-controlled servers located on different domains, where the first server receives user authentication information from the user; the first server validates the user authentication information; the first server receives a request from the user to use a resource on the second server; the first server generates a URL string identifying the requested resource on the second server; the first server provides the URL string to the second server; and the second server validates the URL string. A further aspect of the system includes a data structure of the URL used in the disclosed single sign-on system, where the URL data structure comprises a first field containing information to authenticate the user; and a second field identifying a requested resource. A further aspect of the system includes a website for an industry hub that provides an authenticated user with the capability to receive commingled information, whereby the commingled information includes information from the hub participants with whom the user has an account, by receiving a list of enabled users from each hub participant; receiving information from the hub participants to be displayed to enabled users; using the enabled user list to determine which hub participants the user is enabled with; for each enabled hub participant, commingling information into a single presentation of mformation; and displaying the commingled information to the user. A further aspect of the system includes a method for a user having accounts with multiple hub participants that are located on separate access-controlled servers to use resources provided by each hub participant in a single sign-on system, by entering first user authentication information at a first server; requesting a resource from a second server; and receiving the requested resource in the absence of entering additional user authentication information. A further aspect of the system includes a method for providing a persistent navigator that contains links to every hub participant that a user has an account with and to other sites supported by the industry hub, by determining the hub participants with whom the user has an account; and if the user has accounts with more than one hub participant displaying a navigator that contains links to only those hub participants with whom the user has an account; and continuing to display the navigator after the user links to a different site within the industry hub. A further aspect of the system includes a method for creating a cross-referenced list of hub participants and users in an industry hub, by receiving a list of active users from each hub participant; for each active user, determining whether the user is already in a list of users, and if so, updating the status of the user to indicate that the user is a multiple-account user. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention that together with the description serve to explain the principles of the invention. In the drawings: Fig. 1 A illustrates a typical situation in any online industry, where customers must independently and separately sign-on to each dealer's website. Fig. IB illustrates the current online financial services market, where users must independently and separately sign-on to each financial services dealer's website. Fig. 2 A illustrates the single sign-on of the system of the present invention. Fig. 2B illustrates an example of commingled information presented by the system of the present invention for the financial services market. Fig. 2C illustrates an example of a resource on a remote server being presented to the user by the system of the present invention for the financial services market example. Fig. 2D illustrates an example of a resource on yet another remote server being presented to the user by the system of the present invention for the financial services market example. Fig. 2E illustrates commingled information displayed for a user having accounts with only two of the three financial services dealers in the financial service market example. Fig. 2F illustrates example comparison information for the participating dealers that is presented to the user in the system of the present invention for the financial services market example. Fig. 3 illustrates a network of trusted servers used in the system of the present invention. Fig. 4 illustrates a process for generating and using CURLs to implement a single sign-on system. Fig. 5 illustrates a preferred structure for a CURL. DETAILED DESCRIPTION Reference will now be made in detail to exemplary embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like components. A key issue for the growth of business-to-business electronic commerce over the Internet is the ability of a customer or other user to easily and conveniently access the websites of competing providers of goods and services within a particular industry. The system of the present invention was developed to give users commingled, seamless access to proprietary information from separate and distinct websites. The ability to gather information from competing providers by an independent third-party into an aggregate view enables a user to make better use of the information. The system of the present invention provides a "hub" solution for a particular industry. The industry hub provided by the present invention allows a user to sign-on once, then have access to information from every participating dealer within the industry with whom the user has an account. Information from the hub participants is presented to the user in an intuitive commingled manner, so that the user can easily compare data. The system of the present invention is typically used in a commercial industry where there are several established dealers within the industry. However, the invention is intended to include any situation where information from several separate and distinct websites is presented to the user through a single sign-on session. When describing the present invention herein, the term "dealer" is intended to include any providers of goods, services or information and/or operators of websites that participate in the system of the present invention. These dealers may also be referred to as "hub participants". The industry hub of the present invention uses a persistent navigator to provide the user with a consistent interface for visiting the various websites of the participating dealers. This persistent navigator allows users to have a common interface at all times, no matter whose website the user is currently accessing. The industry hub of the present invention provides users with better, faster and easier access to products and information within an industry. The industry hub of the present invention provides commingled industry content through an independent entity to ensure that the market leaders participating in the industry hub maintain, and often regain control of their content, brand name, client lists and distribution franchise. The system of the present invention completely integrates the websites of participating dealers. Through one website, a user is able to view the information from all the hub participants through which he has an account. Additionally, through the system of the present invention, the user can seamlessly visit any hub participant's website. The system of the present invention allows users to easily navigate between these proprietary websites and commingle the content, creating an industry hub that increases the impact and value of the websites to all participants of the system, both users and dealers. Fig. 1 A illustrates the current process for a user to obtain product information and/or services from several different online dealers in one industry. Typically, the user is a customer that has accounts with several dealers within the industry. As shown, user 100 must enter and send separate user authentication mformation to each online dealer within the industry. Fig 1 A illustrates the current process for almost any industry that has an Internet presence. Although the system of the present invention can be used in any industry, the system of the present invention is particularly useful for business-to-business electronic commerce. As most business customers have accounts with multiple dealers within their industry, the system of the present invention allows the business customers easier, more convenient access to the dealers. As an example of such a situation where customers deal with multiple dealers on a regular basis, consider the financial services market. In the financial services market, the customers are institutional investors who require a great deal of research data in order to make informed buy and sell decisions. Many of these investors have accounts with many, if not all, of the major financial services dealers in the industry. Although many of the features of the system will be described in terms of the financial services industry, these features can be used in a hub developed for almost any industry, and it will be obvious to one skilled in the art to develop the system of the present invention for a different industry. Fig. IB illustrates the specific example of the current process in the online financial services market. In this example, the customer (user) is an institutional investor. As shown in Fig. IB, user 100 may use the website of a major financial services dealer, such as Goldman Sachs 110, to obtain research and trading information. This same user may also have accounts with and use the websites of Morgan Stanley Dean Witter 120 and Salomon Smith Barney 130. Currently, to compare the information offered by these competing services, the user must separately sign-on to each website and manually compare information. When used in the financial services market, the system of the present invention provides a one-stop site for users to obtain current research reports and updated news. For the financial services market, the system of the present invention provides access to lists of bonds available from the various participating dealers, which makes price comparisons easier. Seamless navigation between participating dealers' sites saves the user valuable time. Consolidated headlines on research and market commentary produced by the participating financial services dealers are also available to users through the system of the present invention. As is obvious to one skilled in the art, different types of information may be consolidated for different industries, and are intended to be covered by the system of the present invention. The commingled information provided by the system of the present invention is supplied by the hub participants. The system of the present invention does not change any of this information; it simply presents the information in a commingled fashion to the user. The system of the present invention treats the hub participants as competitors, while still allowing information to be combined. In addition to the information provided by the hub participants, information provided by the administrator of the industry hub or an independent third-party may also be presented to the user in an commingled manner. The system of the present invention acts as a trusted third party, which allows industry market leaders to commingle their proprietary content and services without compromising their existing distribution channels. The system of the present invention only makes a hub participant's information available to users holding accounts with that hub participant, and not to other users or to other hub participants. Hub participants benefit from increased interaction with their customers while still maintaining control of their data. The customers using the system of the present invention benefit from the seamless navigation and content integration. Industry customers use the system of the present invention to access two or more hub participant's sites. Preferably, users may also automatically be given access to the system of the present invention when they visit a hub participants' website. Hub participants continue to maintain their individual sites, and the system of the present invention aggregates information from each site on its hub. The system of the present invention preserves the proprietary nature of the commingled information. Hub participants cannot see other hub participants' information. This is different from an Infonnation Exchange where everyone sees all of the information. In the system of the present invention, hub participants maintain control over their information. Typically, most online dealers do not use the same methodology to establish username and password account information, and users end up having accounts under several different usernames with separate dealers. Therefore, the system of the present invention must determine whether a user has multiple accounts with dealers that participate in the system, and if so, cross-reference these accounts with that user. To create this list of users cross-referenced with hub participants, each hub participant sends a list of users enabled to use that hub participant's website to the administrator of the industry hub. Typically, this is a list of customers that have active accounts with that hub participant. The information provided in the lists should have a sufficient number of attributes to uniquely identify the user. The administrator of the industry hub compares lists from each hub participant to determine which users have accounts with more than one hub participant. These users are flagged as "multiple- account" users. A multiple-account user is a user that has access to the websites of at least two hub participants. A multiple-account user is a user that is enabled to use the industry hub of the present invention. The process to identify multiple-account users may be manual, automated, or some semi-automated combination. In the process, users are matched based on user information in the lists provided by the hub participants, such as name, email address and mailing address. For every user in each of the lists, the administrator of the industry hub tries to find matching records from lists provided by the other hub participants. If matching records are found, the accounts of these users get "matched", and the user is flagged as a multiple-account user. A preferred process of the present invention for identifying and flagging multiple- account users is shown in Fig. 6. As shown in step 610, a hub participant provides the administrator of the system of the present invention with an enabled user list. For every user in this list, the administrator of the system of the present invention compares the user's information with information maintained in a master user list. First at step 615, the first user record is retrieved. The master user list is searched for a match between this user and a user already in the master user list at step 620. If the user matches a user in the master user list, then the user in the master user list is updated and flagged as a multi- account user at step 630. Preferably, the user's information in the master user list is updated to contain the account information provided by this hub participant for this user in the hub participant's enabled user list. Preferably, the hub participant is notified at step 635 that this user is a multiple-account user and is therefore enabled to user the hub of the present invention. If the user does not match up with any of the users on the master user list, then the user is added to the master user list along with the information provided by this hub participant for this user in the hub participant's enabled user list at step 640. In this case, the user is not flagged as a multi-account user as this is the only account for this user in the master user list. This process is continued for every user in the hub participant's list as indicated by the loop 650-660-620. As is obvious to one skilled in the art, there are other methods of cross- referencing users and accounts, and are within the scope of the present invention. For each multi-account user, the hub participant replaces or updates the user's account with an "account" containing user authentication information valid for all the sites this user has access to through the system of the present invention. The user is then notified that he can now use one username and password to access all sites participating in the industry hub of the present invention. This notification can be through e-mail, or any other method known to those skilled in the art. In addition to the account information, hub participants may provide the industry hub of the present invention with information to be presented to users when they sign- onto the system of the present invention. For example, in the financial services industry, each dealer sends a list of headlines and associated URL links to the industry hub so that it can commingle the headlines for the user. As will be obvious to one skilled in the art, different types of information may be supplied by the hub participants to the system of the present invention for commingling. Using tins information, the system of the present invention allows a user to use a single sign-on to access the websites of all hub participants with whom he has an account, and view commingled information through the system of the present invention. An example of a single sign-on screen presented by the system of the present invention for the financial services market is shown in Fig. 2A. Preferably, after signing onto the system, commingled information for the financial services market is displayed to the user. An example of commingled information for a user who is enabled to use three financial services dealers is shown in Fig. 2B. In the example shown in Fig. 2B, section 210 displays commingled headlines. The users can tell the source of each headline by the abbreviation listed to the left of each headline, as shown in section 211. In this example, the first headline "US Economic Overview" comes from Goldman Sachs (GS); the second headline "US Intra- day Economic Commentary" comes from Salomon Smith Barney (SSB), and the third headline "Global Economic Forum - Update" comes from Morgan Stanley Dean Witter (MSDW). To see the complete article, the user can click on the headline, and the system will link the user to the appropriate dealer's website to view the desired article. For example, if the user clicks on the "US Economic Overview" article from Goldman Sachs, the user is linked to this article at the Goldman Sachs Financial Workbench Website. This is shown in Fig. 2C. The system of the present invention links the user directly to this website; he is not required to enter the specific Goldman Sachs user authentication information. The system of the present invention transmits the user's authentication information to the dealer's secure website as part of the document transaction request. Because this occurs in the background, the user is seamlessly authenticated with the dealer. The screen shown in Fig. 2C contains several sections. Section 220 displays the article that user wants to view. Section 225 contains the toolbar that is regularly shown to all users who access the Goldman Sachs Website. Section 227 contains a Navigator bar that enables the user to link to various websites and "navigate" the system of the present invention. Section 229 in this example contains advertising banners. The navigator bar in section 227 of Fig. 2C is the same as the one in section 220 of Fig. 2B. This navigator bar is persistently displayed as the user moves from site to site. The "Home", "Headlines", "Indications", "Messages" and "Search" links in the Navigator bar allow the user to link to these parts of the system of the present invention. The navigator bar also allows the user to link directly to the websites of any of the participating dealers that the user is enabled to use, as shown by the links "GS", "MSDW" and "SSB". Although Figs. 2B and 2C show the navigator in the form of a particular navigator bar, it should be obvious to one skilled in the art that another form of a navigator, such as a pop-up window or menu bar, could be used. Other navigator methods are known to those skilled in the art and are within the scope of this invention. The user can use the navigator to seamlessly move to the information that he needs, whether it is comparison information offered by the system of the present invention, or specific information from one of the hub participants. Because it is persistent throughout the system of the present invention, the user always knows exactly how to go the information he needs, no matter which site he is currently using. As will be obvious to one skilled in the art, different combinations of these screen display sections can be used. Additional sections can be added if desired. The navigator bar shown in Figs. 2B and 2C is an example for the financial services market. One skilled in the art should be aware that similar navigators could be used for other industries. In the example shown in Fig. 2D, the user has clicked on the "MSDW" hotlink in the navigator bar. The system of the present invention links the user directly to the home page of the Morgan Stanley Dean Witter. Accessing this website normally requires a user to enter his Morgan Stanley Dean Witter user authentication information, but because the user is using the system of the present invention to link to the site, no additional user authentication information is needed. As shown in Fig. 2D, this screen contains the same Navigator bar of the present invention as is shown in Figs. 2B and 2C. As an alternative to signing on directly with the system of the present invention, a user may sign-on to a hub participant's website, and then link to the system of the present invention. In this situation, the user will still only be required to enter user authentication information once - at the first hub participant's website. By linking to the system of the present invention, the user can then seamlessly go to or use the resources on the websites of other hub participants with whom he has an account. The system of the present invention uses a CURL mechanism (described below) to seamlessly link from one webserver to another. The system of the present invention may display commingled information. Examples of the types of commingled information displayed by the system of the present invention for the financial services market are shown in Figs. 2B and 2E. In the example shown in Fig. 2B, the user is enabled to use Goldman Sachs, Morgan Stanley Dean Witter, and Salomon Smith Barney systems. When this user clicks on the "Headline" hotlink in the Navigator bar, headlines from all three dealers are presented. As shown, headlines from all three dealers are commingled together so that the user can see and compare all of them. In Fig. 2E, the user only has accounts with Morgan Stanley Dean Witter (MSDW) and Salomon Smith Barney (SSB). Therefore, the user is only enabled to use MSDW and SSB systems, and only headlines from these dealers are shown to the user. The process is the same, however. The system of the present invention can order the commingled information in any logical order, so that the user can easily compare the commingled information. The user need only click on a headline to seamlessly link to that hub participant's website if he desires more specific information. Again, he is not required to enter hub participant- specific user authentication information to link to that hub participant's website from the commingled information screen. A user only sees information from the hub participants with whom he has an existing relationship. This is an attractive feature of the system of the present invention to hub participants, as there is no client list sharing. The system only works for users that already have multiple accounts with hub participants. If a user only has an account with one hub participant, his access to that hub participant's website does not change. When a single-account user signs on with that hub participant, he is not given access to the system of the present invention. If a single-account user later signs up with another hub participant, he automatically will be given access to the system of the present invention after the second hub participant updates the enabled user list and provides it to the system of the present invention. The system of the present invention then performs the cross-referencing process described earlier. After these processes, the user will be flagged as a multi- account user and given access to the system of the present invention. An additional feature of the system of the present invention allows a user to compare product information. For the financial services market, this feature is accessed through the "Indications" hotlink on the navigator bar. An example of a search screen for product information from participating dealers that is displayed to the user in the financial services market is shown in Fig. 2F. This feature allows a user to easily compare potential investments with different dealers. As one skilled in the art can understand, a similar feature can be developed for other industries that present comparison information for that industry. A number of methods have been used to allow for a single sign-on for different websites; however, none are geared toward diverse, multi-domain websites. The conventional methods do not attempt to integrate the websites of competitors targeting the same customer audience. The system of the present invention creates a "network" within a multiple website enviromnent where users can seamlessly navigate these sites and use their resources without having to re-enter user authentication information for each website. One of the most important features of the system of the present invention is the "single sign-on" ability. Single sign-on allows users to seamlessly navigate diverse sites and use their resources without having to re-enter user authentication information for each website, websites belonging to different companies usually have different domain addresses, and therefore, use of cookies to store user authentication information is ineffective because cookies cannot be shared between websites on different domains. The present invention solves these problems by implementing "CURLs". A CURL is a "cooked URL" that allows websites to utilize a single sign-on for a network of related sites without using cookies. Instead of storing user authentication information in a cookie, the system of the present invention attaches user authentication information to a URL. The system of the present invention uses the CURL mechanism to combine a variety of websites into a single sign-on network of trusted servers, as shown in Fig. 3. Preferably, these servers are capable of running HTTPD server software and support HTTP v 1.0 or higher and/or HTTPS (HTTP over Secure Sockets Layer). Preferably, the Web servers also support dynamic content technologies, such as CGI, Servlet, ASP, etc. Other technologies will be known to those skilled in the art, and are within the scope of the present invention. As shown in Fig. 3, a CURL is a protocol that allows one access-controlled Web server 310 to create hyperlinks to resources available on another access-controlled Web server 320. "Access-controlled" means that the user must authenticate himself to use the resources on the Webserver. The servers may implement access control through username/password authentication, digital certificates, biometric authentication or any other method known to those skilled in the art. Using CURLs, user 300 does not have to re-authenticate himself to use the resources on any of the trusted servers 310, 320, 340, 350 shown in Fig. 3. Preferably, the CURL of the present invention is implemented by issuing a cross-server request 330 that contains user information and requested resource information from a first, local Web server 310 to a second, remote Web server 320 within the network of trusted servers. When the user 300 clicks on a link on a website hosted by a first server to request content from a second server, this request 305 is sent to first Web server 310. The first Web server 310 sends a CURL request 330 to the second Web server 320. Web server 320 returns the requested resource 325 to user 300. Preferably, each Web server in the network of trusted servers implements two CURL interfaces: a CURL "malce" point and a CURL "entry" point. The "make" point is located on the Web server making the request. The "malce" point is responsible for creating a valid CURL and sending it via URL redirection to the CURL "entry" point on a second server that has the requested resource. The "entry" point is located on the second server and is responsible for reading and validating an incoming CURL and serving the requested resource. The "entry" point replaces the website's local authentication mechanism while the "make" point replaces the need for a client to enter user authentication information. The same mechanisms apply to each trusted server. There are no limits on how many sites may participate in the system of the present invention as long as they provide CURL interfaces. Preferably, in order to prevent user identity forgery by generating fake CURLs, at least one portion of the CURL is encrypted. Encrypting a portion of a CURL allows user authentication information to be passed securely from one Web server to another. Preferably, regular symmetric encryption keys are used so that the same key is used for encryption as well as decryption. In an alternative embodiment, public/private keys may also be used to encrypt/decrypt the secret potion of each CURL. Other encryption methods are known to those skilled in the art and are within the scope of this invention. Preferably, different encryption keys are used to encrypt CURLs for each Web server pair. For example, Key #1 may only be used to encrypt CURLs when a user is moving between site A and site B (or from site B to site A), and Key #2 may only be used to encrypt CURLs going from site B to site C, and vice versa. In this manner, any particular key may only be known to two parties. The CURL architecture works through a network, such as the Internet. Preferably, the request, from Make point to Entry point, is a regular HTTP redirection request with a valid URL. In an alternative embodiment, the request may use external secure systems such as SSL. Other technologies will be known to those skilled in the art, and are within the scope of the present invention. The process for a user requesting a resource located on a remote website through the system of the present invention is shown in Fig. 4. The user signs on to a first access- controlled website, and then requests a resource from a second, access-controlled website by clicking on a hyperlink on the first website at step 410. It is transparent to the user that the resource is on a different Web server. However, using the single sign-on of the present invention, he will be able to receive the requested resource, or link to the requested site, without re-entering any user authentication information. The user's request is sent to the CURL make point on the first Web server, and the make point creates a CURL at step 420. The CURL is then sent to the CURL entry point on the second Web server at steps 430 - 440. The entry point on the second Web server reads the CURL, validates it and authenticates the user at step 460. After the user is authenticated, the requested resource is then returned, or the user is redirected to the requested resource using URL redirection at step 470. These steps 420-460 are transparent to the user. The user only sees the request in step 410 and the resource in step 470. Because Web servers cannot communicate directly, CURL requests are sent via URL (HTTP) redirection. The first Web server generates a CURL and uses any acceptable method of URL redirection known to one skilled in the art to send the CURL request to the user's Internet browser at step 430. The browser then automatically acts on the redirection to relay the request to the CURL entry point on the second Web server at step 440. The CURL is validated by the second Web server at step 460, and if validated, the resource is returned to the user at step 470. Preferably, the CURL validation process of step 460 requires time verification. Time verification requires a CURL to contain a timestamp of when it was generated. When the CURL is accepted by the CURL entry point the time contained inside the CURL is compared with the current time on the machine. If the difference is greater than an allowed interval, the CURL is not validated and the user is presented with an appropriate error message, as shown at step 475. A smaller allowable time interval results in more secure protection. For sites that require a high level of security, time synchronization between trusted Web servers becomes crucial, since the CURL validation process depends on accurate timestamps. The time on Web servers performing user authentication through CURLs should be synchronized. Preferably, participating Web servers should have an infrastructure that supports time synchronization with precise time sources, such as the Network Time Protocol (NTP). As shown in Fig. 5, CURLs are simply formatted strings that identify the user's identity and a resource on a separate, remote Web server. This identification is preferably through a user reference such as name, location and user attributes. Alternatively, the user reference4 can be a social security number or any other means of identification. CURLS are preferably formatted as standard HTTP URLs, as defined in the Request for Comment 1738 [4] by the Internet Engineering Task Force (IETF). Preferably, a CURL is composed of a static portion 510, which contains a URL to the CURL entry point, and a dynamic portion 530, which contains user authentication data, a URL of the requested resource, and originator information. The static portion 510 of the URL specifies the CURL entry point on the Web server that contains the requested resource. This portion is static because the CURL entry point on a server is always the same and is known to all trusted servers. Preferably, this static portion of the CURL consists of a protocol 511, host 512, port 513, and local path 514. Protocol 511 preferably supports HTTP or HTTPS. Domain or host 512 identifies the network host for the Web server that has the requested resource. Preferably, domain 512 contains either the fully qualified domain name or the IP address as a set of four decimal digit groups separated by ".". Port 513 identifies the port number to connect to, and is optional. Local path 514 identifies the path to the CURL entry point on the Web server that contains the requested resource. The second, dynamic portion of the CURL is generated by the CURL make point and is attached to the static portion of the CURL. The dynamic portion of the CURL preferably consists of several arguments identifying the user, the requested resource and the originator. As shown in Fig. 5, these arguments are preferably name/value pairs. The arguments shown in Fig. 5 may include a Reference, Path and Originator. Reference 540 is preferably a secret portion that contains arguments in an encrypted form to be used by the CURL processor. The Reference string preferably consists of version information, timestamp, reference arguments, zero padding as needed, and a checksum. Typically, the reference arguments in the Reference portion of the dynamic portion of the CURL contain user information. These reference arguments may also contain user credentials. By default, a reference argument may contain a numeric user id that is shared across all trusted websites. The Reference portion of the CURL is secret, and is preferably encrypted. It may also be URL encoded. Other methods of encoding and encrypting are known to those skilled in the art, and are within the scope of this invention. The specific algorithm used to encrypt the secret portion of the CURL depends on the sensitivity of the data and the security requirements of all the trusted websites. The websites preferably rotate or change their encryption keys on a periodic basis. Originator 533 specifies the site that originated the CURL. This may be used to determine which encryption key to use to decrypt the encrypted portion of the CURL. Path 532 contains the URL of the requested resource. Preferably, the requested resource URL is transmitted as an encoded string. If encoded, the CURL processor decodes the value of the Path in order to properly interpret the request. Many of these fields are not necessary for basic implementation of the CURL mechanism of the system of the present invention. The only required fields that are the user information and the identification of the requested resource. Typically, the length of the entire CURL string is limited to 4k. While the invention has been described in detail and with reference to specific embodiments thereof, it will be apparent to one skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope thereof. It is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims: What is claimed is: 1. A method for a first server to authenticate a user that has been authorized to use the resources on the first server to use resources on at least a second server, comprising the steps of: (a) receiving a request from the user to use resources on a second server; (b) generating a URL string that identifies the user and the requested resource on the second server; and (c) transmitting the URL string to the second server. 2. The method of claim 1, wherein step (c) comprises the additional steps of: (i) returning the URL string to the user's browser; and (ii) using the URL string, having the browser redirect the user to the second server. 3. The method of claim 1 , wherein the URL string that identifies the user in step (b) comprises a user reference. 4. The method of claim 1, wherein the URL string that identifies the user in step (b) comprises user authentication information. 5. The method of claim 4, wherein the authentication information comprises a username and password. 6. The method of claim 1 , wherein at least a part of the URL string is encrypted. 7. The method of claim 1 , wherein the URL string contains a timestamp. 8. The method of claim 7, wherein the timestamp is generated by the first server. 9. A system on a first server for authenticating a user that has been authorized to use the resources on the first server to use resources on at least a second server, comprising: means for receiving a request from the user to use resources on a second server; means for generating a URL string that identifies the user and the requested resource on the second server; and means for transmitting the URL string to the second server. 10. The system of claim 9, wherein said means for transmitting comprises: (i) means for returning the URL string to the user's browser; and (ii) means for having the browser redirect the user to the second server, using the URL string. 11. The system of claim 9, wherein the URL string that identifies the user comprises a user reference. 12. The system of claim 9, wherein the URL string that identifies the user comprises user authentication information. 13. The system of claim 12, wherein the authentication information comprises a username and a password. 14. The system of claim 9, wherein at least a part of the URL string is encrypted. 15. The system of claim 9, wherein the URL string contains a timestamp. 16. The system of claim 15, wherein the timestamp is generated by the first server. 17. A computer readable medium on a first server containing program instructions for: receiving a request from the user to use resources on a second server; generating a URL string that identifies the user and the requested resource on the second server; and transmitting the URL string to the second server. 18. The computer readable medium of claim 12, wherein the program instructions for transmitting the URL string comprise additional program instructions for: (i) returning the URL string to the user's browser; and (ii) having the browser redirect the user to the second server, using the URL string. 19. The computer readable medium of claim 18, wherein the URL string that identifies the user comprises a user reference. 20. The computer readable medium of claim 18, wherein the URL string that identifies the user comprises user authentication information. 21. The computer readable medium of claim 20, wherein the authentication information comprises a username and a password. 22. The computer readable medium of claim 18, wherein at least a part of the URL string is encrypted. 23. The computer readable medium of claim 18, wherein the URL string contains a timestamp. 24. The computer readable medium of claim 23, wherein the timestamp is generated by the first server. 25. A method of authenticating a user to use resources on at least two access- controlled servers located on different domains, comprising the steps of: (a) receiving user authentication mformation from the user by a first server; (b) validating the user authentication information by the first server; (c) receiving a request from the user to use a first resource on a second server, wherein the first request is received by the first server; (d) generating a URL string identifying the first requested resource on the second server, wherein the URL string is generated by the first server; (e) providing the URL string by the first server to the second server; (f) validating the URL string by the second server; and (g) returning the resource requested in step (c) to the user. 26. The method of claim 25, comprising the additional steps of: (h) receiving a request from the user to use a second resource on a third server, wherein the second request is received by the first server; (i) generating a URL string identifying the second requested resource on the third server, wherein the URL string is generated by the first server; (j) providing the URL string by the first server to the third server; (k) validating the URL string by the third server; and (1) returning the resource requested in step (h) to the user. 27. The method of claim 25, wherein step (e) comprises the steps of: (i) providing the URL string to the user's browser by the first server; and (ii) redirecting the URL string to the second server by the user's browser. 28. The method of claim 25, wherein the URL string is encrypted. 29. The method of claim 25, wherein the URL string comprises: (i) user authentication information; (ii) a timestamp; and (in) mformation identifying the first requested resource. 30. The method of claim 28, wherein the validation in step (f) comprises comparing the timestamp to a time on the second server. 31. The method of claim 25, wherein the request received in step (c) is made by a user clicking on a hyperlink on the first server's site. 32. The method of claim 25, wherein step (g) comprises redirecting the user to the first requested resource. 33. A system for authenticating a user to use resources on at least two access- controlled servers located on different domains, comprising: means for receiving user authentication information from the user by a first server; means for validating the user authentication information by the first server; means for the first server to receive a request from the user to use a resource on a second server; means for the first server to generate a URL string that identifies the requested resource on the second server; means for the first server to provide the URL string to the second server; means for the second server to validate the URL string; and means for returning the requested resource to the user. 34. The system of claim 33, additionally comprising: means for receiving a request from the user to a second resource on a third server, wherein the second request is received by the first server; means for generating a URL string identifying the second requested resource on the third server, wherein the URL string is generated by the first server; means for providing the URL string by the first server to the third server; means for validating the URL string by the third server; and means for returning the requested resource to the user. 35. The system of claim 33, wherein the means for providing the URL string comprises: means for providing the URL string to the user's browser by the first server; and means for redirecting the URL string to the second server by the user's browser. 36. The system of claim 33, wherein the URL string is encrypted. 37. The system of claim 33, wherein the URL string comprises: (i) user authentication information; (ii) a timestamp; and (iii) information identifying the first requested resource. 38. The system of claim 37, wherein the means for validating the URL string comprises additional means for comparing the timestamp to a time on the second server. 39. The system of claim 33, wherein the means for receiving the request comprises the user clicking on a hyperlink on the first server's site. 40. The system of claim 33, wherein the means for returning the requested resource comprises means for redirecting the user to the first requested resource. 41. A system for authenticating a user to use resources on at least two access- controlled servers, said computer system comprising a memory area for storing a string that is used by the system to authenticate the user requesting resources with a server that has the requested resources, said memory area comprising information that identifies the user and the requested resource. 42. The system of claim 41, wherein the string stored in said memory area is in URL format. 43. The system of claim 41 , wherein said memory area comprises : (a) a first field that identifies the user; and (b) a second field that identifies the requested resource. 44. The system of claim 43, wherein the first field is encrypted. 45. The system of claim 43, wherein said memory area additionally comprises: a third field that identifies the server that has the requested resource. 46. The system of claim 45, wherein the third field comprises: (i) a protocol; (ii) a host; and (iii) a local path to the server that has the request resource. 47. The system of claim 46, wherein the third field additionally comprises port identification information. 48. The system of claim 46, wherein the protocol is HTTP. 49. The system of claim 46, wherein the host is a fully qualified domain name. 50. The system of claim 46, wherein the host is an IP address. 51. The system of claim 43, wherein said memory area additionally comprises: a fourth field that identifies the originating server. 52. The system of claim 51, wherein the fourth field is used to determine an encryption key for decrypting an encrypted portion of said memory area. 53. The system of claim 43, wherein the first field additionally comprises version information and a timestamp. 54. A website for an industry hub that provides an authenticated user with commingled information from at least two hub participants located on separate access-controlled servers, wherein the commingled information displayed to the authenticated user displays only information from hub participants with whom the user has an account, said website including software for commingling information by: (a) receiving information from each hub participant that is to be displayed to users having an account with that hub participant; (b) for each user, determining hub participants with whom that user has an account; (c) for each user, commingling the information received in step (a) for the hub participants determined in step (b) into a single presentation of information; and (d) displaying the commingled information from step (c) to the user. 55. The website of claim 54, wherein the commingled information is displayed to the user by category. 56. The website of claim 54, wherein the information displayed to the authenticated user identifies the hub participant that provided the information. 57. The website of claim 54, wherein the commingled information displayed to the authenticated user includes a hyperlink for each piece of information for allowing the authenticated user to link to a website of the hub participant that provided the information. 58. The website of claim 54, comprising the additional step of: (e) displaying supplementary information to the user in addition to the information displayed in step (d). 59. The website of claim 58, wherein the supplementary information displayed in step (e) is provided by the industry hub website. 60. hi an industry hub, a method for a user having accounts with a plurality of hub participants to use resources provided by each hub participant with whom the user has an account in a single system, wherein the resources offered by the hub participants to the user are located on separate access-controlled servers, and authentication information of the user is different for every server, comprising the steps of: (a) entering first user authentication information at a first server; (b) requesting a first resource from a second server; and (c) receiving the first requested resource without entering additional user authentication information. 61. The method of claim 60, wherein step (b) comprises the additional step of clicking on a hyperlink to request a first resource from a second server. 62. The method of claim 59, wherein the user is redirected to the first requested resource in step (c). 63. The method of claim 59, comprising the additional steps of: (d) requesting a second requested resource from a third server; and (e) receiving the second requested resource without entering additional user authentication information. 64. An industry hub system for a user having accounts with a plurality of hub participants to use resources provided by each hub participant with whom the user has an account in a single system, wherein the resources offered by the hub participants to the user are located on separate access-controlled servers, and authentication information of the user is different for every server, comprising: means for entering first user authentication information at a first server; means for requesting a first resource from a second server; and means for receiving the first requested resource without entering additional user authentication information. 65. The system of claim 64, wherein the means for requesting a first resource comprises clicking on a hyperlink to request a first resource from a second server. 66. The system of claim 64, wherein the means for receiving a first requested resource comprises redirecting the user to the first requested resource. 67. The system of claim 64, additionally comprising: means for requesting a second requested resource from a third server; and means for receiving the second requested resource without entering additional user authentication information. 68. A method for providing a hub navigator to a user of an industry hub system, wherein said hub navigator provides the user with links to hub participants' sites and to other sites supported by the industry hub, comprising the steps of: (a) determining the hub participants with whom the user has an account; (b) if the user has accounts with more than one hub participant, displaying a hub navigator that contains links to only those hub participants with whom the user has an account; and (c) continuing to display the hub navigator after the user links to a different site within the industry hub. 69. The method of claim 68, wherein the hub navigator is a navigator bar. 70. An industry hub system that provides a hub navigator to a user of the industry hub system, wherein said hub navigator provides the user with links to hub participants' sites and to other sites supported by the industry hub system, comprising: means for determining the hub participants with whom the user has an account; if the user has accounts with more than one hub participant, means for displaying a hub navigator that contains links to only those hub participants with whom the user has an account; and means for continuing to display the hub navigator after the user links to a different site within the industry hub. 71. The industry hub system of claim 70, wherein the hub navigator is a navigator bar. 72. A computer readable medium for providing a hub navigator to a user of an industry hub system, wherein said hub navigator provides the user with links to hub participants' sites and to other sites supported by the industry hub, containing program instructions for: determining the hub participants with whom the user has an account; if the user has accounts with more than one dealer, displaying a hub navigator that contains links to only those hub participants with whom the user has an account; and continuing to display the hub navigator after the user links to a different site within the industry hub . 73. The computer readable medium of claim 72 wherein the hub navigator is a navigator bar. 74. A method for creating a cross-referencing hub participants and hub users in an industry hub through a master list that contains a record for every hub user, comprising the steps of: (a) receiving a list of user records from each hub participant; (b) for each user record, determining whether the user in the user record has a record in the master list; (c) if the user has a record in the master list, updating the user's record in the master list to indicate that the user is a multiple-account user, (d) if the user does not have a record in the master list, adding a record for that user to the master list. 75. The method of claim 74, wherein the list of user records received in step (a) contains user identification information. 76. The method of claim 75, wherein step (b) comprises comparing the user identification information in the user record received in step (a) with user identification information contained in the master list for a match. 77. The method of claim 75, wherein the user identification information received in step (a) comprises the user's name, email address and physical address. 78. The method of claim 74, wherein step (c) additionally comprises notifying the hub participant that the user is a multiple-account user. 79. The method of claim 78, wherein step (c) additionally comprises notifying the hub participant via email that the user is a multiple-account user. 80. A computer readable medium containing program instructions for cross- referencing hub participants and hub users in an industry hub through a master list that contains a record for every hub user, comprising computer program instructions for: (a) receiving a list of user records from each hub participant; (b) for each user record, determining whether the user in the user record has a record in the master list; (c) if the user has a record in the master list, updating the user's record in the master list to indicate that the user is a multiple-account user; (d) if the user does not have a record in the master list, adding a record for that user. 81. The computer program product of claim 80, wherein the list of user records received in the computer program instructions for step (a) contains user identification information. 82. The computer program product of claim 81 , wherein computer program instructions in step (b) comprises computer program instructions for comparing the user identification information in the user record received in step (a) with user identification information contained in the master list for a match. 83. The computer program product of claim 81, wherein the user identification information received in the computer program instructions in step (a) comprises the user's name, email address and physical address. 84. The computer program product of claim 80, wherein computer program instructions in step (c) additionally comprise computer program instructions for notifying the hub participant that the user is a multiple-account user. 85. The computer program product of claim 84, wherein the computer program instructions in step (c) additionally comprises notifying the hub participant via email that the user is a multiple-account user.

Inventors: LEFLER STEVEN, REIFMAN GARY, SCHLINKERT LEO R, SHINKAR SERGE, LEFLER, STEVEN, REIFMAN, GARY, SCHLINKERT, LEO, R., SHINKAR, SERGE
Applicants: COMMUNICATOR INC, COMMUNICATOR, INC.
Application year: 2001
Main classification: G06F15
IPC codes: G06F13, G06F21, H04L9, H04L29