PERSONALIZED METABROWSER
CROSS-REFERENCE TO RELATED APPLICATIONS
The following patent claims the benefit of a Provisional U.S. Patent Application Serial No. 60/137,302, entitled "Information for Personalized Browsing/Intelligent Agent Software, which was filed on June 3, 1999 and is incorporated herein by reference.
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention relates to the presentation of data retrieved from the Internet, and more specifically to building a presentation template for presenting various data segments of multiple Internet documents dynamically on a display screen.
Description of the Background of the Invention
The onset of Internet technology has made it possible for users of computing devices connected to the Internet to access vast and ever-increasing sources of information. However, despite the wide availability and volume of such information, the means of bringing diverse elements of such information together in real-time for the purpose of displaying them on a single presentation page or screen is still evolving.
Commercially available programs designed for retrieving
and displaying Internet documents are called browsers. Examples include Microsoft Internet Explorer™ and Netscape Navigator™. Browsers download and display Internet documents, which may be found in hyper-text markup language (HTML) or embedded extensible markup language (XML) format, one document at a time. These documents may be retrieved from Internet- connected devices, called Internet sites, which are assigned discrete Uniform Resource Locator (URL) addresses.
Where a single browser is employed, two separate' documents may be viewed by requesting, retrieving, and viewing a first document, followed by the request, retrieval, and viewing of the second document. However, the first retrieved document will be lost from view when the second is viewed, although BACK and FORWARD browser navigation commands may allow fast representation of a previously retrieved (and now "lost to view) document. This problem can be somewhat alleviated by using more than one copy of a browser. Where multiple copies of a browser are employed, multiple separate documents may be viewed by requesting each copy of the browser being used to retrieve and display a separate document. In the windowing environment of most current operating systems, e.g., WindowsNT™, multiple documents retrieved by individual browsers may be viewed simultaneously, side by side, or in whatever manner the user chooses to arrange the viewable windows.
To facilitate solutions to problems of simultaneous retrieval of a plurality of Internet documents, intelligent agent software may also be used. Intelligent agent software, shown in Figure 1, is used to perform a wide variety of activities on the Internet, including an assortment of computing tasks such as searching, evaluating, reconfiguring, and filtering of documents. Intelligent agent software may act
autonomously on behalf of users, and may sense the state of their computing environment, adapt to changes, and perform intended activities according to predefined and learned parameters .
When multi-tasking intelligent agent software is used to download Internet documents, it may automatically load a plurality of predetermined documents from a variety of Internet sites to the user's desktop at one time. This multi-tasking ability allows intelligent agent software to create a "personal portal" on the user's device, which may facilitate finding, qualifying, comparing, and procuring products and services online.
The one issue that intelligent agent software does not address or resolve, is the arrangement and presentation of the aggregated content to the user on a single display page. Products currently available to search and display multiple Internet documents include applications such as CatchTheWeb, a description of which may be found at http://www.catchtheweb.com/. CatchTheWeb' s site describes the application as follows:
"... an integrated development environment for managing your page archive. You can view the pages, re-organize their order, remove them, change their titles, and revise your notes about them. "
Although programs such as CatchTheWeb may solve the problem of collecting related information, the end product of CatchTheWeb is a list of Internet documents (pages) which can only be viewed one document at a time. The comprehensive presentation of data of interest filtered and collected from more than one page and displayed on a single page display is not addressed by this product.
Presently, a need exists to customize the display of retrieved Internet documents. Customized displays may include a whole document, a part of the document, or just one data segment presented in a document. A single data segment may be static or it may be dynamically modified on a regular or irregular basis by its host Internet site. For example, a vacation resort may have an HTML/XML document that describes the resort, its room availability and its prices. Another related HTML/XML document may describe local amenities, i.e., restaurants, hotels, theaters, and recreation facilities near the hotel. A different Internet document may include daily weather reports for each city in the state where the target vacation resort is located, including water and air temperatures updated hourly.
Using today's browsing technology, an Internet user is required to retrieve and view each of these documents separately: the resort document, then the entertainment document, followed by the weather document, although not necessarily in that order. And, as noted above, viewing one document may preclude viewing another at the same time. Additionally, users interested only in the resort's weather would be required to retrieve and display the entire HTML/XML document containing that information, an inconvenient process when only one element of the page on which such information appears is desired.
Therefore, what is needed is a mechanism to retrieve multiple HTML/XML documents located in a variety of separate URL locations, select the information from them in which the user is interested, and display that information all at once on a pre-formatted presentation document, according to
instructions found in a presentation template, and all on a single page. Furthermore, the size (in bits) of the presentation template must be minimal so that the aggregated content may be displayed on Internet connected devices of various capacities.
SUMMARY OF THE INVENTION The present invention allows a user of an Internet connected device to build presentation templates for the display of data segments from multiple documents. These documents may be retrieved by browsers or intelligent agent software.
All requested documents are gathered and parsed into nodes containing data segments. These documents are then displayed showing selectable data segments separated by lines. The user peruses and selects wanted data segments. A display representation is then built by arranging selected data segments in appropriate windows of the display re-presentation.
Display re-presentations may also be constructed from a prefabricated set of display re-presentations and multi-media presentation metaphors. To complete the formation, the following data for all selected data segments may be stored in the presentation template:
1. the address of the document, e.g., the URL;
2. the location of each data segment within its parent document, as described by counting "begin" and "end" tags from the start of the document; 3. the size of the display re-presentation and the arrangement location of each data segment within the display re-presentation; and
4. attribute information for each data segment.
After completion, the presentation template may comprise instructions for making Internet requests for target Internet documents, intelligently selecting data segments from these Internet documents, and presenting these data segments in an organized fashion to a viewer.
Upon being employed by a presentation segment of the inventive software, at a user's request or on a scheduled basis, the presentation template may provide instructions to retrieve specific documents, translate exact content locations of these documents, and display these contents in specified formats. The user pre-configured presentation template allows for real-time retrieval and selection of multiple data segments from multiple Internet sites and other sources, locally or via the Internet. The presentation template may be used for execution by the inventive application or may be executed by any off-the-shelf browser.
BRIEF DESCRIPTION OF DRAWINGS
The foregoing objects and advantages of the present invention may be more readily understood by one skilled in the art with reference being had to the following detailed description of a preferred embodiment thereof, taken in conjunction with the accompanying drawings wherein like elements are designated by identical reference numerals throughout the several views, and in which:
Figure la is a pictorial representation of the environment in which the inventive software creates a "personal portal" for accessing a plurality of documents.
Figure lb is a diagram of a computer system used for implementing the present invention.
Figure 2 is a sample retrieved document.
Figure 3 represents the data of the document shown in Figure 2.
Figure 4 is a flowchart of an inventive process for retrieving and parsing documents and for building a presentation template.
Figure 5 is a flowchart of an inventive process for parsing individual retrieved documents.
Figure 6a shows the document data of Figure 3 after it has been parsed by the parsing process of Figure 4.
Figure 6b is an illustration of an object tree constructed in accordance with the document 20 as shown in Figure 2.
Figures 7a-d are samples of retrieved document of Figure 2, displaying separated, selectable data segments.
Figure 8a is an user interface view combining component programs of the invention and a document display.
Figure 8b is an user interface view for building the presentation template.
Figure 9a is a flowchart of an inventive process for building the inventive presentation template.
Figures 9b and c represent a data file or a blueprint for storing pointers to data segments.
Figure 10a is a diagram of a computer system used for displaying the presentation template of the present invention.
Figure 10b is a flowchart of an inventive process for displaying the inventive presentation template.
Figure 11 is a flowchart of an inventive process for translating and displaying retrieved selected Internet documents according to the inventive presentation template.
Figure 12 is a flowchart of an inventive error checking process.
Figure 13 is a display of rearranged data segments from the document of Figure 8a.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
Referring now to the drawings and in particular to Figure la, there is shown a network system 10, which comprises a computer system 12 upon which the software of this invention is executed, a plurality of Internet-connected devices or websites 14a-g, -a plurality of databases 16a and b, and a network 11 for interconnecting the computer system 12 to each of the websites 14 and the databases 16. In one illustrative embodiment, the present invention may be implemented over a network 11, such as the Internet or intranet. Alternatively, a network may not be necessary, where the data may be retrieved from a storage device .
Where the network 11 takes the form of the Internet, the computer system 12 may be engineered to work with existing products built using interactive Internet (web) development tools such as a common gateway interface (CGI) 18 using Perl scripts, and an active server agent 18, which works with documents written in Java and Java/Visual languages. Through the use of these tools, the present invention may simultaneously access and retrieve data from the plurality of Internet or web sites 14a-g, as well as the Internet connected databases 16a and b.
Referring now to Figure lb, the details of the computer system 12 are shown. In one illustrative embodiment of this invention, the computer system 12 comprises a bus 1, which is connected directly to each of a central processing unit (CPU) 2, a memory 3, a video interface 4, an input/output (I/O) interface 6, and a communications interface 8. The common bus 1 is connected by the I/O interface 6 to a storage device 7, which .may illustratively take the form of memory gates, disks, diskettes, compact disks (CD) , digital video disks (DVD), etc. The video interface 4 couples a display 5 to the common bus 1. The communications interface 8, e.g., a modem, is coupled to an internet connection 9, e.g., an Internet Service Provider (ISP), which in turn is connected to the network 11, whereby a data path is provided between the network 11 and the computer system 12 and, in particular, its common bus 1.
The computer system 12, as shown in Figures 1 a and b, operates in the context of this invention to transmit requests via the network 11 to selected websites 14 to access and download therefrom data, which represent a document 20 as illustrated in Figure 2. The document 20 is transferred to the
computer system 12, where it is processed one data element at a time and displayed on the display 5 as the document 20 shown in Figure 2. The downloaded document data as processed corresponds to the text shown in Figure 2, i.e., "Our rates and prices:" as well as the rest of the illustrated text. In addition, the document data also includes a collection of embedded codes that explain the meaning or desired formatting for the marked text. The embedded codes include instructions or commands, which control what the document will look like and/or where it will be positioned within the document 20. Though the markup language illustratively shown herein is the well-known Hyper Text and Extensible Markup Languages (HTML or XML) , it is appreciated that there are other such delimited formats, e.g., "Acrobat" or "WordPerfect", which may be employed in this invention. It is appreciated that only the marked up text, but not the markup language itself, will appear in the displayed document 20 of Figure 2.
The document data transmitted over the network 11 from a selected website 14 is comprised of the data text shown in
Figure 2 and the embedded codes for imparting the arrangement of that text as shown in Figure 2. Physical arrangement of the document data is re-arranged in Figure 3 to illustrate how the embedded codes delimit data containers, and how those data containers are nested at different levels within the document data.
As will be explained below, the data containers are assigned various numbers. As also shown in Figure 3, each of the plurality of data containers comprises the content that is identified by the numeral 24, and a pair of embedded codes, known in computer terminology as "tags" or "tokens" 22 and 26. These tags 22 and 26 are disposed on either side of their data
content 24 and are respectively known as "begin" tags 22 and "end" tags 36, respectively. The begin tags 22 and the end tags 26 are both constructed of closed brackets "< >", but differ from each other in that only the end tags 26 include a "/". In one embodiment of this invention, the data container is identified by the numeral 32a and enclosed by a rectangularly shaped block to readily recognize the data container 32a. The begin tag 22 "<H1>" and the end tag 26 "</Hl>" are disposed in the data container 32a directly on either side of the data text 24, "Our rates and prices". Contrast this configuration of data container 32a with that of container 32b, where the begin tag 22 <TABLE> and the end tag 24 </TABLE> are surrounded by the rectangularly shaped box 34b; the begin tag 22 and the end tag 26 are displaced from each other and serve to delimit the data content 24 contained in the box 32d. Though the data content 24 has been described in terms of text and shown in Figure 2 as such, it is appreciated that such content may comprise video data, images and/or links to other websites 14 that are connected to the network 11.
The boxes shown in Figure 3 illustrate the nesting of the data containers with respect to each other and at a plurality of levels. Figure 3 shows an illustrative embodiment of this invention in which the nesting of the data containers occurs at 6 levels. The container segments 32a and 32b, which are identified by the rectangular boxes identified by these numerals, are the data containers at the highest level of the nested structure shown in Figure 3; this highest level is also known as level 1. There are no containers nested within the data container 32a. However, there are a number of data containers nested within the container 32b; in particular, there are 3 data containers 34a, 34b and 34c, which are all level 2 containers and are nested within the level 1 container
32b. Further, there are 2 level 3 data containers 40a and 40b which are nested within the level 2 data container 34b. In turn, there is 1 level 4 container 42, which is nested within the level 3 container 40 b. Still further, there are 3 level 5 containers 44a, 44b and 44c, which are nested within the level container 42. Finally in this illustrative embodiment, there are 2 level 6 containers 46a and 46b, which are nested within the level 5 container 44a.
As will be explained below, the document 20 (Figure 2), which is downloaded from one of the websites 14 (Figure la) , is subdivided or parsed into a plurality of data segments, which are identified by the numerals 132a and 132b as shown in Figure 7a. The parsing routine parses the nested data elements 32a-b, 34a-c, 42, 44a-c, etc., by identifying and counting the number of begin tags 22 and end tags 26 within the document 20 to determine the relative location of each of the data containers within the document page 20. This identify and count operation may be performed on the entire document 20 until all nested data containers 32a-b, 34a-c, 42, 44a-c, etc. within that document 20 have been identified and located.
The begin tag 22 and end 26 tag for each data container may also be marked with other types of codes known as content attributes that determine for example the graphics, the manner of text display, the structure of the text as a table, etc.
Container relationships similar to those described above may also be found in most existing documents created by programs like Microsoft Word™, Microsoft Excel™, Microsoft Powerpoint™, Lotus Notes™, WordPerfect™, Adobe Acrobat™, etc., as well as existing database programs. As long as the document data are delimited according to some defined rules,
the present invention may be used to subdivide or parse the document 20 (Figure 2) into typically smaller data structures which are termed herein data segments. Capitalizing on the fact that interactive Internet software services produce documents organized in the container fashion, e.g., in HTML/XML format, the present invention may interpret the organization of data elements in these documents and may reorganize data elements dynamically at a graphical interface level for viewing.
Figure 4 shows the steps of the information retrieving and parsing operations of this invention. At step 60, the URL addresses for the websites 14 (Figure la) , where document 20 (Figure 2) of potential interest may be found, are retrieved to the computer system 12 (Figure la) . The addresses may be provided manually one at a time or automatically" in a canned file. Additionally, since some computer systems 12 (Fig. la) may be located behind Internet firewalls, an HTTP proxy may be used. For this reason, the inventive application may have the ability to configure such a proxy, so that all Internet activity may proceed through that proxy.
A determination is made at step 62, whether all of the needed data have been found. If retrieved documents 20 (Figure 2) do not contain the needed data segments, the process returns to step 60 for further document retrieval. If the documents 20 of interest have been found, the parsing of the retrieved documents commences at step 64 as shown in Figure 4. The detailed steps of parsing will be explained below with respect to Figure 5. Basically, step 60 parses or subdivides the selected document 20 (Figure 2) into a plurality data segments 132a-b (Figure 7a) . The number of the data segments may be increased as needed by the user (Figures 7b, 7c and 7d) .
After selecting the desired degree of granularity, the user in step 66 selects which data segments of the displayed document 20 (Figure 2) contain the data of interest and then saves a pointer to that segment so that its data may be retrieved later. In step 68, the user indicates whether there are further data segments to be identified either from the same website or perhaps another. If further data segments are to be identified, the process returns to step 60 and the document selection and parsing in steps 60, 62 and 64 are repeated until all of the desired data segments have been identified. If all the necessary data segments have been identified in step 68, the user saves the pointers or addresses to each of the selected data segments.
The detailed steps of the parsing process 64 (Figure 4) will now be explained in detail with respect to"Figure 5. Initially at step 70, data representing the document 20 (Figure 2) as retrieved from its website 14 (Figure la) is downloaded to the computer system 12 (Figure la) . The document data, as explained above, is a sequence of data elements, some of which are data content and others are embedded codes, and is shown in Figure 3 in a manner to illustrate the nesting structure of the data containers. At step 72, each data element is examined and the begin tags 22 and the end tags 26 are saved, while all other data content elements are discarded. The output of step 73 is illustrated in Figure 6a to show the sequence of the begin tags 22 and the end tags 26, where all data content 24 have been removed.
Each tag of this output is examined in Step 74 to determine whether the tag is a begin tag 22 and, if so, a node A and a corresponding branch of an object tree 89 is constructed as shown in Figure 6b for each begin tag 22 that is
so identified. The object tree 89 has a single root node that is identified as Al, where the building process begins. Next, step 78 extracts the data type from the begin tag 22 and, in step 80, applies a label to the node A that identifies the data type of that begin tag 22, i.e., whether it is an image, text, etc. tag. Thereafter the process returns to step 73 to examine the next data element.
If step 74 determines that the tag is an end tag 26, i.e., it is not a begin tag 22, step 86 determines whether the detected end tag 26 is the final end tag in the document 20 (Figure 2) . As shown in Figure 3, the final end tag 26 is the </TR> tag at the bottom of the Figure 3, which marks the end of the document data that represents the page document 20 (Figure 2) . If such a final end tag 26 is identified, step 88 terminates the construction of the object tree 89 (Figure 6b) . If step 86 decides that the end tag 26 is not the final end tag, step 82 traverses the object tree 89 one level or branch back towards the root node Al . There is only one path from any node A to the root node Al for the tree constructing process to return to the root node Al . After traversing back up the tree 89, the process returns to step 73 to examine the next data element. This parsing process 64 is repeated through steps 71 - 88, until each data element of the document data has been examined and step 88 has identified the final end tag 26. The final structure of the tree 89 that corresponds to the document 20 (Figure 2) is shown in Figure 6b.
Referring now to Figures 6a and b, the object tree constructing process 64 begins at the root node Al and initially detects the first begin tag <H1> 22 of the data container 32a, whereby the first branch connecting the root node Al to node A2 is added to the tree 89. Next, the process
64 detects the closing node </Hl> 26 of the data container 32a and moves back up the tree 89 from node A2 backwards to the root node Al . Constructing is carried out such that when a begin node 22 is detected, the process moves away from the root node Al and backwards toward the root node Al when an end tag 26 is detected. The process 64 next detects the first begin tag <TABLE> 22 of the next data container 32b and constructs a branch leading to a node A3. The begin node <TR> 22 of the data container 34a is detected next, whereby the branch to node A4 is constructed. Next, the first opening node <TH align = left> 22 of the nested data container 36a is detected, and the branch to node A7 is constructed. Next, the closing tag </TH> 26 of the data container 36a is detected and the constructing process moves back toward the root node Al to node A4. Next the begin tag <TD> 22 of the data container 36b is detected, whereby a branch to node A8 is added. Next, the end tag </TD> 26 of the data container 36b is detected, whereby the process moves backward to node A4. Next, the end tag <TR> 26 of the data container 34a is detected, and the process moves backward to the node A3.
The tree building process 64 continues in this manner until the process has constructed all of the nodes Al - A19 and the process 64 has returned to the root node Al, which occurs when the final return node </TABLE> 26 of the document 20 has been detected in step 88 of the process 64. As seen in Figure 6a, each data container may be identified by that node A, which the process 64 constructed upon detection of the first begin tag examined in that data container. The structure of the object tree 89 identifies each connection between adjacent data containers and the level of that data container in the nesting structure. As will be explained below the relative position of the first begin tag 22 of the data container 32b marks the
beginning of that data container and the structure of the nested data containers as indicated by the object tree 89 dictate the placement of its end tag 26 and thus the end of the data container 32a. Likewise, the beginning tag 22 of the remaining data containers mark the beginning and end of their respective data containers as identified by each of the nodes A2 - A19 (Figure 6b) . As will be explained below, the begin tags 22 will be used to mark the beginning and end of each data segment of a document 20, whereby the document 20 may be parsed or subdivided.
An alternative to this comprehensive approach to parsing may be a simple content stripping routine. Such a routine may simply find a data content element 24 (Figure 3) included between its begin tag 22 (Figure 3) and end tag 26 and strip that data content. In other words, a copy of document data without its data content but with all the tags 22, 26 (Figure 3) intact may be sufficient for the parsing process 64 (Figures 4 and 5) to examine and successfully parse. This approach although acceptable is not as thorough and comprehensive as the one described in conjunction with Figures 5, 6a and 6b, where additional information is collected and used by sequentially reading in and processing each element of document data.
Selection Of Data Segments
When all of the data containers 32a-b, 34a-c, 36a-b, 38a- b, 40a-b, 42, 44a-c, 46a-b, 48a-b, 50a-b (Figure 6) of the document 20 (Figure 2) are identified and parsed, the document 20 (Figure 7a-c) may be graphically displayed with each of these nested data containers shown upon the display 5, whereby the user may identify specific data of the downloaded document data and the size or granularity of the data segment encompassing the selected document data. The user may now
point, click, and drag any or all of selectable data segments shown on the display 5 (Figure 1) to build a presentation template. After choosing all of the needed data segments from all of the parsed documents 20, the process configures a target presentation template.
The document 20 shown in Figure 7a may be displayed on the display 5 to the user with each of its data segment 132a-b visually separated by lines 54a and b. These lines separate and delineate the document 20 into data segments 132a-b, i.e., line 54b delineates the data segment 132a from the data segment 132b. The lines 54a and 54b are generated in accordance with the respective position of the first begin tag <H1> 22 of the data container 32a and the first begin tag <TABLE> 22 of the date container 32b. It is also appreciated that the data segments 132a and 132b display the same data content as their related data containers 32a and 32b, respectively. Further as seen in Figure 6a, the data segments 132a and 132b display data from the same level of their data containers 32a and 32b, namely level 1. The presentation of the document 20 may be scrollable. Moreover, additional icons 56a may be superimposed by the display 5 on a particular data segment to indicate, for example, that the data segment 132b may be parsed or subdivided into further data segments. This is achieved purposefully so as not to inundate the user with the granularity of a display which may be too small and unnecessary. If the user desires to increase the granularity for example of data segment 132b, the user merely clicks on the icon 56a to cause the document 20 to be further divided, as shown in Figure 7b, into data segments 134a, 134b and 134c, which display content from the level 2 containers 34a, 34b and 34c. Similarly, the icon 56a may be again clicked to further parse the document 20 as shown in Figure 7c to further include the data segments 136a-b, 138a-b,
and 140a-b, which display data from the level 3 containers 36a- b, 38a-b and 40a-b. If the icon 56a is again clicked, the document 20 will be further subdivided to include as shown in Figure 7d segments 146a-b, 148a-b and 150a-b, which display data from the level 6 data containers 46a, 46b and 46c.
Additionally, where document data elements are found to use embedded logic, frames, and pointers to other documents, then those items may be activated, loaded and parsed as if they all came from the same document data. This may be achieved recursively until there is no more data to process.
For further discussion please consider, as shown in Figure 8a, document 90 having data segments 92 separated by lines 54. The document 90 is presented as a window in the inventive user interface 94, which may be shown on display 5 (Figure 1) . By a selection of a menu 96 of icons 98, a user may control which operations are called into service. For example, the user may click on any of an icon 100 to initiate the retrieving and parsing operations 60 and 64 described above, an icon 102 to initiate the compiling and building functions as will be described, and an icon 104 to initiate the distributing and opening of completed presentation templates as will be described, and an icon 106 to call the displaying and translating operations as will be described. All component parts of the invention may be included within the user interface 94, individually or in combination.
Presentation Template Builder After the compiling/building 102, icon is activated and all of the retrieved documents 20 have been parsed, each user desired data segment 92 may be selected with a mouse or a keyboard. Selecting the data segment places that data segment
and its related pointers, such as the address of the parent document 20 and a list of the begin tags 22 and tags 26 (Figure 6) from the start of the document data 20 (Figure 3) to the first begin tag 22 of the data segment comprising the data 5 container; these pointers are stored in the builder file and may be displayed in a builder window 110 (Figure 8b) .
The builder window 110 may be displayed within the user interface 94. That window 110 comprises data segments 92a 10 selected from the document 90 (Figure 8a) and the segment 92b selected from another document, not shown. Once data segments are displayed in the builder window 110, they may be moved to form a presentation template.
15 By activating the compile/build icon 102, the parsing step
_ 64 (Figure 2) is initiated. A user may pre-select the size of a presentation template array 112. Depending on how many data segments 92a-b are expected to be displayed within the formed presentation template. For example if the resultant
20 presentation template display will have four items, the appropriate size of the presentation template array 112 may be two boxes by two boxes. The presentation template array 112 shown in Figure 8b is four by four boxes and is able to accommodate 16 data segments. The individual boxes of the
25 presentation template array 112 may dynamically change shape and size to accommodate the required number of data segments 92a-b to be displayed therein. To build a presentation template, the user may simply click on a selected one of the data segments 92a-b and drag and drop the selected segment into 0 a desired presentation template array box 114. The letter identifying the object 116 will appear in the presentation template array box 114.
Figure 9a shows the progression of steps in the builder process of the invention. After all of the desired data objects are selected, step 120 selects the coordinate of each data segment's coordinates from the object tree 89 generated by the parsing process 64 (Figure 4). The data segment's coordinates comprise a target website 14, e.g., the URL address, and the path to the desired data segment in the object tree 89. The path comprises all begin tags 22 and end tags 26 starting from the first begin tag 22 in the document 20 to the begin tag of the selected data segment. Before this address information is saved at step 128, it is stored in a holding area in step 122, and the user ascertains that no rearrangement of the data segments is necessary at step 124. Otherwise data segments are rearranged at step 126 and the user acceptance is again sought at step 124.
Pointers to data segments are saved in one illustrative embodiment of this invention as a set or collection of records called Uniform Micro Resource Locators (UMRL) . As shown in Figure 9b, each pointer or UMRL 202 may contain elements listed below.
1) An address 204, such as the URL address for the website 14 (Figure la) where the document 20 (Figure 20) may be found.
2) An array or a string of integers 206, each integer referring to a unique container at each level in the object tree, described above in conjunction with Figure 6b. In the object tree shown in Figure 6b, containers are labeled at each branch from left to right with integers 1 A2, A4, A7, A9, All, A14, A16, A18, 2 A3, A5, A8 , A10, A12, A15, A17, A19, and 3 A6. Higher integers may be used where more container branches exist. The container A19 in the lower
right hand corner of the object tree 89 may be addressed with the set of integers (2 A3, 2 A5, 2 A10, 1 A13, 2 A15, and 2 A19) .
3) Screen display coordinates 208 (Figure 9b) for displaying the data segment. In one embodiment of the present invention these coordinates may be specified with X, Y coordinates, for example a screen column number for the X axis coordinate and a screen row number for the Y axis coordinate. In a different embodiment of the present invention these coordinates may be specified with the location and size of the data segment as it may appear on a computer screen, these coordinate having been defined when the data segment was positioned in the presentation template array 112 (Figure 8b) , where the location may be represented by coordinates (1,1) of the cell 114 (Figure "8b) within the array 112 (Figure 8b) .
4) The height and width attributes 210 (Figure 9b) of the data segment, attributes may be these retrieved during parsing of the document 20 (Figure 2) or user defined.
Optional authentication information may be necessary for accessing password protected documents requiring user authentication. As shown in Figure 9c, if an authentication method is used at a particular document associated with an UMRL 212, then information comprising of a username 214 and password 216 pair is saved as supplementary data fields. If the authentication method used requires a POST request, a command that may be given to a computer system so that it returns a particular input form to be filled out by the requestor, then information required to submit the POST request to authenticate the user at the host 218 may also be stored.
This completes the description of the construction of the presentation template data file. The resulting data file may now be delivered by any means available, i.e., a diskette, e- mail, Internet download, etc. to any intended user and loaded into the user's device. To execute the presentation template data file a user's device 220, as shown in Figure 10a, may comprise a bus 221 which is connected directly to each of a CPU 222, a memory 223, a video interface 226, and a communications interface 228. No additional storage, e.g., a disk storage 7 (Figure lb) , is required; therefore the invention may be utilized on devices such as digital phones, palm top devices, personal digital assistant (PDA) devices, and digital television's set top boxes, among others. Proxy services may be utilized for smaller digital appliances to facilitate the implementation of the invention.
Presentation Template Display
Figure 10b shows the process for displaying the presentation template formed according to this invention. At step 130, the presentation template or blueprint is loaded and individual data segments are extracted. At step 132, all information associated with each data segment is fed into the translator routine until all data segments are translated. Then at step 134, a dynamic view designed with the help of the builder section of the invention, where the presentation template array was constructed, is filled in with all of the found and retrieved data segments. The filled-in presentation template document is then displayed to the user, after which the process terminates at step 136.
The detailed steps of the translator process 132 are shown at Figure 11. There at step 152, the URL address of the
website 14 from which the document 20 and data segment's relative location in the parsed tree 89 is accepted. At step 154, the data segment's parent document 20 is retrieved, followed by a determination by an error routine at step 156 of whether the retrieved data segment is valid, non-existent, or whether different unrelated information now occupies the selected data segment's location in the retrieved parent document 20. If it is determined that the retrieved data segment is not the intended data, an error message is generated at step 158 and the erroneous data segment will not be displayed. If step 160 determines that the data segment is valid, then step 160 retrieves its data in accordance with saved data segment attributes .
The error checking step 156 may be performed for each data segment individually, or the validity of all data segments of a loaded presentation template may be examined at the same time. The routine shown in Figure 12 may load data segments' addresses into a buffer or a set of registers at step 162. An iterative loop may be initialized at step 164, and each data segment may be processed one at a time until all of the data segments have been examined and the process returns to routine 132 (Figure 11) at step 174. At step 166 a determination is made as to whether the requested document 20 still exists at a given website 14, which matches the URL saved by the presentation template. If it does not, the requested data segment is no longer valid. In such a case, step 168 generates an error message and the process returns to the translator routine 132 (Figure 11) .
On the other hand if the requested document is found, the document is read in at step 170 and its contents are parsed in the same manner described above in connection with Figure 5 at
step 172. Furthermore at step 172, the newly calculated object tree 89 and those trees saved in the presentation template are compared. If the tree structures match, the data segments are accepted as valid, and the process returns to the top of the loop at step 164 to continue checking addresses until all data segments are tested. If however the tree structures 89 do not match, the data segment is no longer deemed valid. In such case, step 168 generates an error message and the process returns to routine 132 (Figure 11) . In a further embodiment of this invention, it is contemplated that the comparison software may be able to detect whether a newly generated tree that differs from the stored tree may nevertheless by acceptable dependent on the nature and degree of the differences of these tree structures.
When the display process of Figure 10b is started, a list of available presentation templates may be displayed to the user, who may be asked to chose from among these presentation templates. The name of each presentation template may be the same name that was given when the presentation template was created and saved. Clicking on any one presentation template may cause the inventive application to load the presentation template into memory and to begin retrieving and parsing these documents. After all of the documents referenced in the presentation template are retrieved and parsed, selected data segments from each of these documents may be copied and displayed at coordinates and with attributes described in the presentation template. The displayed content itself is not saved in the presentation template of this invention, rather the data content is retrieved from the websites on as needed basis which allows for any content updates to be reflected.
Figure 13 shows a presentation template display 180 which
is a display of rearranged data found in the document 90 (Figure 8a) .
Time Slicing Another embodiment of the present invention may include a time slicing feature. This feature may be used with data segments as described above, as well as with video broadcast content. With time slicing, a plurality of data segments 92a-b (Figure 8b) are entered into each presentation template box 114 (Figure 8b) . Utilizing simple programming techniques, each entered data segment may be displayed for a certain time duration in a round robin or any other order according to the user's preferences. Time slicing for video broadcast content may be performed by substituting begin tags with start time and end tags with end times and by displaying the video segments accordingly.
Uses
The present invention may be used to customize and to individualize presentations and functionality of information services available through the public networks and subscription based network services such as cable television. Specifically, these applications may include empowering stock brokers, real estate agents, travel agents, and other info-media based businesses to build presentation templates for their customers throughout the customer care continuum, i.e., the find-it, qualify-it, compare-it, shop-it, buy-it, deliver-it and service-it stages of the purchasing process.
Consumer applications may allow consumers to build virtual compilations of information such as the presentation templates described above to share with other consumers thus creating a community aspect of information sharing. An example of this
may be enabling users to aggregate a virtual CD by assembling links and song titles of MP3 files on the Internet. The chosen song titles are stored in the presentation template together with a metaphoric CD player. Such a template may be sent to a receiving party, who may then view the aggregated song links and then download and play the intended audio segments from their Internet-connected devices or offload the presentation template to a MP3 player for later playback.
Presentation template files may contain username/password pairs for securing presentation templates from unauthorized use. These user names and passwords should be saved in the presentation templates in an encrypted format. When the presentation template is saved, the user may be asked for a password. This password may be used to generate the Triple
Data Encryption Standard (DES) key that is used "for encryption and must be remembered for the time when presentation templates are reloaded in the future. If the presentation template is sent to another user, then the password must also be provided to that person. The user may also have the option of saving an unencrypted presentation template so that no password may be required.
Additionally, some Internet and non-Internet documents may be secured with a user name/password pair. To address such a documents either a hyper text transport protocol (http) authentication or a custom mechanism that utilizes Point of Sales Terminal (POST) requests from the user's browser may be used. In either situation, the user must provide needed user names and passwords to be stored with the presentation template.
While the invention has been particularly shown and
described with respect to illustrative and preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention that should be limited only by the scope of the appended claims.