Information delivery system and method including restriction processing

Abstract

The electronic distribution of research documents over the world wide web or other network to investors. A repository server receives research documents from contributors. A restriction subsystem server is selectively coupled to the contributor workstation. The restriction subsystem server which includes manages and stores "restriction" and "review" information of companies, relative to contributors. A contributor identifies (via electronic communication or otherwise) to the restriction subsystem server a "restriction" and/or "review" status of a company relative to the contributor. A particular company may be identified as "RESTRICTED" if the contributor has a current banking or financial interest in the company. Additionally, a company may be identified as "UNDER REVIEW" if the contributor believes its opinion about the company may change based on a news event. Moreover, a company may be identified as "UNDER EXTENDED REVIEW," if, for example, the contributor is not presently "covering" that company. Each time the repository server is queried for a list of reports or documents (i.e., document titles or headlines), the repository server determines whether to provide a particular title to the viewer workstation (via a viewer server or web server) to the user based on the restriction status of the contributor of the document relative to the restriction status of the company or companies associated with the document.

Claims

What is claimed is:

1. A method for providing a list of identifiers corresponding to a plurality of electronic documents, the documents being stored in a central repository, each of the documents being associated with a corresponding contributor, a corresponding company, and a corresponding identifier, the method comprising the steps of:

electronically receiving from a remote computer a request for a list of identifiers;

selecting a subset of the documents in accordance with the request;

for each of the documents in the subset,

i) comparing the corresponding contributor and the corresponding company with stored data, the stored data identifying a stored contributor, a stored company, and an identified relationship between the stored contributor and stored company;

ii) if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, determining whether to exclude the corresponding identifier from the list of identifiers as a function of the identified relationship; and

transmitting the list of identifiers to the remote computer.

2. The method of claim 1 further comprising the step of:

if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, and the identified relationship identifies the stored company is "restricted" relative to the stored contributor, excluding the corresponding identifier from the list of identifiers.

3. The method of claim 1 further comprising the step of:

if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, and the identified relationship identifies the stored company is "restricted" relative to the stored contributor, and the remote terminal is associated with an "external" client of the corresponding contributor, excluding the corresponding identifier from the list of identifiers.

4. The method of claim 1 further comprising the step of:

if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, and the identified relationship identifies the stored company is "restricted" relative to the stored contributor, and the remote terminal is associated with an "internal" client of the corresponding contributor, including the corresponding identifier from the list of identifiers.

5. The method of claim 1 further comprising the steps of:

if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, determining whether to transmit to the remote terminal access data indicating that the corresponding document is inaccessible by the remote terminal as a function of the identified relationship.

6. The method of claim 5 wherein the determining step further comprising the step of:

if the identified relationship identifies that the stored company is not "restricted" and is "under review" relative to the stored contributor, and the remote terminal is associated with an "external" client of the corresponding contributor, transmitting the access data to the remote terminal.

7. A method for providing a list of document headlines corresponding to a plurality of electronic documents, the documents being stored in a central repository, each of the documents being associated with a corresponding contributor, a corresponding company, and a corresponding document headline, the method comprising the steps of:

electronically receiving from a remote computer a request for a list of document headlines;

selecting a subset of the documents in accordance with the request;

for each of the documents in the subset,

i) comparing the corresponding contributor and the corresponding company with stored data, the stored data identifying a stored contributor, a stored company, and an identified relationship between the stored contributor and stored company;

ii) if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, determining whether to exclude the corresponding document headline from the list of document headlines as a function of the identified relationship; and

transmitting the list of document headlines to the remote computer.

8. The method of claim 7 further comprising the step of:

if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, and the identified relationship identifies the stored company is "restricted" relative to the stored contributor, excluding the corresponding document headline from the list of headlines.

9. A system for providing a list of document headlines corresponding to a plurality of electronic documents, the documents being stored in a central repository, each of the documents being associated with a corresponding contributor, a corresponding company, and a corresponding document headline, the system comprising:

a server selectively coupled to a remote computer; and

a memory device coupled to the server, the memory device storing a contributor identifier associated with a contributor and a company identifier associated with a company, the database further, the database further storing relationship information identifying a relationship between the contributor and the company;

wherein the server receives from the remote computer a request for a list of document headlines and selects documents in accordance with the request, and for each of the documents in the subset, the server

i) compares the corresponding contributor and the corresponding company with stored data, the stored data identifying a stored contributor, a stored company, and an identified relationship between the stored contributor and stored company;

ii) if the corresponding contributor matches the stored contributor, and the corresponding company matches the stored company, the server determines whether to exclude the corresponding document headline from the list of document headlines as a function of the identified relationship,

and wherein the server transmits the list of document headlines to the remote computer.

Description

FIELD OF THE INVENTION

The present invention is directed to a computer-based system and method for the electronic distribution of information, and more particularly, for the distribution of information via the Internet to authorized recipients.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND INFORMATION

Financial research providers such as brokerage and investment banking firms spend large sums of money creating, printing and distributing thousands of graphic-rich research reports to investors (e.g., customer's, remote sales offices, investment advisors, brokers, portfolio managers, etc.). Research providers seeking to reduce costs may consider distributing these reports electronically, from computer to computer. Electronic distribution is generally cost effective when compared with hard copy distribution methods. Global computer networks, such as the Internet, enable information to be distributed to a wide range of people at locations around the world. One of the many advantages of the Internet, particularly the World Wide Web ("WWW"), is that the communication protocols used are non-proprietary, thus enabling end users to access and use the Internet without the need for customized hardware or software.

Often, research providers wish to provide information to investors or users on a controlled basis. In particular, research providers may wish to provide reports only to particular people, while ensuring that other people (such as, for example, competitors) are not provided with such reports.

Additionally, research providers may wish to control access to reports due to laws or regulations under which the research providers must operate. For example, a research provider may wish to prevent particular users from accessing particular documents in order to comply with certain SEC regulations. When a research provider has a current banking or financial interest in a public company that is the topic of a research report (i.e., a "restricted company"), the research provider may be required by law to restrict its private internal clients from accessing the report. More specifically, SEC laws restrict research providers from influencing the research providers' private clients in any way with regard to a restricted company.

Accordingly, there is a need for a procedure that allows a research provider to restrict research related to restricted companies from being accessed by private clients and investors.

Additionally, when an external event occurs, i.e., a "news" event, a research provider may believe its "opinion" (as reflected in a report, for example) about a particular public company, may change. Accordingly, the research provider may wish to indicate to its investors that the company is "under review." That is, some news event has occurred that is believed to materially affect a public company's financial performance, and therefore the research provider's opinion. For example, assume that a research provider issues a report regarding a particular public company, and that company relies on the availability of a natural resource from a foreign country. If a war breaks out in that supplier company, and thus the public company can no longer acquire that natural resource from the supplier country (due to an embargo, for example), the research provider's opinion regarding the public company may change. Accordingly, there is a need for a procedure that provides a research provider with the ability to indicate to its clients and investors that a particular company is under review.

Also, when a research provider has "no opinion" about a particular public company on which the research provider previously issued an opinion (in the form of a research report, for example), the research provider may wish to indicate to its clients and users that the particular company is under "extended review." This would indicate that previous research reports (and therefore opinions) related to the public company are no longer valid, i.e., the research provider is not "covering" the public company for events that might impact previously rendered opinions.

Accordingly, there is a need for a procedure that allows a research provider to filter or restrict earlier-rendered opinions and reports, or somehow indicate to clients and investors that a company is under "extended review."

SUMMARY OF THE INVENTION

The present invention provides an method and system for controlling the distribution of electronic information based on, in part, an identified relationship between the electronic information provider, e.g., a research provider, and the company or companies that are the subject matter of the electronic information. In a representative embodiment of the present invention, a central repository server is coupled to one or more remote contributor workstations. The information that is stored at the repository server is received from the contributor workstations in electronic form.

According to the representative embodiment of the present invention, the information received from the contributor workstations are files comprising one or more documents. These documents typically would contain text, data, charts, graphs, spreadsheets and the like, or combinations thereof, and may be in many formats. It will be appreciated that any information that can be stored in digital form, such as photographs, videos, sound recordings, etc. may be stored in the files received from the contributor workstations. Files received from the contributor workstations are converted at a central site into predetermined format, e.g., for printable documents, a common viewing format such as, for example, PDF format, and thereafter provided to the repository server. Each document submitted to the repository server is accompanied by a document profile comprising information organized according to predefined fields relating to the document. Information in a document profile may include, for example, a list of ticker symbols of the companies that are related to the subject matter of the document.

In the exemplary embodiment, a restriction subsystem server is selectively coupled to the contributor workstation. The restriction subsystem server, which includes, for example, a restriction database, manages and stores "restriction" and "review" information of companies, relative to contributors. In the exemplary embodiment of the present invention, a contributor identifies (via electronic communication or otherwise) to the restriction subsystem server a "restriction" and/or "review" status of a company relative to the contributor. For example, a particular company may be identified as "RESTRICTED" if the contributor has a current banking or financial interest in the company. Additionally, a company may be identified as "UNDER REVIEW" if the contributor believes its opinion about the company may change based on a news event. Moreover, a company may be identified as "UNDER EXTENDED REVIEW," if, for example, the contributor is not presently "covering" that company.

According to the representative embodiment of the present invention, each user has a user computer, such as, for example, a personal computer with an Intel Pentium processor and a fast modem that the user can use to connect to the Internet. The user computer has one or more local storage devices. In the representative embodiment, the user computer executes Netscape's Navigator browser program. However, other browser programs, such the Mosaic browser or Microsoft's Internet Explorer browser could also be used. As used herein, the browser programs executed by the user computer will be termed "Internet browsers." When the user initially accesses the web server, the user is required to provide a user identification code ("ID") and a password. The web server submits a login request to the CGI program to verify that no other user is using the same ID. According to the present invention, a user is permitted to access the web server from a different user computer or using a different Internet browser; however, the present invention prevents the user (or other users) from "concurrently" accessing the web server from more than one computer or Internet browser using the same ID.

Once the user has provided the ID and password, the repository server will determine what information that user is authorized to receive. According to the present invention, each user has authorization to access all or a subset of the information stored at the repository server.

In the representative embodiment, the repository server can provide the user with a list of new documents that have been recently received by the repository server and which that user is authorized to access. The user may also request a list of documents that fit certain user-specified search criteria. A list of the documents that match that search criteria and which the user is authorized to access is provided to the user computer. The user can then select, request and view documents from these lists.

In the representative embodiment, the repository server also includes a procedure for controlling the ability for a user to display and access a document based on, in part, the "restriction" and/or "review" status (relative to the document contributor) of the company (companies) that is (are) the subject of the document. In the exemplary embodiment, the repository server stores a copy of the restriction database in high speed memory such as, for example, RAM or SRAM. Each time the repository server is queried for a list of reports or documents (i.e., document titles or headlines), the repository server determines whether to provide a particular title to the viewer workstation (via a viewer server or web server) to the user based on the information in the "in memory" restriction database.

In response to a request for a list of documents, the repository server retrieves a list of titles of documents to which the user is "entitled". Additionally, the repository server retrieves any ticker symbols corresponding to the subject matter of each of these documents (such as, for example, those ticker symbols that are provided in each document's corresponding document profile). Each retrieved document title (and corresponding list ticker symbols) is then processed.

The repository server "aggregates" the restriction information for all of the ticker symbols associated with first document. That is, since a document may have a number of ticker symbols associated therewith, the repository system combines the restriction information in order to form aggregate restriction information.

Next, the aggregate restriction information for the title is processed in order to determine whether or not the title should be provided to the user. If the user is an "Internal Private Client" (e.g., an employee of the contributor), the following rules are applied:

If any ticker symbol associated with the document is under restriction and the release date and time of the document is prior to the restriction date and time, the title may be displayed to the user but the title is marked as "restricted." That is, the user can display the title of the document but cannot access the corresponding document.

If any ticker symbol associated with the document is under review or extended review and the release date and time of the document is prior to the review date and time, the title may be displayed to the user, and the title is marked as "under review" or "under extended review." The user may access the corresponding document.

Otherwise, the title may be displayed and the document corresponding to that title may be accessed.

If, instead, the user is an "External Private Client" (e.g., an investor-client of the contributor), the following rules apply:

if a ticker symbol associated with the document is under restriction and the release date and time of the document is prior to the restriction date and time, the title may not be displayed by the user and the user cannot access the corresponding document;

if a ticker symbol associated with the document is not under restriction, but the a ticker symbol associated with the document is either under review or under extended review AND the document release date is prior to the review date and time, the title may not be displayed by the user and the document associated with that title cannot be accessed by that user;

otherwise, the title may be displayed and the document corresponding to that title may be accessed.

This process is repeated for all titles in the list.

The present invention is ideally suited for providing investment research reports to investors and investor advisors. Brokerage and investment banking firms create mounds of investment research reports on a daily basis concerning thousands of companies and industries. These reports are provided to investors in electronic form. At present, these reports are distributed either by messenger or by mail, or over proprietary networks, requiring the installation and maintenence of expensive hardware, software and communication lines. Because of this expense, the number of users who have access to these proprietary networks is limited. In the representative embodiment, the present invention enables investment research reports to be securely distributed to investors over the Internet. The present invention overcomes the disadvantages of a proprietary network and enables investment research reports to be distributed to a wider range of investors who are authorized to receive such reports.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of the overall system architecture of the present invention.

FIG. 2 is an example bulletin board screen display.

FIG. 3 is an example document query form screen display.

FIG. 4 is an example query results screen display.

FIG. 5 is a system architecture diagram of an enhanced system according to the present invention.

FIG. 6 illustrates one embodiment of an on-line entitlement/report subsystem.

FIG. 7 is an example initial menu of the entitlement/report subsystem.

FIG. 8 is an example of a subscriber selection criteria page (for entitlement status viewing/modification).

FIG. 9 is an example of an entitlement status viewing/modification page.

FIG. 10 is an example of an entitlement report parameter specification page.

FIG. 11 illustrates the overall system architecture of an exemplary restriction subsystem.

FIG. 12 is an example of an initial menu presented to a contributor accessing the exemplary restriction subsystem.

FIG. 13 is an example of a selection/modification displaying or modifying information in the restriction database of the restriction subsystem.

FIG. 14 is a flowchart illustrating an exemplary procedure for displaying, at a contributor workstation, the status of a particular company (relative to the contributor).

FIG. 15 is s flowchart of an exemplary procedure for modifying restriction/review information in the restriction database.

FIG. 16 is illustration of an illustrative restriction status report page.

FIG. 17 is a flowchart of a process for processing a list of titles in accordance with the exemplary embodiment of the present invention

DETAILED DESCRIPTION

For ease of description, the embodiment of the present invention described herein is that used for the electronic distribution of investment research reports and morning meeting notes ("reports") to investors via the Internet's World Wide Web ("WWW"). However, the invention is not so limited, and can be used, where appropriate, for the electronic distribution of other types of information via other types of networks.

As used herein, the terms "investor" and "user" include any end user who is permitted to receive or access information via the present invention, such as, for example, customers of brokerage and investment banking firms, employees of brokerage and investment banking firms, investment advisors, brokers, bankers, portfolio and fund managers, journalists, analysts, economists, university professors, MBA students, etc.

Referring now to the drawings, and initially FIG. 1, there is illustrated an overall system architecture according to the present invention. A central repository server 2 is coupled, via a central site 1, to one or more remote contributor workstations 14, 16, 18, 19. The contributor workstations 14, 16, 18, 19 are used by brokerage and investment banking firms to submit reports to the repository server 2. Optionally, the contributor workstations 14, 16, 18, 19 may be coupled to the repository server 2 via a proprietary network comprising a plurality of contributor servers 20, 22. Alternatively or additionally, a contributor workstation 24 may provide reports to the repository server 2 via the Internet.

In the representative embodiment, the contributor workstations execute a program called Multex Contributor.TM., described in detail in the user manual titled "MX Contributor--User Guide" available from Multex Systems, Inc. of New York, N.Y. and expressly incorporated herein by reference. The Multex Contributor.TM. program is a real-time Windows-based document indexing and transfer program used to disseminate reports to the central site 1. The contributor simply completes a form (a document profile) displayed on the screen of the contributor workstation 14, 16, 18, 19, and, at the specified time, the Multex Contributor.TM. program transfers the report, along with the information in the completed form, to the central site 1.

At the contributor workstation 14, 16, 18, 19, the contributor completes a form relating to the report. First, the contributor selects a report for distribution. The report is stored, usually as a file, in electronic form on the contributor workstation 14, 16, 18, 19 or on a server or network drive coupled to the contributor workstation 14, 16, 18, 19. The report may be in any standard electronic format, for example, Pagemaker, Microsoft Word for Windows, Corel WordPerfect, etc. The form has fields relating to the report, for example, title, author, subject, date and time of creation, distribution level (setting distribution to a default group of investors or one of a set of predefined groups of investors) and expiration time. Optionally, the contributor can enter additional information in the form, such as, for example, ticker symbol(s), industry group, synopsis, country, region, currency, etc. Once the report has been selected and the form completed, the user issues a "contribute" command to the Multex Contributor.TM. program and the report and all the information in the form is electronically transmitted to the contributor server 20, 22 or directly from central site 1. In the representative embodiment, the reports are "pushed up" from the contributor servers 20, 22 to the central site 1.

In an alternative embodiment, an "auto-contributor" program may be used to automatically contribute reports. The auto-contributor program executes, for example, on a contributor workstation 14, 16, 18, 19 and provides a mechanism for automatically contributing one or a number of documents. This mechanism is particularly well suited for "high volume" contributors.

In an exemplary embodiment, the auto-contributor reads a file (or a number of files), stored at, for example, the contributor workstation 14, 16, 18, 19 or at a contributor server 20, 22) which provide information related to each report to be automatically contributed. The information may include the same information that a contributor would enter into the form described above, e.g., title, author, subject, date, and time of creation, distribution level, expiration time, ticker symbols, etc. Additionally, the information includes the location or address of the file containing the report (or reports), e.g., file path. After reading the file (or files), the auto-contributor program transmits the file (or files), and the corresponding report files to the central site 1.

At the central site 1, the reports are processed. Typically, the central site comprises a network of computer processors. At the central site 1, each report is converted to a predetermined format. In the representative embodiment, all reports received at the central site 1 are converted at the central site 1 into a format that can be read by the Acrobat Exchange program, available from Adobe Systems. The reports are then provided by the central site 1 to the repository server 2.

Where desired, the repository server 2 can also receive, store and enable the distribution of other useful information, such as, for example, news reports received from wire services, government reports, product reviews, etc.

The repository server 2 comprises or is coupled to at least two database servers 11, 13. Each database server is coupled to a database storage device 10, 12. A relational database 10, 11 allows field searching. In the representative embodiment, the relational database 10, 11 is an SQL database server 11 coupled to a storage device 10. A full text database 12, 13 allows word or text searching. In the representative embodiment, the full text database 12, 13 is a full text search database server 13 (for example, a full text search engine available from Fulcrum of Ottawa, Canada) coupled to a storage device 12.

The information contained in the form is indexed in the relational database 11 to allow retrieval of the report by searching on such fields, e.g., searches by author, date, industry, etc. Where necessary, information in the form received from the contributor is mapped into "common" terminology as used by the relational database 11. For example, the terms "sports utilities" and "minivans" may be mapped and stored as the term "automobile." ASCII text is extracted from the report and stored in the full text database 12, 13 for full text searching.

The repository server 2 provides investors with lists of reports received from the contributor workstations 14, 16, 18, 19 and allows investors to request lists of reports that fit certain criteria. The investor can select reports from these lists to down-load, view and/or print. Generally, lists of reports can be generated by the web server 4.

The contributor of a report can be notified that a particular investor has accessed that report. The repository server 2 maintains for each report a list of those who accessed that report. The repository server 2 can transmit that list to the report's contributor on a regular basis and/or when requested by the contributor.

The repository server 2 is coupled to a web server 4 which in turn is coupled to the Internet via, for example, a T1 or ISDN connection. The web server 4 is a high powered server computer that runs a web server program. In the representative embodiment, the web server 4 executes, for example, Netscape's Commerce Server program. The web server program allows web pages (in HTML format) to be accessed by investors. The web server 4 also executes other programs and subroutines as required.

Each investor has a user computer 6, 8, such as, for example, a personal computer with an Intel Pentium processor and a fast modem. The user computer 6, 8 can connect with the Internet via, for example, a commercial Internet Service Provider. In the representative embodiment, the user computer 6, 8 executes an Internet browser program, such as, for example, Netscape's Navigator browser program. The Internet browser can read HTML format, and can also communicate with other programs. This communication is via a program extension called a plug-in. In the representative embodiment, the plug-in is the Acrobat Exchange Interface program, available from Adobe Systems that directs Acrobat Exchange or Acrobat Reader to load and display downloaded ".pdf" files.

The web server 4 includes a web server helper application, which in the representative embodiment is the CGI (common gateway interface) program, that is activated by investors through web pages provided by the web server 4. CGI provides a method for web pages to interact with programs on the web server. CGI lets those other programs process HTML forms and other data coming from Internet browsers, and then lets the other programs send a response back the web server 4 to be delivered to the Internet browser. The response can be HTML files, GIF files, PDF files or any data that the Internet browser can view. Thus, generally, when an Internet browser requests a document from the web server 4, the web server 4 server program finds the document and sends it to the Internet browser. However, if the Internet browser requests a CGI program, the web server 4 server program acts as a middleman between the Internet browser and the CGI program. Other web server helper applications (or interfaces), such as, for example, BGI, NSAPI, ISAPI, or ASP (Active Server Pages) can be used in place of CGI within the principles of the present invention. These applications are extensions to the web server 4.

Access to the web server 4 begins from an investor's Internet browser. Initially, the investor can access "public" web pages generally describing some of the features of the document delivery service of the present invention. If the investor chooses to proceed, the investor selects the "log-in" option from the initial web page.

User Verification

The first step the web server 4 takes in handling an investor request is verifying that the investor is permitted to access the information stored at the repository server 2. This is accomplished using the standard verification procedure built into the communication protocol between Internet browsers and web servers.

The web server 4 uses Netscape's Commerce Server's ability to call custom verification subroutines when a user tries to access CGI's and web pages. The web server 4 executes a subroutine and, using Netscape's NSAPI, receives the ID and password that the investor is asked to provide by the server/browser, and then verifies the ID and password against a database of authorized users (the user database) maintained at the repository server 2. If the user is verified, the Internet browser will be given a verification signature. An investor who is not in the user database, or enters an incorrect password, is denied access to CGI's and web pages on the web server 4 by simply having the subroutine return an "Access Denied" flag to the web server 4. This subroutine maintains an open connection to the user database to improve performance.

Whenever an investor makes a query for a list of reports, the investor's Internet browser sends an HTTP (hypertext transfer protocol) request that represents what the user wants to the web server 4. If the request does not have a verification signature attached to it, the web server 4 sends a command back to the Internet browser, causing it to prompt the user for an ID and password. The Internet browser will then return this information to the web server 4, which will verify that the user is entitled to access the reports stored at the repository server 2. If the user is verified, the Internet browser will be given a verification signature. If not, the user will be prompted again for his ID and password. Once access is verified, the web server 4 will start the CGI program named in the original HTTP request, along with any run-time parameters that are specified in the request. The CGI program first verifies that the user making the request (whose ID is passed to the CGI program by the web server 4 through, for example, an environment variable) is the only one using that ID at that moment. This is done by the following method:

a. The CGI program gets the value of the Internet browser "cookie", and extracts the value for the named pair "mxauth" from the cookie.

b. If the value is empty, the CGI program indicates that this user is accessing the web server 4 for the first time since starting his or her Internet browser. This user then becomes the designated "current user of this ID". A new random value for the "mxauth" part of the browser cookie is generated, stored on the web server 4 under this user's ID, and sent back to the Internet browser, so that the Internet browser can send it back next time.

c. If the value is not empty, the CGI program indicates that this user has previously already accessed the web server 4 since starting the browser program, and has been given an authorizing cookie. If the "mxauth" value of the cookie does not match the value stored on the web server for this user, then this user has been superseded by another user using the same ID. The CGI does not perform the requested task, and tells the user that access is denied. If the "mxauth" value of the cookie does match, then this user is authorized to continue, and the CGI performs the requested task. Each time the user is authorized to continue, the time of the access is stored on the web server 4.

d. A stored cookie value that is over an hour old is considered "stale". A user whose code does not match a stale cookie is allowed access as if the user was initially signing on, as per b. above.

Part of the rationale for this method comes from the lack of a "sign-off" from a user. When a user "leaves" the web server 4 to browse other parts of the WWW, or closes down his or her Internet browser, the web server 4 is not informed.

(For reference, it is noted that cookies are a general mechanism which server side connections, such as CGI scripts, can use to both store and retrieve information on a client side of an Internet connection. A web server, when returning an HTTP object to an Internet browser, may also send a piece of state information which the Internet browser will store. Included in the state object is a description of the range of URLs for which that state is valid. Future HTTP requests made by the Internet browser which fall within that range will include a transmittal of the current value of the state object from the Internet browser to the web server. For no compelling reason, the state object is known in the art as a "cookie.")

Other systems that allow only one instance of an ID to be active at one time rely on a "sign-off" notification to tell when the ID can be used again for "sign-on". Because the web server 4 does not receive a "sign-off", it is assumed that any new user is allowed to "sign-on" with that ID, but all others that are currently using that ID will now be denied further access, until they "sign-on" again (which involves closing down the browser, then restarting it again). Furthermore, step d. is included to keep a user from locking himself out of his own ID if he happens to use browsers from two different locations, such as home and office.

Thus, the following scenarios apply:

Scenario 1:

User 1 signs on to the web server 4 at his office. The CGI marks this browser/user ID combination as the current user.

At 5:00 PM, he goes home, without closing down his browser.

At 5:45 PM he signs on from his home computer. The CGI now marks this browser/user ID as the current user.

At 10:00 PM, he goes to bed, without turning off his browser.

At 8:00 AM the next day, he arrives at work, and tries to access the web server 4 again. Because his 10:00 PM cookie is now "stale", the CGI marks the office browser/user ID as the current user.

Scenario 2:

User 1 signs on to the web server 4 at her office. The CGI marks this browser/user ID combination as the current user.

She then goes to the desk of User 2, and shows User 2 "this new web service", using her own user ID and password to sign on to the web server 4. The CGI marks User 2's browser as the current user of User 1's ID.

After a few minutes, User 1 returns to her original computer, to find that the CGI is denying her access. User 2 has her locked out by using her ID.

This user verification system is particularly well suited in information delivery systems where a fee is charged per ID/password.

Web Server

The web server 4 uses a single CGI program that handles all the types of requests that a user makes to the web server 4. In the representative embodiment, the types of requests that the CGI program can handle are:

Return a list of reports recently received at the repository server 2.

Reformat the current list of reports.

Present a form that allows the user to specify criteria for reports the user wants to access.

Return a list of reports matching the criteria in the form mentioned above.

Return a list of reports summarized by report contributor.

Return a list of reports authored by a specific contributor.

These requests are handled similarly, except for the request for the form that the user fills in to specify criteria for reports that the user wants to access.

Except for the third request listed above, a query is formulated (whose parameters are determined by the run-time arguments given to the CGI from the original HTTP request from the investor) by the web server 4 and sent to the appropriate database 11, 13. A result set (a list of reports) is returned and stored in memory. The CGI then opens a HTML template form that comprises RAL (research access language) elements, fills in each RAL element with data from the result set and sends the contents of the template to the Internet browser through the Web Server 4. (In the case of the reports that are summarized by contributor, the CGI simply condenses the list of headlines internally to summary form, before using the template.) When the output from the CGI is received at the investor's Internet browser, the browser forms it into a "page" of information, along with action buttons that the investor can select to initiate other requests.

The request to present a "report query form" (the third request listed above) calls for the CGI to make several queries from the relational database 11. One query is for a list of all contributors whose reports this investor has authorization (i.e., is entitled) to access. The result set of this query is used to fill a list box, from which the investor is expected to pick the particular contributors whose reports the investor would like to access. Another query is for a list of all industries. The result set of this query is used to fill a list box, from which the investor is expected to pick the particular industries that the investor is interested in. Other queries are for lists of all reports meeting other criteria, such as, for example, countries, currencies, subjects, and document types. These list boxes are defined in the HTML template with RAL elements that are appropriate to this particular user request.

When a query is made, the web server 2 selects the appropriate database to which the query is first routed. In summary, if the query involves text matching (e.g., a full text search) within reports, the query is passed to the full text database 13. If the query does not involve text matching within reports, the query is passed to the relational database 11.

In the representative embodiment, each database comprises a number of database servers networked together. (for example, database server 13 comprises a network of database servers.) The database servers that are available to the CGI are listed in the WEBPUBL.INI file (a CGI initialization file) on the web server 4. When satisfying a non-text matching query, the CGI will attempt to use an SQL type server (e.g., 11) first. If that database server is not available, the CGI will automatically switch to the next available SQL database server. (If all SQL database servers are not available, then the query will be passed on to full text database server (e.g. 13).) When satisfying a text matching query, the CGI will attempt to use an full text database server (e.g. 13). Again, if that server is not available, then its backup will be tried, and so on, until either a server can satisfy the query, or all servers have been found to be down. In addition to this automatic backup system, the CGI practices semi-random selection of servers in an effort to balance the load on the servers. This means that the order that servers are tried is not always the same.

The HTML template forms that the CGI uses rely on the forms mechanism that is part of HTML. This allows the users to select buttons on the pages to submit requests. Each page may have several buttons, and the names of the buttons (the actual visible text in them) are used in the CGI to identify which button the user selected, and therefore, which action to perform. Parameters for a query are taken from other form constructs, such as text fields, list boxes, and combo boxes. When a form does not actively show a parameter value, but it would be convenient for the CGI to maintain its value for the next user request, the values are stored as "hidden" fields in the form. (A hidden field is a form construct defined in HTML for just this purpose.) This allows the parameters of a query to be stored in a page that shows the results of a query, so that they can then be used again as starting values when the user requests the report query form.

Authorization

In the representative embodiment, each user has authorization (i.e., is entitled) to access a subset of the information stored at the repository server 2. The contributor company (i.e., the report producer) determines who has access to each report. For example, an investment bank may designate that one of its reports can be accessed only by its employees and certain investors (e.g., its customers). Another report may be designated as accessible by employees only. A third report may be released for general distribution to all who wish to access that report. Every document contributed by a contributor is identified by a "contributor ID". Furthermore the document is assigned by the contributor to one or many "document groups" owned by the contributor. (Documents usually belong to one document group.)

The authorization information links an investor to a list of user groups. Each user group can include many users. Each investor may be permitted to access documents in one, some or all document groups.

The repository server 2 constantly maintains an up to date list of all the document groups available along with the documents in the relational database 11. This list is updated in real time after a document is added, and completely refreshed daily (e.g., after document removal of expired reports). The list is also updated after a contributor changes the entitlement status of an individual investor (or investor group).

To submit a query, an investor must be identified by the repository server 2. As the investor's credential are checked (see above), the authorization information is retrieved by the repository server 2. This authorization information contains a list of document groups the investor is permitted (entitled) to access.

Optimizations

Two types of optimizations are performed by repository server 2. The first is a simplification of the authorization restriction. The second is an optional optimization performed when the result set has to be sorted; it is aimed at reducing the perceived response time for the first answers to a query.

One of the characteristics of the architecture of the present invention is that each query submitted to a database 11, 13 is submitted as a structure description, rather than a fully formed SQL statement. The actual SQL statement is built by the database server 11, 13 itself. Thus, the optimizations can take place on the raw query definition (i.e., a structure definition) before executing the query. This allows for more powerful query optimization, and immediate query definition analysis to select the proper mechanism to execute it.

In the alternative, the actual SQL statement may be fully formulated and then submitted to the database server 11, 13.

1. Optimization of the authorization restriction

In query definition, the investor can restrict the query to a subset of the contributors the investor has access to. This feature is used to implement queries like "What's new today from XYZ" and "All reports relating to automobiles from PQR."

The purpose of the authorization optimizer is to build the least expensive (with respect to execution time) selection clause, which will restrict the investor's query to the database subset the investor is allowed to access.

The authorization optimizer uses this database content information, combined with the investor's accessible groups, as well as the contributor restriction in the query, to build the restriction clause using the following method.

The repository server 2 builds two lists of groups:

a) the list of groups the investor has requested and has access to.

b) the list of groups the investor has requested but doesn't have access to

Based on the number of elements in these two lists the authorization optimizer will build the proper selection clause.

The following pseudo code describes the actual code used to implement this algorithm:

    ______________________________________
    for (all the groups in the investor's allowed group list) do
    begin
    if (group is in the query contributor restriction)
             and group is in database)
    then add group to the allowed list
    end
    for (all the groups in the database) do
    begin
    if (group is in the query's contributor restriction)
             and group is not in the investor's allowed list)
    then add group to the disallowed list
    end
    if (allowed groups list is empty)
    then deny request
    else if (disallowed groups list is empty)
    then no restriction
    else if (decisionFunction (allowed list, disallowed list))
    then restrict to groups in allowed list
    else restrict to groups not in disallowed list
    ______________________________________

    ______________________________________
    Retrieve the count
    if (Query is sorted by a time) and (count > = threshold) then
    begin
    if (query definition contains a time range)
    then get the time range from the query definition
    else use an appropriate default value
    add the restriction for 1/10.sup.th  of the time range
    retrieve the first rows
    rows.sub.-- still.sub.-- to.sub.-- fetch = rows.sub.-- requested -
    rows.sub.-- already.sub.-- fetched
    if (rows.sub.-- still.sub.-- to.sub.-- fetch > 0)
    begin
            add the restriction for remainder of the time
            range
            retrieve rows.sub.-- still.sub.-- to.sub.-- fetch rows
    end
    end
    ______________________________________

    ______________________________________
                0  Today
                1  Last 2 Days
                2  ThisWeek
                3  Last 7 Days
                5  Last 14 Days
                7  This Month
                8  Last 30 Days
               10  All Dates
               12  Last 60 Days
               13  Last 90 Days
    ______________________________________

    ______________________________________
    microsoft       Find documents with
                    `microsoft` in their text.
    ibm & microsoft Find documents with `ibm` and
                    `microsoft` in their text.
    ibm .vertline. microsoft
                    Find documents with either
                    `ibm` or `microsoft` in their
                    text.
    ibm &           Find documents with `ibm`,
     ( microsoft    and either `microsoft` or
      .vertline. apple )
                    `apple` in their text.
    "earnings report"
                    Find documents with the phrase
                    `earnings report` in their
                    text.
    ______________________________________

    ______________________________________
    resultrl.tpl:
               List form output for a query.
    resultrd.tpl:
               Double line output for a query.
    resultrt.tpl:
               Table form output for a query.
    resultcl.tpl
               List form output for a query, broken
               down by contributor and document type
               during a summary.
    resultcd.tpl
               Double line output for a query, broken
               down by contributor and document type
               during a summary.
    resultct.tpl
               Table form output for a query, broken
               down by contributor and document type
               during a summary.
    resultq.tpl
               Query form.
    resultx.tpl
               Query count.
    resulti.tpl
               Symbol Guide form.
    resultt.tpl
               Standard HTTP header prepended to each
               of these templates.
    bboardrl.tpl:
               List form output for a bulletin board.
    bboardrd.tpl:
               Double line output for a bulletin board.
    bboardrt.tpl:
               Table form output for a bulletin board.
    bboardcl.tpl
               List form output for a bulletin board,
               broken down by contributor and document
               type during a summary.
    bboardcd.tpl
               Double line output for a bulletin board,
               broken down by contributor and document
               type during a summary.
    bboardct.tpl
               Table form output for a bulletin board,
               broken down by contributor and document
               type during a summary.
    ______________________________________

    ______________________________________
    start-token
             := "{mx" <white-space>
    white-space
             := (any ASCII character value between 1 and 32,
             inclusive)
    end-token
             := "}"
    attribute := <attribute-name> "=" <attribute-value>
    attribute-name
             := "end" .vertline. "name" .vertline. "true" .vertline. "width"
             .vertline. "align" .vertline.
             "start" .vertline. "false" .vertline. "empty" .vertline. "match"
             .vertline. "format" .vertline.
             "select" .vertline. "quotes"
    attribute-value
             := <double-quotes> <any-characters> <double-quotes> .vertline.
             <any-non-white-characters (except end-token)>
    Examples:
    {mx name=headline align=left width=50}
    {mx start=documents}
    {mx name=synopsis match=1 true=Yes false=""}
    ______________________________________

    ______________________________________
    Format string
                 Element Value
                             Output Result
    ______________________________________
    "%s"         "ABC Corp." "ABC Corp."
    "%15s"       "ABC Corp." "ABC Corp.  "
    "%-15s"      "ABC Corp." "  ABC Corp."
    "%5.5s"      "ABC Corp." "ABC C"
    "%s Documents"
                 "ABC Corp." "ABC Corp. Documents"
    ______________________________________

    ______________________________________
    Match   True       False   Element Value
                                         Output
    ______________________________________
    "1"     "Synopsis" ""      "0"       ""
    "1"     "Synopsis" ""      "1"       "Synopsis"
    ______________________________________

    ______________________________________
                0  Today
                1  Last 2 Days
                2  ThisWeek
                3  Last 7 Days
                5  Last 14 Days
                7  This Month
                8  Last 30 Days
               10  All Dates
               12  Last 60 Days
               13  Last 90 Days
    ______________________________________

    ______________________________________
    Analysts Names of the analysts that compiled the document.
    AnalystIDs
             Numeric ID's of the analysts that compiled the
             document.
    ByteCount
             Size of the document (in PDF form) in kilobytes or
             megabytes.
    Contributor
             Name of the company that compiled the document.
    ContributorID
             Numeric ID of the company that compiled the document.
    DocID    The internal system document ID number.
    DocType  `R` for a research document; `M` for a morning
             call note; `N` for a news document.
    Headline The headline of the document. The system of the
             representative embodiment also surrounds the output
             from a element that displays this field with an HTML
             "anchor" to a CGI that downloads the PDF file for
             the document, or generates an HTML page for
             documents with no PDF form.
    PageCount
             The number of pages in the document.
    ReleaseDate
             The official release date of the document.
    Relevance
             A number from 0 to 1000 that indicates the
             relevance of the document to the free text that
             was used in the query. The higher the number, the
             more matches on the free text.
    SubmitDate
             The date the document was submitted by the contributing
             company to the repository server 2.
    Symbols  A list of ticker symbols that the contributor listed as
             relevant in the document.
    Synopsis A "1"/"0" flag that indicates whether a synopsis is
             available for the document. By default, the value "Yes"
             is output if the synopsis is available, and ""
             is output otherwise. The representative embodiment
             also surrounds the output from a element that displays
             this field with an HTML "anchor" to a CGI that
             creates an HTML page with the actual synopsis text.
    ______________________________________

    ______________________________________
    if and -endif Usage
    {mx -if <expression> }
    . . .
    {mx -endif}
    where
    expression
           = <value> <operator> <value>
    value  = <string> .vertline. <number> .vertline. <variable>
    operator
           = == .vertline. < .vertline. > .vertline. |= .vertline. <=
           .vertline. >=
    string = <double-quote> ›<any-characters>!+ <double-quote>
    number := <digit>*
    variable
           := ›.sub.-- .vertline.$!<alphabetic character>›<alphanumeric
           characters>!+
    ______________________________________

    ______________________________________
    {mx -if morningnotes |= 0}
    - Click the "AM Notes" button to
    access them. <BR>
    {mx -endif}
    ______________________________________

    ______________________________________
    {mx -if.sub.-- contributors |= ""}
    Query on contributors {mx name=contributorstext}
    {mx -endif}
    ______________________________________

    ______________________________________
    <HTML>
    <HEAD>
    <TITLE>
    Bulletin Board
    </TITLE>
    </HEAD>
    <BODY>
    <h2><i>Bulletin Board</h2></i>
    <form method="POST" action="/CGIBIN/result.exe">
    <input type="submit" name="subaction" value="Refresh">
    <input type="submit" name="subaction" value="Query">
    <input type="submit" name="subaction" value="Summary">
    <input type="submit" name="subaction" value="AM Notes">
    Compare the total matching records to the maximum allowed in the
    display. If there are more, show the "change viewing mode" button.
    {mx -if total > maximum}
    <input type="submit" name="subaction" value="{mx
    name=changeviewmode}">
    {mx -endif}
    <input type="submit" "name="subaction" value="Long Form">
    <input type="hidden" "name="current" value="bboard"><br>
    Display the total number of documents that matched, and how many
    will be displayed in this list.
    <b>{mx name=docsshown}</b><br>
    </form>
    <PRE>
    <B>Submit Company
                  Pgs Size Symbol
                               Syn Headline
    </B>
    <HR>
    This part is a document enumeration. The enumeration shows the fields
    named `updatedate`, `contributor`, `pagecount`, `bytecount`,
    `symbols`, `synopsis`, and `headline`. Around the `synopsis` field,
    there is a use of the -if element, which decides whether to output a
    hypertext links to the synopsis. There is no -if element for the </A>,
    because an extra one doesn't hurt most browsers.
    (The following lines are split up with newlines to make it easier to
    read
    running this HTML, it will not give the desired results.)
    {mx start=documents}
    {mx name=updatedate width=7}
    {mx name=contributor width=20}
    {mx name=pagecount width=3 align=right}
    {mx name=bytecount width=4 align=right}
    {mx -if synopsis == 1}
    <A HREF="result.exe?subaction={mx name=synfile}">
    {mx -endif}
    {mx name=synopsis width=3}</A>
    <A HREF="result.exe?subaction={mx name=docfile}">{mx
    name=headline}</A>
    {mx end=documents}</PRE>
    <b>
    Display the final counts.
    {mx name=research} Research Documents<br>
    {mx name=morningnotes} Morning Notes
    {mx -if morningnotes > 0}
    Click the "AM Notes" button to access them.
    {mx -endif}
    <br>
    </b>
    If there were more than a screenful of headlines displayed,
    create another form and display the control buttons again,
    just for the user's convenience.
    {mx -if research > 17}
    <hr>
    <form method="POST" action="/CGIBIN/result.exe">
    <input type="submit" name="subaction" value="Refresh">
    <input type="submit" name="subaction" value="Query">
    <input type="submit" name="subaction" value="Summary">
    <input type="submit" name="subaction" value="AM Notes">
    {mx -if total > maximum}
    <input type="submit" name="subaction" value="{mx
    name=changeviewmode}">
    {mx -endif}
    <input type="submit" name="subaction" value="Long Form">
    <input type="hidden" name="current" value="bboard">
    </form>
    {mx -endif}
    </BODY>
    </HTML>
    ______________________________________

    ______________________________________
    <SELECT NAME=contributors SIZE=6 MULTIPLE>
    <OPTION VALUE="-1" selected>›All Contributors!
    <OPTION VALUE=42>Adams, Harkness & Hill
    <OPTION VALUE=47>Alex Brown & Sons
    <OPTION VALUE=128>Auerbach Grayson & Co., Inc.
    <OPTION VALUE=53>Brown Brothers Harriman & Co.
    <OPTION VALUE=109>Chicago Corporation
    <OPTION VALUE=157>Closed End Fund Digest
    ...
    ...
    <OPTION VALUE="-2">=======================
    </SELECT>
    ______________________________________

    ______________________________________
    ›IDENTIFIERS!
    CtbID=2         //id of contributor company//
    UserID=MC       //id of particular user//
    Password=MC     //user password//
    RecordType=CST
    Action=UPD      //this is an update//
    ›RESTRICTIONS!
    Restricted=Y    //restricted//
    RestrictDate=10/11/95
    RestrictedTime=12:59:01
    Review=X        //under extended review//
    ReviewDate=10/10/95
    ›Symbols!
    Primary=