A computer implemented method and system for information retrieval

Abstract: A computer-implemented method and system for of retrieving information. A first file of information is received which includes a first markup language to identify contents of the information. Responsive to the receiving the first file of information, the first file of information is parsed to generate a list of profiles, and at least one corresponding topic for each of the list of profiles. A second file in a second markup language is created containing the list of the profiles and at least one corresponding third file is created in a third markup language for the at least one corresponding topic for each of the list of profiles. The second file contains anchors referencing each at least one corresponding third file, and first markup instances in the first file of information are converted to second markup instances in either the second file or the third file. The first file of information is parsed to determine the at least one article, if any, for the each at least one corresponding topic for the each of the list of profiles, and a corresponding brief for the at least one article. A fourth file and a fifth file are generated for the at least one article, if any, for the each at least one corresponding topic for the each of the list of profiles. The fourth file includes a brief of each the at least one article in the first file of information and an anchor to the fifth file, the fifth file including text for the at least one article, if any, for the each at least one corresponding topic for the each of the list of profiles. In implemented embodiments, a sixth file can also be created which contains a plurality of anchors referencing a plurality of the fifth files, wherein the anchors in the sixth file are arranged by each the profile and corresponding topic. The first file of information can include receiving an electronic mail (e-mail) message. The processing of the first file, and the creation of the additional files with the included anchors allows hypertext viewing and traversal of the processed information. In another embodiment, a computer-implemented method and system for retrieving information includes using a hypertext transfer protocol to display to a user a display generated from a first markup language, containing a list a profiles, and at least one corresponding topic for each of the list of profiles. Searches may be performed on the information depending upon selected profiles and topics, and entered keywords.

Description: The present invention relates to a computer implemented method for information retrieval. More specifically, the present invention relates to a client/server model for information retrieval which includes the receipt of a plurality of information organized by profile and topic in a first markup language, and the parsing of the plurality of information into portions of information in a second markup language, including anchors referencing each of the portions of information to allow hypertext viewing and accessing. The development of computerized information resources, such as the Internet, and various on-line services, such as Compuserve, America Online, Prodigy, and other services, has led to a proliferation of electronically-available information. In fact, this electronic information is increasingly displacing more conventional means of information transmission, such as newspapers, magazines, and even, television. The primary issue in all of these resources is filtering the vast amount of information which is available in order that a user obtain that information which is of interest to him. Currently, a user who subscribes to one of the above-services, or uses the Internet, in some circumstances, manually scans through the various information resources in order to obtain articles, postings, or other files which are of interest. Typically, the user manually scans in areas or sources of interest (publications, USENET Newsgroups, fora, or other areas classified by topic) to find topic areas which may be of interest to the user. The user then retrieves articles or files which have subject headings, for example, matching those which the user wishes to read. For example, in USENET newsgroups on the Internet postings frequently have relevant subject headings to permit manual scanning. Article headings in newspapers/magazines serve similar functions. Thus, if the user does not wish to view those stories with products for sale, then he simply ignores those postings having the term "For Sale" in the subject heading. Finally, as a last level of filtering, the user can read the stories which have been filtered by topic, and subject heading, and if anytime during the viewing of the story the user wishes to ignore the rest of the article, he can stop reading it and simply discard the story. If desired, the user can download the remaining stories in any number of prior art ways, for off-line viewing. As is clearly evident, this manual scanning process which a user must engage in is very time-consuming. To some extent, news is already filtered for readers. Those that subscribe to certain magazines/newspapers, or view certain television networks, already have the vast base of electronically-available information (e.g. wire services) filtered for them. However, this "filtering" is performed on a large-scale basis, for a wide audience. The tailoring of specific stories of interest to particular users has not been performed. Thus, a need has arisen to automatically sort through the large variety of electronic sources in order to generate a subset of the stories available in electronic form which is tailored to a user's specific interests is desired. Other services have recently become available. Some allow the retrieval of information via facsimile or other means, based upon user-specified parameters. Certain commercial services now provide a facsimile service to retrieve articles of interest based upon predefined profiles. These profiles include those grouped by company or by subject area. The articles of interest are retrieved using standard prior art techniques (e.g. boolean search terms). These services do not to a large extent, however, provide the information in digital form (e.g. on a user-interface display), nor do they allow the browsing of information which is retrieved from these sources. Thus, the prior art of obtaining information from various sources suffers from several shortcomings. According to the present invention there is provided a computer-implemented method of retrieving information comprising the following steps: a. parsing a first file of information to generate a list of profiles, and at least one corresponding topic for each of said list of profiles, said first file being, in a first format for example, an email message in SGML format; b. generating a second file containing said list of said profiles and said at least one corresponding topic for each of said list of profiles, said second file being, in a second format for example, an index file in HTML format; c. parsing said first file of information to determine said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles; d. generating a third file for said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles, said third file including text for said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles; and e. inserting an anchor in said second file referencing said third file for said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles. In accordance with the present invention a first file of information is received which includes a first markup language to identify contents of the information. Responsive to the receiving the first file of information, the first file of information is parsed to generate a list of profiles, and at least one corresponding topic for each of the list of profiles. A second file in a second markup language is created containing the list of the profiles and at least one corresponding third file is created in a third markup language for the at least one corresponding topic for each of the list of profiles. The second file contains anchors referencing each at least one corresponding third file, and first markup instances in the first file of information are converted to second markup instances in either the second file or the third file. The first file of information is parsed to determine the at least one article, if any, for the each at least one corresponding topic for the each of the list of profiles, and a corresponding brief for the at least one article. A fourth file and a fifth file are generated for the at least one article, if any, for the each at least one corresponding topic for the each of the list of profiles. The fourth file includes a brief of each the at least one article in the first file of information and an anchor to the fifth file, the fifth file including text for the at least one article, if any, for the each at least one corresponding topic for the each of the list of profiles. In implemented embodiments, a sixth file can also be created which contains a plurality of anchors referencing a plurality of the fifth files, wherein the anchors in the sixth file are arranged by each the profile and corresponding topic. The first file of information can include receiving an electronic mail (e-mail) message. The processing of the first file, and the creation of the additional files with the included anchors allows hypertext viewing and traversal of the processed information. The present invention will now be further described, by way of example with reference to the accompanying drawings, in which like references indicate like elements, and in which:- Figure 1 shows a client/server system in which embodiments of the present invention may be implemented. Figure 2 shows a more detailed view of the client/server illustrated in Figure 1. Figure 3 shows the structure of a workstation in which the client or server may be operative. Figure 4 shows a more detailed view of processes operative within the server. Figure 5 shows an example of files which are processed in implemented embodiments of the present invention. Figures 6a and 6b show more details of files which are created in the server. Figures 7a-7d shows a sequence of steps performed in the server for generation of a profile and/or creation of a personal newspaper. Figure 8 shows the process performed during a user session, including the performance of any searching. Figures 9-13 shows various display screens for user control and showing the results of the processes illustrated in Figures 5a-5d and 7. DETAILED DESCRIPTION A portion of the disclosure of this patent document contains material which is subject to copyright protection and to which a claim of copyright protection is made. The owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyrights and similar rights whatsoever. The present invention is a method and apparatus for automatically creating hypertext documents from information using profiles and topics, and providing that information to a user. Although the following will be described with reference to certain particular embodiments, including data structures, flow of steps, hardware configurations, etc..., it will be apparent to one skilled in the art that implementations of the present invention can be practiced without these specific details. Implementations of the present invention use a client/server architecture, as illustrated in Figure 1, wherein user requests 110 for news are sent by a client application program 100 to a server 150 (typically, a remote computer system accessible over the Internet or other communication medium). The server 150, as will be described in more detail below, performs scanning and searching of raw (e.g. unprocessed) information sources (e.g. newswires feeds or newsgroups), based upon these user requests, presents the filtered electronic information as server responses 160 to the client process. The client process may be active in a first computer system, and the server process may be active in a second computer system, and communicate with one another over a communication medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information gathering capabilities of the server. A more detailed view of the client and server are shown in Figure 2. Although the client and server are processes which are operative within two computer systems, these processes being generated from a high level programming language (e.g. PERL), which is interpreted and executed in a computer system at runtime (e.g. a workstation), it can be appreciated by one skilled in the art that they may be implemented in a variety of hardware devices, either programmed or dedicated. Client 100 and server 150 communicate using the functionality provided by Hypertext Transfer Protocol (HTTP). The World Wide Web (WWW) or simply the "Web" includes all the servers adhering to this standard which are accessible to clients via Uniform Resource Locators (URL's). For example, communication can be provided over a communication medium 250. In some embodiments, the client and server may be coupled via Serial Line Internet Protocol (SLIP) or TCP/IP connections for high-capacity communication. Active within the client is a first process, known as a "browser" 200, which establishes the connection with server 150, and presents information to the user. Any number of commercially or publicly-available browsers may be used, in various implementations, however in this implementation, browser 200 is the Mosaic brand browser available from the National Center for Supercomputing Applications (NCSA) in Urbana-Champaign, Illinois. Other browsers such as the Netscape, Netcruiser, or the Lynx brand browsers, or others, which are available and provide the functionality specified under HTTP and the Mosaic browser may be used. The server 150 executes the corresponding server software which presents information to the client in the form of HTTP responses. The HTTP responses correspond with the Web "pages" represented using Hypertext Markup Language (HTML), or other data which is generated by the server, as will now be discussed. Under the Mosaic brand browser, in addition to HTML functionality 210 provided by the server (display and retrieval of certain textual and other data based upon hypertext views and selection of item(s)), a Common Gateway Interface (CGI) 220 is provided which allows the client program to direct the server to commence execution of a specified program contained within the server. This may include a search engine which scans received information in the server for presentation to the user controlling the client. Using this interface, and HTTP, the server may notify the client of the results of that execution upon completion. In order to control the parameters of the execution of this server-resident process, the client may direct the filling out of certain "forms" from his browser. This is also provided by the "fill-in forms" functionality 230 available under Mosaic, which allows the user via his client application program 100, to specify search terms in which the server will cause an application program to function (e.g. terms contained in the types of stories/articles which are of interest to the user). The details of this searching mechanism will be discussed below. A computer system, such as a workstation, personal computer or other processing apparatus in which the client 100 or server 150 may be operative is illustrated in Figure 3. A workstation in which one implementation of the present invention may be practiced includes system 300. 300 comprises a bus or other communication means 301 for communicating information, and a processing means 302 coupled with bus 301 for processing information. System 300 further comprises a random access memory (RAM) or other volatile storage device 304 (referred to as main memory), coupled to bus 301 for storing information and instructions to be executed by processor 302. Main memory 304 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 302. System 300 also comprises a read only memory (ROM) and/or other static storage device 306 coupled to bus 301 for storing static information and instructions for processor 302, and a data storage device 307 such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 307 is coupled to bus 301 for storing information and instructions. This may be used for storage of the various files to be described here including profile, indices, topics, and article files. System 300 may further be coupled to a display device 321, such as a cathode ray tube (CRT) or liquid crystal display (LCD) coupled to bus 301 for displaying information to a computer user. Such a display 321 may further be coupled to bus 301 via a frame buffer 310, which information such as a single or multiple frames or images for display upon display device 321. An alphanumeric input device 322, including alphanumeric and other keys, may also be coupled to bus 301 for communicating information and command selections to processor 302. An additional user input device is cursor control 323, such as a mouse, a trackball, stylus, or cursor direction keys, coupled to bus 301 for communicating direction information and command selections to processor 302, and for controlling cursor movement on display 321. Note, also, that any or all of the components of system 300 and associated hardware may be used in various embodiments, however, it can be appreciated that any configuration of the system may be used for various purposes according to the particular implementation. In one embodiment, system 300 is one of the Sun Microsystems® brand family of workstations such as the SPARCstation brand workstation manufactured by Sun Microsystems® of Mountain View, California. Processor 302 may be one of the SPARC brand microprocessors manufactured by Sun Microsystems®, Inc. of Mountain View, California. Note that the following discussion of various embodiments discussed herein will refer specifically to a series of routines which are generated in a high-level programming language (e.g., the PERL interpretive language) which is interpreted and/or executed in system 300 at run-time. These further are used in conjunction with the browser and server software available from NCSA, as described above, including the specification of the appearance of displays in HTML. It can be appreciated by one skilled in the art, however, that the following methods and apparatus may be implemented in special purpose hardware devices, such as discrete logic devices, large scale integrated circuits (LSI's), application-specific integrated circuits (ASIC's), or other specialized hardware. The description here has equal application to apparatus having similar function. Figure 4 shows in more detail the processes which form major components of implemented embodiments of the present invention. An SGML/HTML parser/converter process 400, implemented in PERL, communicates with the server via CGI 220, can process and respond to user requests for information, including search requests, in files which are resident upon the server. In addition, a search result formatter process 430 may also create certain HTML files 420 responsive to user search requests to perform a FreeWAIS search. The HTML versions of articles stored from the SGML mail message are searched for the presence of specified search terms, and additional HTML files created responsive thereto. The HTML results of these search requests can then be displayed on the client's console. In implemented embodiments, the HTML files 420 which are resident on the server are generated from an electronic mail (e-mail) message which is received from a second process, the news source 410. This process may be operative on yet another computer system and communicate with the server over a networking medium. In this implementation, the news source embeds within the e-mail message, Standard Generalized Markup Language (SGML) text which helps to identify and categorize the text. This is illustrated in Figure 5. This is one implementation only, however, and other sources (e.g. USENET Newsgroups) may be used as a news source. In a In this implementation, a news source provides an e-mail message at some predetermined time period to the server 210, and the HTML generator 400 parses the message, and creates HTML files which are made available during the client's session. The e-mail message contains embedded SGML text, which includes profile/topic(key) information. Of course, the text may be received in any number of descriptive/formatting languages. A profile, in this implementation, is one or many topics. For example, a profile list file may be entitled "Sun_Express_News.list" wherein a single profile name may be entitled "Direct Marketing." Keys (or topics) may be, for example, "Telemarketing" and "Catalog Sales." In another implementation, a profiles/topic may include a USENET newsgroup and subject heading. Individual topics, in this implementation, are generated via a search of large numbers of publications using heuristic techniques to obtain the topics and group them by profile. This front-end searching and categorization into profiles and topics is performed using a service available from Individual, Inc. Also, profiles are preset with specific topic(s) contained therein, although profiles and/or topics may be user-defined in other implementations. A separate directory is used for storing each topic. As illustrated in Figure 5 and 6b, a directory 501 representing a profile may be created (named "Internet Watch" in the example) is created, if required. If it already exists, then subdirectories (e.g. 502 and 503, named "Connectivity" and "Making Money") for the topic(s) contained within the profile also are present (and created, if required). Within each subdirectory, files are created (e.g. 504) which contained the parsed articles themselves contained within the e-mail message 500. Two types of files are stored for each article: a brief of the article; and the article itself. Briefs (a.k.a. abstracts) are used by the user during browsing of the results of the information retrieval to determine if a detailed review of the specific article is required. The various files created during SGML processing are shown in Figures 6a and 6b. In a specified directory (e.g. the root directory accessible via the Uniform Resource Locator [URL]) the html files index.html 610 and expanded_index.html 620 are stored. The index.html file 610, contains a list of all the profiles which are currently defined (as received in the SGML file). The expanded_index.html file 620, contains a list of the profiles along with their associated anchors referencing a list of abstracts (briefs) for each topic. Theses lists of abstracts are contained in key files (e.g. 620, 630), for each topic. The index.html file 610, expanded index.html 680, and key files are all created after parsing of the article files, wherein anchors are created in the various files in order to allows hypertext cross-referencing of the various related files and/or documents. As the SGML file is parsed, profile files (lists of topics) 640, 641, 642, etc... are created in order to keep track of profiles. These are stored in a profiles directory 630. As shown in Figure 6b, a topics directory 650 references each of the topics, stored as directories 660, 661, 662, etc... In each topic directory (e.g. 660), a key file 670 is stored which contains, by topic, references to each of the articles (e.g. 673) contained within the directory. As will be illustrated below, the key file 670 contained titles represented as anchors to the articles themselves, and associated abstracts (from the brief files - e.g. 672) stored in the directory. Each brief file, such as 672, also contains an anchor to the article file. Lastly, summary files, such as summary*.html 671, are stored in the directory which contain a previous weeks' summary of titles, represented as anchors, of articles stored in the topic directory. Summary files are stored with the file specification summary<date#>.html, wherein date# is a julian date for a previous week's date. Of course, any unique file specification may be used. The SGML file is processed twice to obtain relevant information. First, it is parsed to obtain the articles and briefs for each article. According to which profiles/topics the articles are relevant to each article and brief, directories, if required are created. The articles and briefs are then stored in to these subdirectories. A second pass of the profile and topic subdirectories causes the linkage of the index.html, expanded_index.html, key.html, and article html files for each topic for hyperlink cross-referencing. The details and mechanics of this are discussed below. An example of a story contained within an SGML formatted message is shown as follows: After parsing to create the profile list, the SGML file is parsed again to otain the brief and story files. HTML instances are substituted for SGML instances. Other corresponding formatting commands and/or codes may be used which correspond with those in the source language. In addition, an anchor is created referencing the article file itself, in order to allow hypertext browsing from the brief to the article itself. Anchors implemented using any number of hypertext retrieval techniques, and HTML is only discussed as one implementation. A brief file has a file name with the format: Wherein day# is the julian calendar date for the year, and story# is a unique number assigned to the story as it was read from the SGML file. An example of a brief file is as follows: An article file is similarly created wherein SGML instances are replaced by their HTML equivalents. An article file has a file name with the format: An example of an article or story file is as follows: Details of a process performed for creating the profile.list (and corresponding HTML file), topic, summary, article and brief files in implemented embodiments will now be discussed with rerference to Figures 7a-7d. The process is implemented as an interpretative PERL script, and is idle until the expiration of a predetermined time period, step 702 (e.g. 15 minutes). Upon the expiration of this time period, it is determined whether the server has received a new mail message containing the SGML formatted text, step 704. If so, then processing of the mail message can proceed. At step 706, the mail message is copied to a local working directory for additional processing. The file has a name with the format: The file is then parsed at step 710 to remove articles, obtain profiles/keys, and create any topic directories, if required. Subsequent to parsing of the sgml file and creation of html files, the directories are post processed at step 712 in order to create the homepage and expanded index, and provide linkage among the various article, brief, summary, topic, index, and expanded index files. Finally, at step 714, the FreeWAIS indices, used for performing keyword searching are updated to allow user searching of the profiles and topics. Figure 7b shows more details of the step 710 shown in Figure 7a. At step 730, it is determined whether there are any more article files contained within the SGML file. If not (e.g. an end-of-file condition is detected), then the process is complete. If so, however, then the next article file, including the profile/key information is read at step 732 (e.g. the next instance of <rec>). Stories are delimited by <rec></rec>. Then, the profile/key information contained within the article can be processed. As shown in the example SGML file above, profiles are delimited by the expressions <profile> </profile>. Topics are delimited by the expressions <key> </key> and follow the profile name. As shown above, profiles and keys (topics) follow each article, and are delimited by the expressions <catalog_items> </catalog_items>. If there are no more profiles/topics for the article, as detected at step 734, then process 710 proceeds to step 736. If there are more profiles, then it is detected at step 736 whether a profile file exists for the profile. If not, then a profile file is created at step 738. Then, at step 740, it is detected whether a topic subdirectory exists for the topic. If not, then it is created at step 742 and a entry is added to the profile file listing the topic in the profile file. Once the entry has been added to the profile file, and the topic subdirectory created, if required, then the article file is written at step 744, replacing all SGML instances with HTML instances. The brief file is similarly written. As shown in the example above, the brief file is delimited by <brief> </brief>. At step 748, it is detected whether any more topics defined for this profile. If so, process 710 proceeds to step 740. If not, it proceeds to step 734 for retrieval of the next profile in the article. As is evident from the flowchart, several copies of the article and corresponding brief may be created, however, as an optimization, links only may be stored in the directories to a single copy of the brief and corresponding article. Other modifications would be apparent to one skilled in the art. Figures 7c and 7d show the details of the post processing step 712. Step 712 is performed upon completion of processing of the article files from the e-mail message. Upon entry into step 712, complete profiles and associated topics are known. Thus, the Index.html and expanded_index.html files may be created at step 750. Anchors to the brief files and the corresponding articles occurs within the process at step 752. At step 754 it is determined whether there are any more topic subdirectories. If so, then the next topic subdirectory is retrieved at step 756. The key.html file (for referencing the articles) is created at step 758. The process then continues in figure 7d. At step 762 in figure 7d, it is determined whether there are any more brief files contained in the subdirectory. If not, then the process returns to step 754 of figure 7c. If so, then the next brief file is retrieved at step 764. The corresponding article file is then retrieved at step 766. The anchor to the article can then be added to the brief file at step 768. The brief file, including the anchor can then be inserted into the key.html file at step 770. This allows hypertext viewing of the article from the brief or key.html files via a browser. Upon completion of this processing, full hypertext browsing among the index, expanded index, topic, brief, or article files may then be accomplished. Figure 8 shows a process for displaying/searching using the above-created HTML files, and additional files which can be created on demand, after execution of a search. A session typically commences when the HTTP server detects a request for a client connect, step 802. Then, the requested page, typically the home page, is displayed on the client browser at step 804. Any other requested page can be displayed using normal HTTP exchanges, including, the profile list (home page), the expanded profile list which includes topics arranged by profile, or any selected profile, topic, brief or story page using the above-created HTML pages. In addition, the server detects whether a search has been requested at step 806. If so, then a FreeWAIS (inverted index) search is performed, at step 808, in the selected profiles, if any. At step 810, HTML page(s) containing the results of the search are generated, including story brief, and titles, organized by relevancy. Relevancy may include any number of factors, including but not limited to, primacy, and number of occurrences, in this order. Other, more sophisticated, relevancy measures may also be used. The story headings are displayed as anchors which reference the stories themselves. Upon completion of the search, the request page(s) are again displayed, in this case the search results, at step 804. Figures 9a and 9b show a scrollable display which is displayed as the main home page HTML file. A search field 910, which allows user input at any time using fill-in forms support under HTTP is displayed for FreeWAIS searching at any time in the selected profile(s). Each of the profile names (e.g. 920, 921, etc.) are selectable as anchors as profiles for the search or for referencing the expanded home page (Figure 10). The expanded home page display is shown in Figure 10. This includes profile headings (e.g. 1020, 1030) and corresponding topic anchors (1021, 1022, 1023, and 1031) for access to the topic main pages. Again, the expanded home page is searchable by entering text into field 1010. Figures 11a-11c include a scrollable display which shows the Topic Summary page accessible by selecting any of the topic anchors shown in Figure 10. This includes the topic heading 1100, and anchor 1101 to the previous topic, if any, for the profile. This also includes a next topic anchor 1102, and a return to profile page for returning to the home page shown in Figure 9. Anchors for story headings 1111, 1112, etc... are present for access to the stories themselves. The display also includes the brief for each story (e.g. 1121). A previous days headings only (1130, 1131, etc...) are shown and allow access to those stories, as shown in Figure 11b. Anchor 1140 of figure 11c allows the access of an HTML page for a previous week's stories for the given topic, if any. Figures 12a and 12b show the results of a FreeWAIS search, as described above. The search term(s) are shown in field 1200, and story headings (e.g. 1202), which act as anchors to the story pages themselves, are shown sorted by relevancy. The relevancy Score, including the date, is shown as 1201 for each article. The text from the brief HTML file is shown as 1203. Lastly, story text is displayed on a page such as that shown in Figure 13. 1300 includes the story title, 1301 includes identifying information regarding the story, and 1302 shows the story text itself. Thus, a method and apparatus for a retrieving information has been described. Note that though the foregoing has particular utility and has been described with reference to certain specific embodiments in the figures and the text, that one may practice the present invention without implementing all of these specific details. Thus, the figures and the text are to be viewed in an illustrative sense only, and not limit the present invention. The present invention is only to be limited by the appended claims which follow.

Claims: A computer-implemented method of retrieving information comprising the following steps: a. parsing (400, 710) a first file of information to generate a list of profiles (630), and at least one corresponding topic (660) for each of said list of profiles (630), said first file being in a first format, for example, an e-mail message in SGML format; b. generating (712) a second file containing said list of said profiles (630) and said at least one corresponding topic (660) for each of said list of profiles, said second file being in a second format, for example, an index file in HTML format; c. parsing (400, 710) said first file of information to determine said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles; d. generating (712) a third file for said at least one article, if any, for said each at least one corresponding topic (660) for said each of said list of profiles (630), said third file including text for said at least one article, if any, for said each at least one corresponding topic for each of said list of profiles; and e. inserting (712) an anchor in said second file referencing said third file for said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles. The method of claim 1 further comprises the step of receiving said first file of information in an electronic mail (e-mail) message (704). The method of claim 1, wherein said inserting an anchor in said second file referencing said third file for said at least one article, if any, for said each at least one corresponding topic for said each of said list of profiles includes generating a first level heading for each of said list of profiles, and generating a second level heading for said at least one corresponding topic for each of said list of profiles, wherein said second level heading includes a first anchor referencing said third file.

Inventors: HOOPER PHILIP J, MESKE CARL F, OPPERMAN MARK R, HOOPER, PHILIP J., MESKE, CARL F., OPPERMAN, MARK R.
Applicants: SUN MICROSYSTEMS INC, SUN MICROSYSTEMS, INC.
Application year: 1995
Main classification: G06F17
IPC codes: G06F17, G06F12, H04L29