Information delivery system and method

Abstract

The secure electronic distribution of research documents over the world wide web to investors who are authorized to receive said research documents. A repository server receives research documents from contributors. Also received are corresponding document profiles with information relating to each research document including authorization information specifying who is permitted to access each research document. The repository server includes a first database for structured query searches and a second database for full text searches. A web server is coupled to the repository server and coupled to the world wide web. The web server receives requests from investors for research documents that satisfy a query. The web server determines whether the first database or the second database should be searched based upon the type of query. The repository server transmits to the web server a list of research documents that satisfy the query and which the investor is authorized to access according to the authorization information. The web server formats the list of documents according to a template form. Optionally, queries can be optimized. The system has a control mechanism to prevent concurrent unauthorized access by two people using the same ID/password combination.

Claims

What is claimed is:

1. A computer-implemented system for the secure electronic distribution of research documents over the world wide web to investors who are authorized to receive said research documents, comprising:

a repository server receiving from a plurality of contributors a plurality of research documents in electronic form and a plurality of corresponding document profiles comprising information relating to each research document including authorization information specifying who is permitted to access each research document, the repository server including a first database for structured query searches storing the information from the plurality of document profiles and a second database for full text searches storing searchable full text of the plurality of research reports; and

a web server coupled to the repository server and coupled to the world wide web, the web server receiving a request from an investor for research documents that satisfy a query, the web server determining whether the first database or the second database should be searched based upon the type of query and thereafter requesting that the repository server query said determined database and transmit to the web server a list of research documents that satisfy the query and which the investor is authorized to access according to the authorization information, the web server thereafter formatting the list of documents according to a template form and transmitting the formatted list of documents to the investor.

2. The system of claim 1 wherein the template form is selected by the investor.

3. The system of claim 1 wherein the template form is selected by the web server according to the identity of the investor.

4. The system of claim 1 further comprising a user computer used by the investor and executing a browser program, the user computer coupled to the world wide web.

5. The system of claim 4 wherein the query is formulated by the investor at the user computer.

6. The system of claim 1 further comprising a plurality of contributor workstations, each coupled to the repository server, for transmitting to the repository server the plurality of research documents and the plurality of corresponding document profiles.

7. A computer-based system for the secure electronic distribution of documents over the world wide web to users who are authorized to receive said documents, comprising:

a plurality of templates, each template specifying an output format;

means for receiving a plurality of documents in electronic form from a plurality of contributors;

means for receiving a plurality of document profiles from the plurality of contributors, each document profile corresponding to one of the plurality of documents and comprising information related to said one of the plurality of documents;

means for receiving authorization information for each one of the plurality of documents, the authorization information defining who is authorized to access said document;

means for converting the plurality of documents into a common format;

means for storing the plurality of documents in said common format;

a relational database for storing the plurality of document profiles and the authorization information;

means for extracting text from the plurality of documents;

a full text database for storing the extracted text;

means for receiving a user identification code from a browser program of remote user;

means for blocking simultaneous use of the user identification code with automatic re-enablement after a predetermined period of inactivity from the user identification code;

means for submitting an initial query to the relational database for all documents the remote user is authorized to access and that were received from contributors during a previous preset time period;

means for transmitting results of queries to the browser program for display according to the format specified in one of the plurality of templates;

means for enabling the remote user to submit queries;

means for determining if a submitted query includes a text search parameter, and if so, routing said query to the full text database, and if not, routing the query to the relational database; and

means for executing the submitted queries by selecting all documents the remote user is authorized to access and that satisfy the submitted query.

8. A computer-based system for the secure electronic distribution of research documents over the world wide web to investors who are authorized to receive said documents, comprising:

a plurality of templates, each template specifying an output format;

means for receiving a plurality of research documents in electronic form from a plurality of contributors;

means for receiving a plurality of research document profiles from the plurality of contributors, each research document profile corresponding to one of the plurality of research documents and comprising information related to said one of the plurality of research documents;

means for receiving authorization information for each one of the plurality of research documents, the authorization information defining who is authorized to access said research document;

a relational database for storing the plurality of research document profiles and the authorization information;

means for extracting text from the plurality of research documents;

a full text database for storing the extracted text;

means for receiving a user identification code from a browser program operated by a remote user;

means for submitting an initial query to the relational database for all research documents the remote user is authorized to access and that were received from contributors during a previous preset time period;

means for transmitting results of queries to the browser program for display according to the format specified in one of the plurality of templates;

means for enabling the remote user to submit queries;

means for determining if a submitted query includes a text search parameter, and if so, routing said query to the full text database, and if not, routing the query to the relational database;

means for optimizing predetermined queries;

means for executing the submitted queries by selecting all research documents the remote user is authorized to access and that satisfy the submitted query.

9. The system of claim 8 further comprising means for blocking simultaneous use of the user identification code with automatic re-enablement after a predetermined period of inactivity from the user identification code.

10. The system of claim 8 further comprising:

means for converting the plurality of research documents into a common format; and

means for storing the plurality of research documents in said common format.

11. The system of claim 8 further comprising:

means for enabling the remote user to select a research document from the results of queries; and

means for transmitting the selected document to the remote user's browser program.

12. A computer-implemented system for the secure electronic distribution of research documents over the world wide web to investors who are authorized to receive said research documents, comprising:

a repository server receiving from a plurality of contributors a plurality of research documents in electronic form and a plurality of corresponding document profiles comprising information relating to each research document including authorization information specifying who is permitted to access each research document, the repository server including a first database for structured query searches storing the information from the plurality of document profiles and a second database for full text searches storing searchable full text of the plurality of research reports; and

a web server coupled to the repository server and coupled to the world wide web, the web server receiving a request from an investor for research documents that satisfy a query, the web server determining whether the first database or the second database should be searched based upon the type of query and thereafter requesting that the repository server query said determined database and transmit to the web server a list of research documents that satisfy the query and which the investor is authorized to access according to the authorization information, the web server thereafter transmitting the list of documents to the investor.

13. A method for optimizing search requests received from remote computers operated by users, comprising:

storing at a central server a plurality of document profiles, each document profile corresponding to a document and comprising information related to the document, including a set of one or more authorization groups for the document, each authorization group corresponding with a contributor of the document;

for each user, storing at the central server a set of accessible groups specifying which authorization groups of documents the user is permitted to access;

receiving, at a web server, a search request from a user at remote computer for documents, the search requesting including a limitation that the documents are from a specified contributor;

providing the search request to the central server;

at the central server, creating a first list of groups of documents stored at the central server listing the user's accessible groups that correspond with the specified contributor;

at the central server, creating a second list of groups of documents stored at the central server listing the groups that are not accessible to the user and that correspond with the specified contributor;

if the first list is empty, denying the search request;

if the second list is empty, then constructing a search for all documents of the specified contributor that satisfy the search request; and

otherwise, determining selecting the shorter of the first list and the second list, and if the shorter list is the first list, then constructing a search restricted to groups in the first list, and if the shorter list is the second list, then constructing a search restricted to groups of the specified contributor not in the second list.

14. The method of claim 13 further comprising the steps of:

executing the search at the central server;

providing the search results to the web server;

formatting the search results at the web server; and

providing the formatted search results via the Internet to the remote computer.

15. The method of claim 14 wherein the search results comprises a list of documents that satisfy the constructed search.

16. A computer-implemented method for optimizing a query that requests a list of documents sorted by time, the documents stored in a database, comprising:

providing a first query requesting a list of documents sorted by time and a maximum number of documents;

determining a count of the number of documents that satisfy the first query;

if the count is less than or equal to a predetermined threshold, then execute the first query and return the results;

if the count is greater than a predetermined threshold, then determine if the first query is for documents that are dated within a time range;

if the first query is not for documents that are dated within a time range, then select a default time range as the time range;

create a second query comprising the first query with a restriction for documents dated within a predetermined first portion of the time range;

execute the second query and return the results;

if the number of results returned is less than the maximum number of documents, create a third query comprising the first query with a restriction for documents dated within a remaining portion of the time range; and

execute the second query and return the results.

17. The method of claim 16 wherein the maximum number of documents is set by the user.

18. The method of claim 16 wherein the step of providing a first query requesting a list of documents sorted by time further comprises the step of transmitting the first query over the Internet from a remote user.

19. The method of claim 18 wherein the step of determining a count further comprises the step of providing the count over the Internet to the remote user as soon as determined.

20. The method of claim 18 further comprising the step of providing results over the Internet to the remote user as soon as partial results are returned.

21. A method for the secure electronic distribution of documents over the world wide web to users who are authorized to receive said documents, comprising:

providing a plurality of templates, each template specifying an output format;

receiving a plurality of documents in electronic form from a plurality of contributors;

receiving a plurality of document profiles from the plurality of contributors, each document profile corresponding to one of the plurality of documents and comprising information related to said one of the plurality of documents;

receiving authorization information for each one of the plurality of documents, the authorization information defining who is authorized to access said document;

converting the plurality of documents into a common format;

storing the plurality of documents in said common format;

storing the plurality of document profiles in a relational database;

storing the authorization information for each document in the relational database;

extracting text from the plurality of documents;

storing the extracted text in a full text database;

receiving a user identification code from a browser program of remote user;

blocking simultaneous use of the user identification code;

automatically re-enabling use of the user identification code after a predetermined period of inactivity from the user identification code;

initially, executing a first query to the relational database for all documents the remote user is authorized to access and that were received from contributors during a previous preset time period;

outputting results of the first query according to the format specified in one of the plurality of templates;

enabling the remote user to submit queries;

for each submitted query, determining if the query includes a text search parameter, and if so, routing said query to the full text database, and if not, routing the query to the relational database;

executing the submitted queries by selecting all documents the remote user is authorized to access and that satisfy the submitted query; and

outputting the results of the submitted query according to the format specified in one of the plurality of templates.

22. A computer-based system for the secure electronic distribution of documents over the world wide web to users who are authorized to receive said documents, comprising:

a plurality of templates, each template specifying an output format;

means for receiving a plurality of documents in electronic form from a plurality of contributors;

means for receiving a plurality of document profiles from the plurality of contributors, each document profile corresponding to one of the plurality of documents and comprising information related to said one of the plurality of documents;

means for receiving authorization information for each one of the plurality of documents, the authorization information defining who is authorized to access said document;

means for converting the plurality of documents into a common format;

means for storing the plurality of documents in said common format;

a first database for storing the plurality of document profiles and the authorization information;

means for extracting text from the plurality of documents;

a second database for storing the extracted text;

means for receiving a user identification code from a browser program of remote user;

means for blocking simultaneous use of the user identification code with automatic re-enablement after a predetermined period of inactivity from the user identification code;

means for submitting an initial query to the relational database for all documents the remote user is authorized to access and that were received from contributors during a previous preset time period;

means for transmitting results of queries to the browser program for display according to the format specified in one of the plurality of templates;

means for enabling the remote user to submit queries;

means for determining if a submitted query includes a text search parameter, and if so, routing said query to the second database, and if not, routing the query to the first database; and

means for executing the submitted queries by selecting all documents the remote user is authorized to access and that satisfy the submitted query.

Description

FIELD OF 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 OF THE INVENTION

Current computer technology allows documents and other information to be distributed 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, an information provider wishes to provide information to users on a controlled basis. For example, the information provider may want to provide information only to those users who have paid a fee or completed a registration process, and also may want to restrict access to certain types of information to certain classes of users. Additionally, the information provider may require that the format of the information provided to one user be different from the format of the same information provided to another user or class of users.

Further, some users only may be interested in certain types of information available from a particular information provider. Users may wish that the information received from an information provider be output in a format specific to that user.

Existing technology allows an information provider who distributes information via the WWW to restrict access to authorized users by means of, for example, a user identification code and/or password. However, current password authorization methods used on the WWW have a number of significant problems. When using a browser program, such as Netscape's Navigator program or Microsoft's Internet Explorer program, to access web pages, a user is simply making a request to a remote web server (having a unique IP address) for a file. This file is stored in the user's computer local memory and is output by the browser program. Typically, web pages are in HTML format (HyperText Markup Language). Each time the user "moves" to a new web page, the browser program makes a new request to a web server (which may be the same or another web server) for a file. Thus, although a user may provide a password to obtain a file from a web server, the user typically does not log-out when the user has finished with this file--the user simply issues a request for a file on another web server or closes down his or her browser program.

When a user initially accesses a web server, most browser programs can provide the web server with an identification code identifying the particular browser as well as the user's Internet Protocol ("IP") address. However, when a user accesses a web server through a proxy server, many users may appear to have the same IP address.

To prevent concurrent use of a user's identification code and password (e.g., to prevent the user from distributing the user's identification code and password for use by others) when a user initially accesses a web server, the web server, using current password technology, can prevent other access with that identification code for a predetermined period of time. However, if the user moves to another computer or browser program, then the authorized user will be prevented from accessing the web server from the new computer or browser program.

Thus, a secure sign-on procedure is needed that prevents multiple users using the same identification code and allows an authorized user to move to another computer or browser program and still be permitted to access the secure web server.

When providing information via the WWW, information providers can, in a crude way, "customize" the information for a user. One simple example of customization is providing the user with the results of a query. Here, the user submits a query to the web server, e.g., by completing a form, and, based on the user's request, the web server creates a web page (or form) comprising information satisfying the query and transfers this web page (or form) to the user's browser program for display. In such systems, the program used to create the web page (or form) is "hard coded", so that if the information provider wishes to change the format of the information, this program must be recoded or replaced. Recoding or replacing such programs is inefficient and often time consuming.

Further, every user who submits the same query to the web server will receive the same results in the same format. Existing methods of providing information to WWW users do not enable different users to be automatically provided with different views of the information. Thus, a procedure is needed to enable the provision of customized views of requested information to WWW users.

When a user submits a query to a web server, the web server will typically format and submit the received query to a database program or search engine. There can be many types of queries that a user submits via an information provider's web server. For example, some queries may request information based on categories contained in a relational database (e.g., all presidents who were born in Virginia) while other queries may require full text searches of textual documents (e.g., all documents containing the words "sell" and "IBM"). Currently, information providers maintain one database of information that is used to obtain the results of all types of queries. However, while a database search engine may be fast and efficient in obtaining search results for some types of queries, it may be slow and inefficient in obtaining search results for other types of queries.

Moreover, when responding to queries via the WWW, the web server is accessed by many users. Due to communication delays over the Internet, it is wasteful to tie-up the database program or search engine until each user has received the full results of the user's query. It would be desirable in some instances to provide a search mechanism that allows asynchronous searching of a database by multiple web users such that the database program or search engine can take advantage of communication delays when serving multiple users.

Thus, in summary, an Internet information delivery system is needed that has a secure but flexible password control mechanism so that information is provided only to users who are authorized to receive it, that efficiently retrieves any requested information, and that customizes the views of information provided to users in a flexible and robust manner.

SUMMARY OF THE INVENTION

The present invention provides an electronic information distribution system that allows remote users to receive, access and query information that is stored in electronic form at a central server, called a repository server. Ideally, users communicate with the repository server via the Internet. The repository server is coupled to the Internet by a web server. The repository server comprises or is coupled to a plurality of databases of information stored in electronic form.

Preferably, the 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. In the representative embodiment, 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. In the representative embodiment, each document submitted to the repository server is accompanied by a document profile comprising information organized according to predefined fields relating to the document.

The web server includes a web server program. The web server also includes a web server helper application using the appropriate API such as, for example, the Common Gateway Interface (CGI) program, BGI, NSAPI or ISAPI.

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 2.1 browser program. However, other browser programs, such the Mosaic browser or Microsoft's Internet Explorer 2.0 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.

Different users may be permitted to access different subsets of the documents stored at the central repository.

According to the present invention, the web server is coupled to at least two database search engines in the repository server. At least one search engine performs at least full text searching of textual documents. At least one other search engine performs at least searching on predefined fields of information. When a search is submitted by the user to the web server, it is determined what type of search is required, and the appropriate query (e.g., full text, search on predefined fields) is formulated and submitted to the appropriate search engine. The search engine returns a results set to the web server. Typically, the results set will comprise a list of documents satisfying the query and that the user has authorization to access. This architecture ensures that the most efficient search engine is used to obtain the search results and allows more than one search to be conducted in parallel.

In the representative embodiment, the repository server includes a number of optimizers. An authorization optimizer builds the least expensive (in terms of execution time) search selection clause which will restrict the user's query to the database subset that the user is authorized to access. A sorted queries optimizer speedily provides users with the results set even when the number of elements in the results set is substantial. The web server sends a query block to repository server for optimization and the actual database query is built by a database server.

Communication delays over the Internet are used to make apparent response time at the web server faster by interleaving server access and response through an asynchronous protocol to the search engine.

The web server can provide customized views of the information provided to users. The web server has access to a number of different template forms. The template forms are written in a novel computer language, called herein a "research access language" (or RAL) that describes how to format a HTML document and integrate the information from results set into this format. The web server interprets the template form and creates a HTML page comprising the information from the results set. The web server may have a number of template forms, for each type of query, for each user or class of user, etc. Thus, each user or class of users may receive information in a format defined for that user or class of users. The template forms of the present invention provide an additional advantage. Whenever the information provider wishes to change the output format of the information provided to users, a new template form is created and used by the web server. Template forms can easily be created (without having to "hardcode" any program) and can be loaded for use without having to take the web server off-line.

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 over proprietary networks, requiring the installation and maintenance 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 Internet (e.g., slower than proprietary networks, less secure, user interface limited to HTML format) 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.

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.

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.) Brokerage and investment banking firms distribute their reports only to selected investors (e.g., their customers). However, each investor may receive reports from more than one brokerage or investment banking firm. Investors require access to these reports on a timely basis. It is also desirable to search all available reports for those reports that may be of interest to the investor. The representative embodiment of the present invention provides an advanced, secure system to distribute reports on a timely basis from brokerage and investment banking firms to investors and that allows investors to access and query a database of reports located at a remote location.

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. The contributor workstations 14, 16, 18 are used by brokerage and investment banking firms to submit reports to the repository server 2. Optionally, the contributor workstations 14, 16, 18 may be coupled to the repository server 2 via proprietary network comprising a plurality of contributor servers 20, 22. Alternatively or additionally, a contributor workstation 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 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, 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 or on a server or network drive coupled to the contributor workstation 14, 16, 18. 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, 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. In the representative embodiment, the reports are "pushed up" from the contributor servers 20, 22 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 in to a predetermined 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 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 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. In the representative embodiment, the user computer 6, 8 executes an Internet browser program, such as, for example, Netscape's Navigator 2.1 browser program. The Internet browser can read files in HTML format. In the representative embodiment, the Internet browser has access to a plug-in program that can read files in the predetermined format. In the representative embodiment, the plug-in is the Acrobat Exchange program, available from Adobe Systems that can read files in ".pdf" format. The user computer 6, 8 can connect with the Internet via, for example, a commercial Internet Service Provider.

The web server 4 includes to 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 is an interface between the web server program and other programs. 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, such as, for example, BGI, NSAPI or ISAPI, can be used in place of CGI within the principles of the present invention.

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 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:00PM, he goes home, without closing down his browser.

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

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

At 8:00AM the next day, he arrives at work, and tries to access the web server 4 again. Because his 10:00PM 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 two queries from the relational database 11. The first query is for a list of all contributors whose reports this investor has authorization 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. The second 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. 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 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 forms that are 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 to access a subset of the information stored at the repository server 2. The contributor 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 document groups. 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 report groups available along with the reports in the relational database 11. This list is updated in real time after a report is added, and completely refreshed daily (e.g., after report removal of expired reports).

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 report groups the investor is permitted 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.

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 restriction 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.
    ______________________________________

    __________________________________________________________________________
    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
    ______________________________________

    ______________________________________
    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}
           - ere are {mx name=morningnotes}
           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>BulletinBoard</h2> </i>
    <form method="POST" action="/CGIBINIresult.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 name=symbols width=10}
    {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>
    __________________________________________________________________________

    __________________________________________________________________________
    <HTML>
    <HEAD>
    <TITLE>
    Bulletin Board
    </TITLE>
    </HEAD>
    <BODY BGCOLOR="ffffff">
    <nobr>
    The next line, though has an RAL element that gets its value from the
    initialization file
    that "result.xe", named "webpubl.ini". The dollar sign before "webserver"
    indicates
    that "result.exe" should look up the JNI entry named "webserver", and
    substitute its
    name here in the HTML.
    <h2> <A HREF="{mx name=$webserver} /home/imagemap/mxnetlog.map">
    <IMG SRC="/home/gif/mxnetlog.gif" BORDER=O ALT="Service Name" ISMAP>
    </A> <i>
    Bulletin Board
    </h2> </i>
    </nobr>
    <form method="POST" action="/CGIBIN/result.exe">
    <nobr>
    <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">
    The next lines are conditional, depending on whether the "total" number
    of headlines
    returned from a headline list query is greater than the "maximum" number
    that
    "result.exe" has been configured to display. When "result.exe" is
    confronted with
    resolving the value for "total", it first checks to see if it has that
    value yet. If not, it
    then goes into a waiting mode, while it waits for that value to arrive
    asynchronously
    from the database server 11, 13. Once the total arrives (which it does
    independently
    of the actual headline records), "result.exe" proceeds with evaluating
    this "if"
    condition. If the evaluation is false, then all text until the next
    "endif" is ignored.
    {mx -if total > maximum}
    In this example one, the total number of headlines returned is 143, while
    the value set
    for "maximum" is 100. So this condition is true, meaning the next line
    gets evaluated
    and sent out. The element named "changeviewmode" is intended to generate
    text for a
    button that the user can press to change from viewing only 100 headlines,
    to view all of
    them. So this element's value will become
    "View All 143".
    <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">
    The next line has the element "docsshown". This evaluates to a phrase
    that tells the
    user what he is being shown. In this case, the element's value is "Latest
    100 of 143
    documents". These values depend on the total number of records, the
    maximum, and
    whether the user presses the "changeviewmode" button later, in which case
    it would
    show "143 documents".
    <br> <font > <b>{mx name=docsshown)</font> </b> <br>
    </nobr>
    </form>
    <PRE>
    <B>Submit Company  Pgs Size Symbol  Syn Headline
    </B>
    The next line actually does not contain any line breaks until the </PRE>,
    but it is
    wrapped it here for clarity. The first element "{mx start=documents}"
    marks the
    beginning of a loop, causing "result.exe" to repeat this section through
    the "{mx
    end=documents)" as long as there are headline records in the result from
    the query.
    All the elements in between are involved in displaying fields of the
    headline records,
    and in two cases, they are used to establish hypertext links to
    "result.exe" with
    arguments that display document synopsis and document contents. Of
    particular
    interest here, is that "result.exe" will access the headline records as
    they arrive
    asynchronously from the database server 11, 13, displaying them as soon
    as they
    arrive. The entire result set of the query does not have to be present
    for display to
    start, thus making the display to the user appear faster. In fact, the
    server is
    programmed to break the query to it up into pieces if sorting the results
    will be a
    lengthy process, as discussed above in the section titled
    "Optimizations". When a
    query is broken up, the most recent headlines are accessed first, which
    is the order
    that they are shown in this list. In addition, "result.exe" makes certain
    that the data is
    being sent to the server (and therefore to the user) by flushing its
    output queue every 5
    headlines.
    <HR>{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 name=symbols width=10} {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>
    The next lines display counts of the documents, broken down by report
    type (e.g.,
    here, research documents and morning notes.) Some of the output is
    conditional,
    depending on a zero value.
    {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>
    It is convenient to have the action buttons also at the end of a long
    list of documents,
    but it looks unprofessional to have two sets of buttons with a short list
    of documents.
    So the next section that displays buttons is identical to the button
    display section above,
    except that it is conditional on how many research documents were
    actually displayed.
    (mx -if research > 17}
    <hr>
    <form method="POST" action="/CG1B1N/result.exe">
    <nobr>
    <input type="submit" name="subaction"
    <input type="submit" name="subaction"
    <input type="submit" name="subaction"
    <input type="submit" name="subaction"
    {mx -if total > maximum}
    <input type="submit" name="subaction"
    {mx -endif}
    <input type="submit" name="subaction" value="Refresh">
    value="Query">
    value="Summary">
    value="AM Notes">
    value="{nm name=changevieWmode}">
    value="Long Form">
    <input type="hidden" name="current" value="bboard">
    </nobr>
    </form>
    {mx -endif}
    </BODY>
    </HTML>
    __________________________________________________________________________

    __________________________________________________________________________
    <html>
    <head>
    <title >Document Query</title>
    </head>
    <body BGCOLOR="#ffffff">
    <nobr>
    <h2> <A HREF="{mx
    name=$webserver}/hcyme/imagemap/mxnetlog.map"> <IMG
    SRC=91/home/gif/mxnetlog.gif" BORDER=O ALT="Service Name" 1SMAP> </A>
    <i>
    Document Query
    </h2> </i>
    </nobr>
    <nobr>
    <form method="POST" action="/CG1B1N/result.exe">
    Generate the buttons for commands to be executed from this form.
    <input
        type="submit"
               name="subaction"
                        value="Submit">
    <input
        type="submit"
               name="subaction"
                        value="Count Only">
    <input
        type="submit"
               name="subaction"
                        value="Summary">
    <input
        type="submit"
               name="subaction"
                        value="AM Notes">
    <input
        type="submit"
               name="subaction"
                        value="Reset">
    <input
        type="submit"
               name="subaction"
                        value="BBoard">
    <input type="hidden" name="current" value="query">
    </nobr>
    <table>
    <tr valign="top">
    <td width=90> <b>Symbol:</b> </td>
    The element here is evaluating the value for "-ticker". Any element name
    that begins
    with an underscore is taken from values that are given to "result.exe" as
    input from the
    last form that started "result.exe". If the last form had a field (text,
    list box, hidden, or
    otherwise) named "ticker" (no underscore), then the web server 4 would
    start this
    instance of "result.exe" with an input field named "ticker" whose value
    would be the
    value in the "ticker" field in the last form. If the last form had a
    field named "ticker"
    with a value of "IBM", then this element will generate a default value
    for this input
    field of "IBM". This allows "result.exe" to come back to the previous
    state of this
    query form, if other forms remember the value for "ticker" in hidden
    fields.
    <td> <input type="text" name="ticker" value={mx name=-ticker quotes=1}
    > </td>
    <td width=86>
    <td> <input type="submit" name="subaction" value="Symbol Guide"> </td>
    </tr>
    </table>
    <table>
    <tr valign="top">
    <td width=90> <b>For Period Of:</b> </td>
    The following list box has one value preselected, due to the "match" and
    "true" parts
    in the elements within it. These elements evaluate the value for the
    field "date" from
    the last form, and if the value matches the value given for the "match"
    part, then the
    displayed value for the element will be contents of the "true" part of
    the element, in
    this case, the word "selected". In other words, for each one of these
    lines, you could
    read "If the last form's date field matches X, then display the word
    `selected"`. The
    special case for "Last 7 Days", where the match value is ",3", simply
    means that if the
    date value is either empty, or the number three, it is a match.
    <td> <select name="date">
    <option value="0" {mx name=.sub.-- date match=O true=selected} >Today
    <option value="1" {mx name=.sub.-- date match=1 true=selected} >Last 2
    days
    <option value="2" {mx name=.sub.-- date match=2 true=selected} >This
    Week
    <option value="3" {mx name=.sub.-- date match=,3 true=selected} >Last 7
    days
    <option value="5" {mx name=.sub.-- date match=5 true=selected} >Last 14
    days
    <option value="7" {mx name=.sub.-- date match=7 true=selected} >This
    Month
    <option value="8" {mx name=.sub.-- date match=8 true=selected} >Last 30
    days
    <option value="12" {mx name=.sub.-- date match=12 true=selected} >Last 60
    Days
    <option value="13" {mx name=.sub.-- date match=13 true=selected} >Last 90
    Days
    <option value="10" {mx name=.sub.-- date match=10 true=selected} >All
    Dates
    <option value="-1">= = = = = = = = = = = = = = = = =
    </select> </td>
    </tr>
    </table>
    <table>
    <tr>
    </tr>
    </table>
    <table> <tr valign="top"> <td width=90> <b>Keywords: </b> </td>
    Here, a default value for this field is based on the "query" field in the
    last form.
    <td> <input type="text" name="query" size=49 value={mx name=.sub.--
    query
    quotes=1} > </td> </tr>
    </table>
    <table>
    <tr valign="top"> <td width=90> <b>Contributors: </b> </td>
    <td> <SELECT NAME=contributors SIZE=6 MULTIPLE>
    This is a possible default selection, the same as described above for
    "date."
    <OPTION VALUE="-1" {mx name=-contributors match=,-1 true=selected}>› All
    Contributors!
    This element marks the beginning of a loop on contributors. When this
    element is
    evaluated, "result.exe" forms a query to the server that will return a
    list of all
    document contributors (companies) that this particular user is entitled
    to read
    documents from. The request is asynchronous, so as each contributor
    record is
    returned from the server, "request.exe" can fill in the inside of this
    loop. Inside the
    loop is an element that displays the ID number of the contributor,
    optionally followed
    by the word "selected" if it should be the default selection on this
    form, based on prior
    values of the form fields "contributors".
    {mx start=contributorlist}
    <OPTION VALUE={m name=contributorid match=.sub.-- contributors true="%s
    selected" false="%s"}>{mx name=contributorname}
    {mx end=contributorlist}
    <OPTION
    VALUE="2">= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
    = = =
    = = = = = = = = = = = =
    </SELECT>
    </td> </tr>
    <tr valign="top"> <td> <b>Industries:</b> </td>
    <td> <SELECT NAMEmindustries SIZE=6 MULTIPLE>
    <OPTION VALUE="-1" {mx name=.sub.-- industries match=,-1 true=selected}>›
    All
    Industries!
    This element and the following loop is the same as the contributor loop
    above, except it
    lists the industries that the user may choose as selection criteria for
    documents, instead
    of contributors.
    {mx start=industrylist}
    <OPTION VALUE={mx name=industryid match=.sub.-- industries true="%s
    selected"
    false="%s"}>{mx name=industryname}
    {mx end=industrylist}
    <OPTION
    VALUE="2">= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
    = =
    </SELECT>
    </td> </tr>
    </table>
    <hr>
    These buttons are duplicates of the ones above -- we found it was
    convenient to have
    them here too.
    <input
        type="submit"
               name="subaction"
                        value="Submit">
    <input
        type="submit"
               name="subaction"
                        value="Count Only">
    <input
        type="submit"
               name="subaction"
                        value="Summary">
    <input
        type="submit"
               name="subaction"
                        value="AM Notes">
    <input
        type="submit"
               name="subaction"
                        value="Reset">
    <input
        type="submit"
               name="subaction"
                        value="BBoard">
    <input
        type="hidden"
               name="current"
                        value="query">
    </form>
    </body>
    &l