CA2410747C

CA2410747C - System and method for saving browsed data

Info

Publication number: CA2410747C
Application number: CA2410747A
Authority: CA
Inventors: Aruna Rohra Suda; Suresh Jeyachandran; Prem Anand Joseph
Original assignee: Saora KK
Current assignee: Saora KK
Priority date: 2000-05-29
Filing date: 2001-05-25
Publication date: 2011-01-04
Anticipated expiration: 2021-05-25
Also published as: US7822735B2; EP1407381A2; US20020078197A1; ATE386302T1; AU2001258688B2; EP1407381B1; AU5868801A; DE60132821T2; WO2001093071A3; CA2410747A1; DE60132821D1; US20020035563A1; WO2001093071A2

Abstract

A system saves browsed data in a database in response to a user request by assigning a predetermined index to the data, wherein the user is not requested for any index. The system sorts indices of the data in the database and displays the sorted indices, then the system retrieves, in response to a selection of an index from the displayed indices by a user, the data corresponding to the selected index from the database. Accordingly if a user wants to save a data currently browsed, he can make store the data in the database easily only by issuing an instruction to save without specifying any index.

Description

SYSTEM AND METHOD FOR SAVING BROWSED DATA
CLAIM FOR PRIORITY
This application claims priority from Application No. 2000-197293, filed on May 29, 2000 in Japan and Application No. 2000-314641, filed on October 16, 2000 in Japan.
FIELD
A system and method for saving acquired data, and more particularly a system and method for saving acquired data browsed in a client application, such as browsed by an Internet browser.
BACKGROUND
A conventional computer can access and display data in an Internet using a software called browser. The conventional computer also can open a file application and store data in a file.
The data on the browser can be transported to a word processing software or the like. Then a user can add an annotation to the browsed data on the word processing software or the like. The conventional computer can also send the browsed data as it is or with adding an annotation to other computer.
In the above conventional computer, however, the user must specify a folder and a file name for saving the browsed data. The user must open respective applications to save, make an annotation, and send the data. Therefore, the user has to perform complex operations to save the browsed data, make an annotation therein, and send the browsed or annotated data to other computer.
SUMMARY
According to certain embodiments of the present invention, the present invention provides a system and method to save data, which a user wants to do with a simple operation.
According to one of the embodiments, the present invention relates to a data processing system comprising data acquisition means for acquiring data;
determination means for determining whether or not a user requests to save the acquired data; indexing means for assigning a predetermined index to the data CONFIRMATION COPY

_2_ requested to save, without inputting any index; and saving means for saving the requested data with the assigned index in a predetermined storage unit.
According to another embodiment, the present invention relates to a data processing method comprising a data acquisition step of acquiring data; a determination step of determining whether or not a user requests to save the acquired data; an indexing step of assigning a predetermined index to the data requested to save, without inputting any index; and a saving step of saving the requested data with the assigned index in a predetermined storage unit.
According to still another embodiment, the present invention relates to a computer-executable program for controlling a computer to perform data processing, said program comprising codes for causing the computer to perform a data acquisition step of acquiring data; a determination step of determining whether or not a user requests to save the acquired data; an indexing step of assigning a predetermined index to the data requested to save, without inputting any index; and a saving step of saving the requested data with the assigned index in a predetermined storage unit.
Other features and advantages of the present invention will be apparent from the following description taken in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.
BRIEF DESCRIPTION OF THE FIGURES
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.
Fig. 1 is a block diagram illustrating the hardware configuration according to an embodiment of the present invention.
Fig. 2 shows the functional block diagram of information processing system embodying the present invention.
Fig. 3 shows the functional block diagram of information browsing system embodying the present invention.
Fig. 4 is a flowchart of the main procedural steps of this embodiment.

Fig. 5 is a flowchart of INITIALIZE procedure.
Fig. 6 is a flowchart of MAIN-PROCESSOR.
Fig. 7 is a flowchart of the procedural steps of UserAction.
Fig. 8 is a flowchart of the procedural steps of CheckExisting().
Fig. 9 is a flowchart of the procedural steps of Annotate().
Fig. 10 is a flowchart of the procedural steps of Extract().
Fig. 11 is a flowchart of the procedural steps of Mgmt().
Fig. 12 is a flowchart of the procedural steps of ShowSession.
Fig. 13 is a flowchart that procedural steps of ShowLinks.
Fig. 14 is a flowchart of the procedural steps of ExecuteAction.
Fig. 15 is a flowchart of the procedural steps of SaveContents.
Fig. 16 is a flowchart of the procedural steps of WebFetch.
Fig. 17 is a flowchart of the procedural steps of SendContents.
Fig. 18 is a flowchart of the procedural steps of TERMINATE.
Figs. 19 and 20 show examples of the knowledge structures in the knowledge base.
Figs. 21 and 22 show examples content of the knowledge base.
Fig. 23 shows an example content of the Domain knowledge base.
Fig. 24 shows an example User Interface of this embodiment.
Fig. 25 shows an example User Interface of Save UI.
Fig. 26 shows example results of the knowledge structures.
Fig. 27 shows an example HTML text obtained from the browser.
Fig. 28 shows example results of the knowledge structures.
Fig. 29 shows example modified HTML text.
Fig. 30 shows example results of the knowledge structures.
Fig. 31 shows an example User Interface of Hold UI.
Fig. 32 shows an example User Interface of the Annotation UI.
Fig. 33 shows example modified HTML text after user has performed annotations.
Fig. 34 shows an example User Interface of Send UI.
Fig. 35 shows an example User Interface of Extract Data UI.

Fig. 36 shows example results of knowledge structures.
Fig. 37 shows an example User Interface of Session UI.
Figs. 38, 39, and 40 show examples User Tilterface of Get All Links UI.
Fig. 41 shows an example Retrieve or Find UI.
Fig. 42 shows an example of Properties or Attributes UI.
Fig. 43 shows an example Retrieve Extracted Data or Find UI.
Fig. 44 shows an example Address book UI.
Fig. 4S shows an example of Properties or Attributes UI.
Figs. 46 to SO show some examples of User Settings UI.
Fig. S 1 is a flowchart of the procedural steps to see if any system task needs to be executed.
Fig. S2 is a flowchart of the procedural steps of RemoveExpired.
Fig. S3 is a flowchart of the procedural steps of CheckUpdate.
1 S Fig. S4 is a flowchart of the procedural steps of Sort by keywords.
Fig. SS is a flowchart of the procedural steps of ShowTreeView.
Fig. S6 is a flowchart of the procedural steps of ProcessLeafAction.
Fig. S7 is a flowchart of the procedural steps of ProcessNodeAction.
Fig. S8 is a flowchart of the procedural steps of Sort by Domain.
Fig. 59 is a flowchart of the procedural steps of Sort by Organization.
Fig. 60 is a flowchart of the procedural steps of For Each Session, Sort KPTAction by Time.
Fig. 61 is a flowchart of the procedural steps of GetPreviousYearNodes.
2S Fig. 62 is a flowchart of the procedural steps of GetB eforeCurrMonthNodes.
Fig. 63 is a flowchart of the procedural steps of GetbeforeCurrWeekNodes.
Fig. 64 is a flowchart of the procedural steps of GetCurrWeekNodes.
Fig. 6S is a flowchart of the procedural steps of steps S 1 S 10, S 1 S 12 SaveFileContents.

Fig. 66 is a flowchart of the procedural steps of FilIKPTAction.
Figs. 67 and 68 are flowcharts for processing the retrieve conditions and to fetch the appropriate information.
Fig. 69 shows example rules for determining the organization indices for a URL.
Fig. 70 shows example rules for determining the domain indices for a URL.
Fig. 71 shows a Client-Server type implementation.
Fig. 72 is a flowchart of the procedural steps of INITIALIZE
processing of a client.
Fig. 73 is a flowchart of the main procedural steps of server.
Fig. 74 is a flowchart of INITIALIZE SERVER procedure.
Fig. 75 is a flowchart of the procedural steps of MAIN-PROCESSOR SERVER procedure.
Fig. 76 is a flowchart of TERMINATE SERVER procedure.
Fig. 77 shows a File Server type implementation.
Fig. 78 shows a Distributed Clients type implementation.
Fig. 79 shows another example of Client-Server type implementation.
Fig. 80 shows an example implementation in which the server acts as a proxy server.
Fig. 81 shows an example web server based implementation.
Fig. 82 shows an example mixed implementation of a File Server implementation and a Distributed Client implementation.
Fig. 83 shows another example of implementation.
Fig. 84 shows another example of compounded implementation.
Fig.85 displays an example of Show All links User Interface for Distributed client implementation.
Fig.86 displays an example of Show All links User Interface for Client Server implementation.
Figs.87 and 88 display other examples of Show all links User Interface for external Database implementation.
Fig. 89 displays an example of Session User Interface for external Database implementation.
Fig. 90 displays another example of Show all links User Interface for local web information implementation.
Fig. 91 displays another example of Session User Interface for File System implementation.

_7_ DETAILED DESCRIPTION
With reference to the figures, various embodiments of the method, system and apparatus for discovering, establishing and managing network connectivity across disparate networks will now be described in greater detail. It is to be understood that the tasks shown in the figures and described in this description can be sequenced in many different orders to achieve the desired result. The order or sequence of tasks illustrated in the figures is merely intended to be exemplary of the concepts defined herein.
Fig.l is a block diagram illustrating the hardware configuration according to an embodiment of the present invention. In this figure, a central processing unit (CPU) 101 is operative to perform operations for various processing and make a logical decision or the like and further controls each composing element connected to a bus 107.
A RAM 102 is used to temporarily store variables and intermediate data generated during the processing. A program from an external source may be loaded into the RAM 102. A ROM 103 is used to store programs, which correspond to individual flowcharts that will be described later and which are to be executed by the CPU 101, and fixed data.
A keyboard (KB) 104 is used for inputting data and an instruction by a user. A mouse or other input devices may be used with the keyboard 104.
Display 105 displays data and a hard disk drive (HHD) stores data of a database, a program, and the like.
The bus 107 is used to transfer an address signal indicating a composing element to be controlled by the CPU 101, a control signal used for controlling each composing element and data to be exchanged between the composing equipment.
Fig. 2 shows the functional block diagram of information processing system embodying the present invention. Browser 201 is used for information browsing of the Web. Filing system 202 is for filing and managing files.
Document Management System 203 is for managing documents. Information Management System 204 is for managing information other than documents. KPT System _g_ interacts and acts as a controlling system as explained in detail in this embodiment to Browser 201, Filing System 202, Document Management System 203 and Information Management System 204. Knowledge Base Management 206, is the management of knowledge accessed/stored frorn/to the Database 206.
Fig. 3 shows the functional block diagram of information browsing system embodying the present invention. The information on the Internet 301 is browsed using multiple browsers 302, 303 simultaneously and as explained in this embodiment, KPT System 205 handles and processes them separately.
Fig. 4 is a flowchart of the main procedural steps of this embodiment.
The following description is for an example system, which connects to the Internet and allows browsing, annotating, extracting and saving of the information. In step 5401, initialization processes to connect to the Internet are executed. In step 5402, main function processing browsing, annotating, saving etc. of this embodiment is performed. In step 5403, terminate or clean-up processing is executed.
Fig. 5 is a flowchart of INITIALIZE procedure of step 5401. In step 5501 a check is made to determine if the browser needs to be instantiated or not. If browser is not instantiated, it is instantiated in step 5502. In step 5503, a new session is created. In step 5504, the knowledge base is updated. The main UI
of this embodiment is displayed in step 5505 and the process ends.
Fig. 6 is a flowchart of MAIN-PROCESSOR of step 5402. In step 5601, a check is made to determine if the browser was instantiated or not. If so, a new session is created in step 5602 and the process proceeds to step 5605, wherein the knowledge base is updated. If not, a check is made in step 5603 to determine if the browser was terminated or ended. If so, the session associated with the browser is ended and proceeds to step 5605. If not, a check is made in step 5606 to determine if an action was performed to end the system. If so, all the current tasks are terminated in step 5607 and the process returns.
If not, a check is made in step 5608 to determine if the user is navigating to a new URL. If so, a check is made in step 5609 to confirm with the user that the current task should be terminated. If not, the process proceeds to step 5610, where the navigation is aborted and the process continues to step 5601.
If the _9_ current task is to be ended in step 5609, step 5611 is executed wherein, the previous task is terminated and then a new task is created. In step 5612, the knowledge structures KPTAction and KPTDocument are created.
In step 5613, the URL and the keywords are obtained from the Browser. A check is made in step 5614 to determine if the URL data already exists in the knowledge base. If so, all the existing data for the current URL is procured from the knowledge base in step 5615 and moves to step 5616, where a check is made to determine if it is a RetrievedURL i.e., the user is trying to view the contents of an already stored page. If so, step 5617 is executed to get the RetrieveUI
message and control goes to S6I8. If URL data does not already exist in step 5614, step 5618 is executed to display the keywords, other acquired data from browser like the URL, page title etc... and other existing data if any from the knowledge base like Keep As, validity period etc. . . and the process proceeds to step 5601.
In step 5608, if the user is not moving to a new URL, a check is made in step 5619 to determine .if any SystemTask ActL needs to be executed.
If so, step 5622 ExecuteAction (ActL) is executed and the control moves to step 5605 to update the knowledge base. If not, a check is made in step 5620 to determine if any User Operation was performed. If not, step 5605 is executed, otherwise in step 5621, the HTML text is obtained from the browser and the KPTAction and KPTDocument structures created in step 5612 are updated and ExecuteAction(ActL) for the UserAction is executed in step 5622 and the process moves to step 5605 to update the knowledge base.
For example, when the browser 201 displays an HTML page as shown in Fig. 27, the keywords embedded in the Meta Name fag (i.e., KPT, Yokohama), which are not normally displayed by the browser are extracted and displayed in the keywords field, as shown in Fig. 24.
Fig. 7 is a flowchart of the procedural steps of 5620 UserAction. A
check is first made in step 5701 to set Act equal to the User operation performed by user and to determine if Act is equal to NULL. If so, the process returns false. If it is not NULL, the process proceeds to step 5702, a check is made to determine whether Act is Create New. If so, the process proceeds to step 5704. If not, the process proceeds to step 5703, a check is made to determine whether Act is Quick Save.
If so, the process proceeds to step 5704. If not, a check is made in step 5705 to determine whether Act is Automatic Save. If so, the process proceeds to step 5704.
If not, a check is made in step 5706 to determine whether Act is Save. If Act is Save, Save UI, an example of which is shown in Fig. 25, is displayed in step and proceeds to step 5704. If not, a check is made in step 5708 to determine if the Act is Hold. If so, Hold UI, an example of which is shown in Fig. 31 is displayed in step 5709 and proceeds to step 5704. In step 5704, a check is made to determine if the information being saved or held is already exists using CheckExisting(), which is explained in detail later and if so, proceeds to step 5720, otherwise return false.
In step 5708, if Act is not Hold, a check is made in step 5710 to determine if the Act is Send. If so, Send UI, an example of which is shown in Fig.
34, is displayed in step S71 l and the recipients (To, CC) information, Subject, Contents and/or the like are obtained from the user in step 5712 and proceeds to step 5720. If not, a check is made in step 5713 to determine if Act is Annotate. If so, Annotate UI, an example of which is shown in Fig. 32 is displayed in step 5714 and the actual Annotations executed using Annotate(), which is explained in detail later, in step 5715 and proceeds to step 5720. If not, a check is made in step 5716 to determine if Act is Extract.
If so, Extract UI; an example of which is shown in Fig. 35, is displayed in step 5717 and the actual Extract information executed using Extract(), which is explained in detail later, in step 5718 and proceeds to step 5720. If not, Mgmt(), which is explained in detail later is executed in step 5719 and proceeds to step 5720. In step 5720, createKS() is executed to create the associated knowledge structures, which are explained in detail later and the process returns true.
Fig. 8 is a flowchart of the procedural steps of 5704, CheckExisting() of this embodiment to check if the information already exists in the knowledge base or not. In step 801, the values of Keep As, Validity Range etc.. . are either obtained from the user or from the system settings. In step 5802, a check is made to determine whether the URL already exists. If URL does not exist, the process proceeds to step 5803 where Modifystatus is set to SaveAsNewAction is set to and returns true. If URL exists, a check is made in step 5804 to determine if the information needs to be over-written (i.e., update or modify the previous information). This is done either by asking the user, whether he would like to overwrite the existing information, save as new do not save or based on the user settings as shown in Fig. 48. If so, in step 5805, ModifyStatus is set to OverWriteExisting and the process returns true. If not, a check is made in step 8806 to determine if the information needs to be saved as new, (i.e., without modifying the existing information, save the current information as a separate entity).
If so, ModifyStatus is set to saveAsNewAction and the process returns true. If not, the process returns false.
Fig. 9 is a flowchart of the procedural steps of 5715 Annotate() of this embodiment and Fig. 32 shows an example user interface for Annotating a web page currently being browsed. In step 5901, the user-performed operation is set to Act. A check is made in step 5902 to determine if Act is Add Note. If so, the user specified memo/note is added to the selected place in step 5903 and goes to step 5904. If not, a check is made in step 5906 to determine if the Act is Footnote. If so, the footnote number is created based on a sequence and the footnote number is added to the selected place in the page and the actual contents of the footnote are added to the end of the page in form of a table and proceeds to step 5904. The notes added to the page are added based on user settings, example of which is shown in Fig. 49, to set the "annotation demarkers", "default annotation text", the color of annotation etc. The annotations are added as standard HTML tags and the results of the actual annotation for example text in Fig. 27 are shown in Fig. 33. Also, as can be seen in Fig. 32, the annotation to be added "Express Train does not Stop", is prepared using the default annotation text "My Comments" and enclosed with the annotation demarkers []. This is done to enable later for the user and/or the system to distinguish the user annotations from the actual or original HTML text. If Act is not Footnote in step 5906, a check is made in step 5908 to determine if the Act is Highlight. If so, a Font tag <font bgcolor = .. .> is added around the selected text with the background color set to the selected color in step 5909 and proceeds to step 5904. If not, a check is made in step 5910 to determine if the Act is Change text color. If so, a Font tag <font color=...> is added around the selected text with the foreground color set to the selected color in step S91 l and proceeds to step 5904. If not, a check is made in step 5912 to determine if Act is Delete. If so, the tag is modified to <visible = false> to hide the selected part of the text in step 5913 and proceeds to step 5904. If not, a check is made in step 5914 to determine if Act is Undo. If so, the last performed annotation is undone and proceeds to step 5904. If not, a check is made in step 5916 to determine if Act is UndoAll. If so, all the annotation performed by the user on this page during this session are removed and proceeds to step 5904. If not the function returns. In step 5904, the modified HTML
tag page is passed back to the browser, which will render and update the UI in step 5905 and return to step 5901. If Act is none of the ones specified in the flowchart, the function returns.
Fig. 10 is a flowchart of the procedural steps of 5718, Extract() of this embodiment. In step S 1001, an instance of the knowledge structure for person -KPTPerson is created. In step S 1002, the User operation is set to Act. An example User interface to describe some of the action is shown in Fig. 35. First a check is made to determine the type of Act (i.e., if Keep As, Name, Email, Phone, Fax, Notes) was input by the user (steps S 1003, S 100751010). This action can be performed in various ways, like first selecting the text to be extracted and pressing a predefine button, as shown in Fig. 35, or dragging and dropping the text to be extracted to the appropriate field or by right clicking on the selected text and specifying it to be the extracted data. If so, the KPTPerson knowledge structure is modified appropriately in step S 1004 and the UI gets updated in step S 1005 and the process returns to S 1002. If the Act is Clear All (step S 1011), all the fields are cleared in step S 1012 and process proceeds to S 1004. If the Act is Save (step S 1013), a new action KPTAction is created of type Extract as shown in Fig. 36 and the KPTPerson is filled as associate object and the process returns.
Fig. 11 is a flowchart of the procedural steps of 5719 Mgmt() of this embodiment. In step Sl 101, Act is set to the user-performed operation. In step 51102, a check is made to determine if Act is NULL. If so, the process returns. If not, a check is made in step 51103 to determine if Act is Show Sessions. If so, ShowSession() as explained later is executed in step Sl 104 and the process returns.
If not, a check is made in step S 1105 to determine if the Act is Show Links.
If so, ShowLinks() as explained later is executed in step S 1106 and the process returns. If not, a check is made in step S 1107 to determine whether Act is Retrieve pages. If Act is to retrieve a page, the process proceeds to step S 1108 where RetrieveUI is displayed, example of which is shown in Fig. 41. If not, a check is made in step S 1109 to determine if Act is Retrieve extracted data. If so, Show Retrieve Extracted data UI is displayed, an example of which is shown in Fig. 43. If not, a check is made in step S 1111 to determine if Act is Show address book. If so, Show Address book UI is displayed, an example of which is shown in Fig. 44 and the process returns.
Fig. 12 is a flowchart of the procedural steps of Sl 104, ShowSession of this embodiment. In step 51201, all the KPTAction and the associated KPTDocument are got from Knowledge Base. In step S 1202, KPTAction is sorted for, each session by time as explained in detail later, in Fig. 60. In step S
1203, Session UI is displayed, an example of which is shown in Fig. 37 and the process returns.
Fig. 13 is a flowchart that procedural steps of 51106, ShowLinks of this embodiment. In step 51301, all the KPTAction and the associated KPTDocument are got from knowledge base. In step 51302, a check ismade to determine if the Sort Item is equal to Organizations. If so, the information is sorted by Organization, as explained in detail later in Fig. 59, in step S 1303 and proceeds to 51304, where it is displayed, an example of which is shown in Fig. 38. If not, a check is made in step 51305 to determine if the sorting is by Domains. If so, the information is sorted by Domain, as explained in detail later in Fig. 58, in step S 1306 and proceeds to step S 1304, where it is displayed, an example of which is shown in Fig. 39. If not, the information is sorted by Keywords, as explained in detail later in Fig. 54, in step 51307 and proceeds to step 51304, where it is displayed, an example of which is shown in Fig. 40 and the process returns.
Fig. 14 is a flowchart of the procedural steps of 5622, ExecuteAction of this embodiment. In step 51401, the next Act is got from the ActList. In step S 1402, a check is made to determine if Act exists. If not, the process returns.
Otherwise, in step S 1403 inference is made using the knowledge base to complete the Act. A check is made in steps 5140451408 to determine if Act is Quick Save or Save or Hold or Automatic Save and if either one of them is true, step 51405, SaveContents() as explained later in Fig. 15. is executed and goes to step 51413.
Otherwise a check is made in step S 1409 to determine if Act is send. If so, SendContents(), as explained later in Fig. 17 is executed and goes to step 51413. If not, a check is made in step S 1411 to check if Act is Extract. If so, the KPTAction . and the corresponding KPTPerson are added to the knowledge base in step .10 and in step S 1413 the knowledge base is updated and the process returns to step S 1401 to fetch the next action from the ActList, till there are no more action left to be processed, at which stage the process returns.
Fig. 15 is a flowchart of the procedural steps of SaveContents in step . S 1405 of this embodiment. A check is made in step S 1501 to determine if it is a .SaveLink only operation. If so, process proceeds to step 51505. Otherwise, a check is made to determine if it is a SavePage contents operation in step 51502. If so, Page PLUS is set to true in step 51504. In either case, step 51503, WebFetch() is executed, which is explained in detail later in Fig. 16, in step S 1503. In step S 1505, a check is made to determine if ModifyStatus is saveAsNewAction or not. If so, indices of KPTAction and the associated KPTDocument is determined from Knowledge Base in step S 1509 and SaveFileContents() is executed as explained in Fig.65, in step SISOI. The KPTAction and KPTPerson are added to Knowledge Base in step 51506 and the process returns. If ModifyStatus is not _ saveAsNewAction, check is made in step S 1507 to determine if it is OverWriteExisiting. If not the process returns, otherwise, in step S1511 indices of KPTAction and the associated KPTDocument is determined from Knowledge Base in step 5151 l and SaveFileContents() is executed as explained in Fig.65, in step 51502. The KPTAction and KPTPerson are updated in the Knowledge Base in step 51508 and the process returns.
Fig. 16 is a flowchart of the procedural steps of WebFetch in step 51504 of this embodiment. In step 51601, HTML document obtained from the browser is opened. In step S 1602, next tag is got. In step S 1603, a check is made to determine if the end of file has been reached. If so the process returns. If not, a check is made to determine if the tag is for ail embedded image, frame etc. in step S 1604. If so, step S 1605 is executed. If not, a check is made in step S 1609 to determine if PagePLUS is true and the Tag type is of LINK. If not the process returns back to step S 1602 to fetch the next tag. Otherwise, step S 1605 is executed in which a check is made to see if the contents (i.e., embedded images etc.) already exist in our knowledge base and they are up to date in step 51605. If so, the HTML
tag is edited in step S 1606 to change the absolute or original path to the local path. of the system where the file exists and process returns to step S 1602. If not, a check is made to determine if the file to be fetched is a local file in step S 1610. If so, the file contents are just copied, using a simple file copy command in step 51611, otherwise the contents are downloaded from the Internet in step S 1607. In either case step S 1608 is executed, wherein the knowledge base is modified to update the information downloaded etc. and process returns to step 51602 to fetch the next tag in the HTML document. The process continues till end of file is reached at which instant the process returns.
Fig. 17 is a flowchart of the procedural steps of SendContents in step S 1410 of this embodiment. In step S 1701, a check is made whether the contents to be sent are SendLink only. If so, a message is created with the given Link in step S 1702 and proceeds to step S 1707. If not so, a check is made to determine if the contents to be sent are SendPage (I.e., send the HTML page including the embedded images etc.), in step S 1703. If not so, a message for only top HTML
is created and proceeds to step S 1707. Otherwise, Webfetch() is executed as explained in Fig.16 in step S 1705. In step S 1707, the created message is sent and the knowledge structures KPTAction and KPTDocument are added to knowledge base in step S 1708 and the process returns.
Fig. 18 is a flowchart of the procedural steps of TERMINATE of step 5403 of this embodiment. In step S 1801, the UI on display are closed. In step S 1802, all the current sessions are ended. In step S 1803, Knowledge base is updated. A check is made in step S 1804 to determine if browser needs to be ended or terminated. If so, the browser will be terminated in step S 1805 and the process ends.
Fig. 19 shows an example of the knowledge structures in the knowledge base. (a), (b), (c) are the knowledge structure definitions for I~PTConcept, I~I'TPerson and KPTDocument respectively.
Fig. 20 shows an example of the knowledge structures in the knowledge base. (a), (b) are the knowledge structure definitions for KPTAction and KPTContent respectively.
Fig. 21 shows an example content of the knowledge base. (a), (b) are . the contents of the knowledge base for KPTDocument and KPTAction respectively.
Fig. 22 shows an example content of the knowledge base. (a), (b) are the contents of the knowledge base for KPTPerson and KPTContent respectively.
Fig. 23 shows an example content of the Domain knowledge base.
Fig. 24 shows an example User Interface of one embodiment. The keywords obtained in step 5612 - KPT, Yokohama are displayed in the UI as shown in step 5618.
Fig. 25 shows an example User Interface of Save UI displayed in step 5707, when Save is selected in Fig. 24, to get the validity or the period of time for which the contents needs to be saved.
Fig. 26 shows example results of the knowledge structures (a), (b) created in Step 5612 and for KPTAction and KPTDocument respectively.
Fig. 27 shows an example HTML text obtained from the browser. In step 5621, the system obtains the HTML text like shown in this figure and in steps 51604 to.S1608, downloads the embedded files, which happens to be image files with '.gif extension for the example HTML file shown.
Fig. 28 shows example results of the knowledge structures. These knowledge structures are created and updated to knowledge base in step S 1608 for the example HTML text shown in Fig. 27.
Fig. 29 shows example modified HTML text. The original HTML
text obtained from the browser, shown in Fig. 27 is modified by the system in step S 1606 and the resultant HTML text is shown in this figure. As can be seen from this figure, the embedded links are modified to reflect the path where the system stores the embedded contents.
Fig. 30 shows example results of the knowledge structures created in step 51506 of this embodiment.
Fig. 31 shows an example User Interface of Hold UI, displayed in step 5709, when Hold is selected in Fig. 24, to get the validity or the period of time for which the contents needs to be held by the system.
Fig. 32 shows an example User Interface of the Annotation UI
displayed in step 5714, when Annotation is selected to annotate, edit the HTML
text from within the browser, without opening a separate window or application for the same purpose.
Fig. 33 shows example modified HTML text after user has performed annotations. The example shows the modified HTML text after adding notes directly on to the page in step 5903. As can be seen from the figure, no special 1 S or custom tags are created, only standard HTML tags are added and hence, the contents of the annotations can be viewed using any standard browser.
Fig. 34 shows an example User Interface of Send UI, displayed in step 5711, when Send is selected in Fig. 24, to get the recipients - "To", "Cc"
"Subject" etc... As can be seen from the figure, the annotated page in Fig. 33 can be sent to any recipient from within the browser and since no special or custom tags are added for annotations, the contents of the page can be viewed by the recipient using any standard browser Fig. 35 shows an example User Tnterface of Extract Data UI, displayed in step 5717, when Extract is selected in Fig. 24, to allow the extraction of specified data.
Fig. 36 shows example results of knowledge structures created in step 51412 to be updated to the knowledge base.
Fig. 37 shows an example User Interface of Session UI. In step S 1202, for each session the KPTAction is sorted by Time and the result is as shown in this figure. Also, as can be seen from the figure, being a Retrieved URL, the RetrieveUI message is obtained in step 5617 and displayed in S61 S.

Fig. 38 shows an example User Interface of Get All Links UI. In step 51303, the links are sorted by Organization and the resultant UI is displayed in step 51304 as shown. As can be seen from the figure, if a content has subdomains (e.g., sales.saora.com) then it will appear in multiple places below each of the organization nodes, such as sales, saora, etc.
Fig. 39 shows an example User Interface of Get All Links UI. In step S 1306, the links are sorted by Domains and the resultant UI displayed in step as shown.
Fig. 40 shows an example User Interface of Get All Links UI. In step S 1307, the links are sorted by Keywords and the resultant UI displayed in step S 1304 as shown. As can be seen from the figure, if a content has multiple keywords then it will appear in multiple places below each of the keyword nodes.
Fig. 41 shows an example Retrieve or Find UI, which is displayed in step S 1108.
Fig. 42 shows an example Properties or Attributes UI of an entry selected in Fig. 41.
Fig. 43 shows an example Retrieve Extracted Data or Find UI, which is displayed in step S 1110.
Fig. 44 shows an example Address book UI, which is displayed in step S 1112.
Fig. 45 shows an example Properties or Attributes UI of an entry selected in Fig. 44.
Figs. 46 to 50 show some examples of User Settings UI, displayed in step S 1114 of this embodiment.
Fig. 51 is a flowchart of the procedural steps of 5619 of this embodiment, in which a check is made to see if any system task needs to be executed. In step 55101, a check is made to determine if any system action exists, which needs to be executed. If no such action exists, the process is terminated and returns. If system action exists, system task T1 is created in step 55102. A
check is made in step 55103 to determine if the system action is CheckExpired. If so, RemoveExpired is executed in step 55104 to remove the infornation whose validity period has expired. If not, a check is made in step 55105 to determine if the system action is CheckUpdate. If so, Update is executed in step 55016 to update the version of the system. After the completion of the above steps, knowledge base is updated in . step 55107 and system task T1 is terminated in step 55108 and the process returns.
Fig. 52 is a flowchart of the procedural steps of RemoveExpired 55104 of this embodiment. Referring to the figure, in step 55201, a valid or active KPTAction is fetched from the knowledge base. In step 55202, a check is made to determine if no KPTAction was found in the previous step. If so, the process terminates.and returns. If not, a check is made in step 55203 to determine if the validity period of the KPTAction is defined. If not, the control goes back to step 55202 to fetch the next valid or active I~I'TAction from the knowledge base and the process continues. If so, a check is made in step 55204 to determine if the validity period of the KPTAction has expired. If not, the control goes back to step otherwise, a confirmation is made to the user or based on user settings without asking the user every time, to verify if the found action can be deleted, in step 55205. If so, in step 55206 the KPTAction and the associated I~PTDocument is deleted from the knowledge base and in step 55207 the knowledge base is updated and the control goes back to step 55201 to fetch the next valid or active KPTAction from the knowledge base and the process continues till no more actions are found.
Fig. 53 is a flowchart of the procedural steps of CheckUpdate 55106 of this embodiment. In step 55301, the current version of the system, V 1 is obtained. In step 55302 a check is made to determine if the version V2 can be obtained from the website. If not, the process terminates and returns. If so, a check is made to determine if version V2 is greater than V 1. If not, the process terminates and returns. If so, a check is made in step 55304, to see if user confirmation is required, in which case after confirming from the user, the latest version is downloaded in step 55305 and the system updates itself in step 55306 and the process returns.
Fig. 54 is a flowchart of the procedural steps of Sort by keywords S 1307 of this embodiment. Initially in step 55401 the NodeList is set to NULL. In step 55402, the list of all keywords Ll, is retrieved from the knowledge base.
In step SS403, the next keyword Kl is fetched from the list of keywords L1. A
check is made in step 55404 to determine if Kl exists. If so, a check is made in step 55406 to determine if it is a required keyword. If not, the control goes back to step 55403. If so, a check is made in step S5407 to determine if the keyword Kl already exists in the NodeList. If so, the control goes back to step 55403. If not, the keyword Kl is added at the appropriate place in the NodeList in step 55408 and control goes back to step 55403 to fetch the next keyword from the list. If Kl does not exist in step 55404, implying that all the keywords in the NodeList were processed and hence in step 55405, ShowTreeView (NodeList, Type) is executed with Type=Keyword, whose details are explained in Fig. 55 and the example results are shown in Fig. 40, wherein the keywords in the NodeList are displayed in the sorted order.
Fig. 55 is a flowchart of the procedural steps of ShowTreeView 55405 of this embodiment. First in step 55501, a check is made to determine if Type .is Keyword. If so, no keyword is added to the NodeList in step 55502. In step : 55503, the list of nodes in the NodeList is displayed. In step 55504, the process waits for user operation or Action Act and in step 55505, a check is made to determine if the Act is End, in which case the process returns. If not, a check is made in step 55506 to determine if a Leaf was selected. If so ProcessLeafAction(Act, Node, Type) is executed in. step 55507. If not, ProcessNodeAction(Act, Node, Type) is executed in step 55508 and the process returns to step S 5 5 04.
Fig. 56 is a flowchart of the procedural steps of ProcessLeafAction(Act, Node, Type) of step 55507 of this embodiment. A check is made in step 55601, if the Act is Open. If so, all the child nodes and all the actions KPTAction and associated KPTDocument are fetched in step 55602, from the knowledge base for the selected node and added to the NodeList at appropriate places in step 55603 and continues to step 55609. If not, a check is made in step 55604, if the Act is Close. If so, all the child nodes below the selected node are closed or hidden in step 55605 and continues to step 55609. If not, a check is made to determine if the Act is Delete. If so, a confirmation is sought from the user, if required, in step 55607 and if delete is not to be performed, it continues to step 55609, else all the I~PTAction and associated KPTDocument for all the child nodes below the selected node is deleted from the knowledge base in step 55608 and continues to step 55609. In step 55609, the knowledge base is updated based on the type of action performed and in step 55610 the user interface is updated to reflect the updates made in the knowledge base. If in step 55606, the action is not Delete, the process returns.
Fig. 57 is a flowchart of the procedural steps of ProcessNodeAction (Act, Node, Type) of step 55508 of this embodiment. A check is made in step 55701 to determine if the Act is Display (i.e., to display the contents of the stored page), if contents are stored, otherwise, the original page needs to be displayed. If . . so, KPTAction and associated KPTDocument are fetched from the knowledge base for the selected node and added to the NodeList at appropriate place in step and continues to step 55714. If not, a check is made in step 55703 to determine if the Act is Source (i.e., to display the contents of the original page). If so, the KPTAction and associated I~PTDocument are fetched from the knowledge base for the selected node in step 55704 and fetches the contents of the page from the original location or URL in step 55705 and continues to step 55714. If not, a check is made to determine if the Act is Delete in step 55706. If so, a confirmation is sought from the user, if required, in step 55707 and if delete is not to be performed, it continues to step 55714, else in step 55708, the associated KPTAction and I~PTDocument are deleted from the knowledge base and continues to step 55714.
If not, a check is made in step 55709 to determine if the Act is Delete from this group.
If so, a confirmation is sought from the user, if required, in step 55710 and if delete is not to be performed, it continues to step 55714, else in step 55711, the associated attributes or properties of KPTAction and KPTDocument are modified in the knowledge base and continues to step 55714. If not, a check is made in step to determine if the Act is Show Property. If so, the associated properties or attributes of the KPTAction and KPTDocument for the associated node are fetched from the knowledge base in step 55713 and continues to step 55714. In step 55714, the knowledge base is updated based on the type of action performed and in step the user interface is updated to reflect the updates made in the knowledge base. If in step SS712, the action is not Show Property, the process returns.
Fig. S8 is a flowchart of the procedural steps of Sort by Domain step S 1306 of this embodiment. Initially the NodeList is set to NULL in step SS801. In step SS802, the entire top-level domain list Ll is fetched from the knowledge base.
S In step SS803, the next domain name K1 in list Ll is fetched. A check is made in step SS804 to determine if the domain name Kl exists. If so, a check is made in step SS806 to determine if the domain name Kl is unnecessary or not required domain.
If so, it continues to step SS803 to fetch the next domain name from the list.
If not, a check is made in step SS807 to determine if the Kl is already present in Ll, if so, it continues to step SS803 otherwise the domain name Kl is added to the NodeList at the.appropriate place in step SS808 and then continues to step SS803. In step SS804;
if Kl does not exist, implying that all the items in the list L1 have been processed, Rig. SS ShowTreeView(NodeList, Type), with Type = Domain is executed in step SS80S and the example results are shown in Fig. 39, wherein the Domains in the 1 S NodeList are displayed in the sorted order.
Fig. S9 is a flowchart of the procedural steps of Sort by Organization step S 1303 of this embodiment. Initially the NodeList is set to NULL in step SS901.
In step SS902, list of all the organizations Ll are fetched from the knowledge base:
In step SS903, the next organization name Kl in list L1 is fetched. A check is made in step SS904 to determine if the organization name Kl exists. If so, a check is made in step SS906 to determine if the organization name Kl is unnecessary or not required entry. If so, it continues to step SS903 to fetch the next organization name from the list. If not, a check is made in step SS907 to determine if the Kl is already present in L1. If so, it continues to step SS903 otherwise the organization name Kl 2S is added to the NodeList at the appropriate place in step SS908 and then continues to step SS903. In step SS904, if Kl does not exist, implying that all the items in the list L1 have been processed, Fig. SS ShowTreeView(NodeList, Type), with Type =
Orgn is executed in step SS90S and the example results are shown in Fig. 38, wherein the Organizations in the NodeList are displayed in the sorted order.
Fig. 60 is a flowchart of the procedural steps of For Each Session, Sort KPTAction by Time, step 51202 of this embodiment. Initially, in step 56001, the CurrD is set to GetCurrentDate(), which the current date of the system. In step 56002, the MinD is set to GetMinimumDate(), which the minimum or earliest date for which information exists in the knowledge base. In step 56003, the NodeList is set to NULL. In step 56004, GetPreviousYearNodes(NodeList, CurrD, MinD) as detailed in Fig. 61 is executed. In step 56005, GetBeforeCurrMonthNodes(NodeList, CurrD) as detailed in Fig. 62 is executed.
In step 56006, GetBeforeCurrWeekNodes (NodeList, CurrD) as detailed in Fig. 63 is executed. In step 56007, GetCurrWeekNodes(NodeList, CurrD) as detailed in Fig.
64 is executed. In step 56008, ShowTreeView(NodeList, Type) with Type =
Session is executed as detailed in Fig. 55 and the example results are shown in Fig.
37, wherein the Sessions in the NodeList are displayed in sorted order.
Fig. 61 is a flowchart of the procedural steps of GetPreviousYearNodes (NodeList, CurrD, MinD) of step 56004 of this embodiment. A check is made in step 56101 to determine if Year(CurrD) >
Year(MinD) (i.e., the year part of CurrD is greater than the year part of MinD). If not, the process returns. If so, Iyear is set to Year(MinD) (i.e., year part of MinD) in step 56102. In step 56103, a check is made to determine if Iyear < Year(CurrD) (i.e., Iyear is less than the year part of CurrD). If not, the process returns. If so, a check is made in step 56104 to determine if Iyear is equal to Year(CurrD) - 1.
If so, a node called 'Last year' is created and added to the appropriate place in NodeList in step 56105. If not, nodes for that year (i.e., Iyear) is created (e.g., 1999 etc.) and added to appropriate place in NodeList in step 56106. In either case, the step is executed, wherein nodes are created only for 'Months' (e.g., January, June etc.) for which data exists for the specified Iyear in the knowledge base and added to appropriate places in NodeList. In step 56108, nodes are created only for 'Days' (e.g., l, 3, 27 etc.) for each of the above 'Months' for which data exists in the knowledge base and are added to appropriate places in NodeList. In step 56109, Iyear is incremented and the process continues to step 56103, till Iyear becomes greater than or equal to year part of CurrD, at which point the process returns.
Fig. 62 is a flowchart of the procedural steps of GetBeforeCurrMonthNodes (NodeList, CurrD) of step S6005 of this embodiment.

Initially, in step 56201, Imonth is set to 1. A check is made in step 56202 to determine if Month(CurrD) (i.e., month part of CunrD) is equal to Imonth. If so, the process returns. If not, a check is made in step 56203 to determine if the values of Imonth and Month(CurrD)-1 are equal. If so, step 56204 is executed in which, a node called 'Last month' is created and added to appropriate place in NodeList. If not, step 56205 is executed in which, the node with Month name (e.g., Jan or Jun etc.) is created and added to appropriate place in NodeList. In either case, after completion, step 56206 is executed, wherein nodes are created only for 'Days' (e.g., 1, 3, 27 etc.) for each of the above 'Months' for which data exists in the knowledge base and are added to appropriate places in NodeList. In step 56207, Imonth is incremented and the process continues to step 56202, till Imonth is equal to the month part of CurrD, at which point the process returns.
Fig. 63 is a flowchart of the procedural steps of GetbeforeCurrWeekNodes (NodeList, CurrD) of step 56006 of this embodiment.
Initially, in step 56301, Iweek is set to 1. A check is made in step 56302 to determine if Week(CurrD) (i.e., week part of CurrD) is equal to Iweek. If so the process returns. If not, a check is made in step 56303 to determine if the values of Iweek and Week(CurrD-1) are equal. If so, step 56304 is executed in which, a node called 'Last Week' is created and added to appropriate place in NodeList. If not, step 56305 is executed in which the node with Iweek is created (e.g., 1st week, 2nd week etc.) and added to appropriate place to NodeList. In either case after completion, step 56306 is executed, wherein nodes are created only for 'Days' (e.g., 1, 3, 27 etc.) for each of the above''Weeks' for which data exists in the knowledge base and are added to appropriate places in NodeList. In step 56307, Iweek is incremented and the process continues to step 56302, till Iweek is equal to the week part of CurrD, at which point the process returns.
Fig. 64 is a flowchart of the procedural steps of GetCurrWeekNodes (NodeList, CurrD) of step 56007 of this embodiment. Initially, in step 56401, Iday is set to StartofWeek(CurrD) (i.e., the starting day of the current week). A
check is made in step 56402 to determine if Iday is greater than the Day(CurrD) (i.e., the day part of the CurrD). If so, the process returns. If not, in step 56403, a check is made to determine if Iday is equal to Day(CurrD)-1. If so, step 56404 is executed in which, a node called 'Yesterday' is created and added to appropriate place in NodeList and continues to step S6408. If not, step 56405 is executed in which, a check is made to determine if Iday is equal to Day(CurrD) (i.e., current day).
If so, step 56406 is executed in which, a node called 'Today' is created and added to appropriate place in NodeList and continues to step 56408. If not, nodes are created only for 'Days' (e.g., 1, 3, 4 etc.) for which data exists in the knowledge base and added to appropriate places in NodeList and continues to step 56408. In step 56408, child nodes are created for sessions of days) for which data exists in knowledge base. and added to appropriate places to NodeList. Finally in step 56409, Iday is incremented by 1 and the process continues to step 56402, till Iday >
Day(CurrD), at which point the process returns.
Fig. 65 is a flowchart of the procedural steps of steps 51510, 51512 SaveFileContents() of this embodiment. A check is made in step 56501 to determine if the contents to be saved is SaveLink only. If so, the process continues to step 56506. In step 56502, a folder F1 with the name based on the KPTDocument's name, which is a Globally unique identifier (GUID) is created, which ensures that the folder to be created is unique within and across the local system. In step 56503, a file called KPTIndex is created in the folder created in previous step. The actual page contents (i.e., HTML text) are saved to the file created in the previous step.
The fully qualified file name (i.e., the folder name and the file name) is stored as the physical URL location of the KPTDocument. In step 56506, FiIIKPTAction() is executed which is explained in detail in Fig. 66 and the other required indices are determined by refernng to the knowledge base in step 56507 and the process returns.
Fig. 66 is a flowchart of the procedural steps of 56506, FilIKPTAction() of this embodiment. In step 56601, the contents of 'Keep As' are set to 'Remember As' field of KPTDocument. In step 56602, the contents of 'URL' are set to 'LogicalURL' field of KPTDocument. In step 56603, the contents of 'keyword' are set to 'Keyword' field of KPTDocument. In step 56604, the time and date are set to 'WhenDone' field of KPTAction. In step 56605, a checlc is made to determine if KPTAction is Save. If so, step 56606 is executed. If not, a check is made in step 56608 to determine if KPTAction is Hold. If so, in step 56606, the 'Validity' is set to 'WhenToDo' field of KPTAction and in step 56607, 'Page title' is set to 'Title' of KPTDocument and process returns. If not, step 56609 is executed, in which the 'WhenToDo' field of KPTAction is filled with value 'infinity' and the process returns.
Thus, when the user selects Quick Save, this embodiment does not ask the user for file name or destination folder location and the actual process of saving the information be it page contents, annotated contents, page contents plus including all the links below them are stored in a one-touch operation. Also the same information be it a page or link can be stored multiple times (i.e., store the contents of the same link as many times as the user wishes), without ever specifying the filename, and still be able to retrieve them easily. This is especially useful, for users to keep track of the changes in the contents of the same web page. When user selects Save, user interface like Fig. 25 is shown to obtain optionally information regarding the validity or time period for which the contents needs to be saved. When user selects Hold, user interface like Fig. 31 is shown to obtain optionally information regarding the validity or time period for which the contents needs to be held on to. The Save option is basically for storing the information for long range of time, just like storing it in a file cabinet and Hold option for a short period, (i.e., for transient information), which is required to be for say a week or for a few days (e.g., Event or Show information, Limited Time Offers, etc.). The important part of setting the validity or time period for the information in this embodiment is that it will automatically be deleted, after the validity time expires, thus eliminating the time-consuming clean up operations. The user can, of course, keep the information forever, by specifying the validity as Indefinite. Also, if Automatic Save has been selected then all the information are automatically stored by this embodiment but for the URL(s) which are to be executed as specified by user in Fig. 50, are stored without any user intervention.
Fig. 41 is an example for User Interface of Search UI, displayed in step S 1108. Fig. 67 is the flowchart for processing the retrieve conditions set in Fig.

41 and to fetch the appropriate information. In step 56701, Retrieve Query 'Q' is set to NULL. A check is made in step 56702 to determine if Keep As is NULL. If so, the input characters of keep As are set to Keep As of the Retrieve Query Q in step 56703 to retrieve the matching information starting with the given input and continues to step 56704. If not, a check is made in step 56704 is determine if keyword is NULL. If so, the input keyword is set to keyword of the Retrieve Query Q in step 56705 to retrieve the matching information and continues to step 56706. If not, a check is made in step 56706 to determine if Browse Date/ Validity Range is equal to NULL. If so, the input information is set to Browse Date/Validity Range of Retrieve Query Q in step 56707 and continues to step 56708. If not, a check is made in step 56708 to determine if Action Type is null. If so, the input Action Type is set to Action Type of query Q in step 56709 and continues to step 56710. If not, a check is made in step 56710 to determine if input URL is null. If so, the input characters of URL are set to URL of the retrieve query Q in step 56711 to retrieve query Q to retrieve the matching information starting the given input and continues to step 56712. If not, a check is made in step 56712 to determine if the input Page tile is NULL. If so, the input characters of Page title is set to Page Title of the retrieve query Q in step 56713 to retrieve query Q to retrieve the matching information starting the given input and continues to.step 56714. If not, a check is made in step 56714 to determine if retrieve query Q is NULL (i.e., if any of the conditions to find was specified). If so, step 56715 is executed in which an error message is displayed to the user and continues to step 56702. If not, step 56716 is executed to retrieve all the matching KPTAction and associated KPTDocument from the knowledge base for the input retrieve query Q and the results are displayed to the user in step 56717 and the function returns.
Fig.43 is an example for User Interface of Search Extracted Data UI
for UI displayed in step S 1110. Fig. 68 is the flowchart for processing the retrieve conditions set in Fig.43 and to fetch the appropriate information. In step 56801, Retrieve Query "Q" is set to NULL. A check is made in step 56802 to determine if Keep As is NULL. If so, the input characters of Keep As are set to Keep As of the Retrieve Query "Q" in step 56803 to retrieve the matching information starting with the given input and continues to step 56804. If not, a check is made in step 56804 is determine if Name is NULL. If so, the input Name is set to name of the Retrieve Query "Q" in step 56805 to retrieve the matching information and continues to step 56806. If not, a check is made in step 56806 to determine if Extracted date is NULL. If so, the input information is set to Extracted date of Retrieve Query "Q" in step 56807 and continues to step 56808. If not, a check is made in step 56808 to determine if Retrieve Query "Q" is NULL (i.e., if any of the conditions to find was specified). If so, step 56809 is executed in which an error message is displayed to the user and continues to step 56802. If not, step 56810 is executed to retrieve all the matching KPTAction and associated KPTPerson from the knowledge base for the input retrieve query Q and the results are displayed to the user in step 5681 l and . the function returns.
Fig. 69 shows example rules for determining the organization indices for a,URL. As can be seen from the figure, the parameter, protocol, obvious address, page information is first removed from the URL. By referring to the Domain Knowledge base, whose example is shown in Fig. 23, the domain part of the URL
is removed. The remaining URL is then processed to obtain the Organization indices as shown.
Fig. 70 shows example rules for determining the domain indices for a . URL_ As can be seen from the figure, the parameter, protocol, obvious address, page information is first removed from the URL. By referring to the Domain Knowledge base, whose example is shown in Fig. 23, the domain part of the URL is obtained.
Fig. 71 shows a Client-Server type implementation of this embodiment. The figure illustrates an example Client-Server type implementation of embodiment of Fig. 2. Multiple clients 401 have KPT C 1 system 402, and communicate with Server 403. Server 403 is equipped with KPT S1 System 404, knowledge base management 405 and Database 406. Server 403 can also communicate with other servers to access their information stored in database, via knowledge base management.
Fig. 72 is a flowchart of the procedural steps of INITIALIZE
processing step 5401 of a client 401, when the embodiment is implemented as Client-Server type implementation. In step 57201, the client first connects to the server. In step 57202, a check is made to determine if connection was successful. If not, error message is displayed in step 57203 and the process returns false.
Otherwise, in step 57204, User information is got and using the information thus obtained, the client logs in to knowledge base in step 57205. In step 57206 a check is made to determine if the login to the knowledge base was successful. If not, an error message is displayed in step 57207 and the process returns false.
Otherwise, the knowledge base is updated in step 57208. In step 57209, UI of this embodiment .
is displayed, an example of which is shown in Fig. 25 is shown and the process returns true.
Fig. 73 is a flowchart of the main procedural steps of server 403, when the embodiment is implemented as Client-Server type implementation. In step 57301, initialization steps are executed. In step 57302, main function processing saving etc. of this embodiment at the server side is performed. In step 57303, terminate or clean-up processing is executed.
Fig. 74 is a flowchart of INITIALIZE SERVER procedure of step 57301 of this embodiment when implemented as Client-Server. In step 57401, Session is created. In step 57402 knowledge base is updated. In step 57403, service is started to accept requests from clients and the process returns.
Fig. 75 is a flowchart of the procedural steps of MAIN-PROCESSOR SERVER procedure of step 57302 of this embodiment when implemented as Client-Server. In step 57501, a check is made if ActL has any requests from any client. If so, the process proceeds to step 57504. If no, a check is made to determine if there is any user operation and ActL is set to UserAction(). If so, the process proceeds to step 57504. If not, a check is made to determine if there are any system tasks to be performed and ActL is set to SystemActionU. If not, the process returns to step 57501. In step 57504, a check is made to determine if ActL
is equal to End System. If so, all the current active tasks are terminated in step 57505 and the knowledge base is updated in step 57506 and the process returns.
If not, in step 57507 ExecuteServerAct(ActL) is executed The ExecuteServerAct is similar to the ExecuteAction of Fig. 14 of this embodiment, the only difference being instead of executing the action completely at the client-end, only a request is made by the client and the actual process is executed at the server end. The knowledge base is updated in step 57508 and the process returns to step 57501.
Fig. 76 is a flowchart of TERMINATE SERVER procedure of step 57303 of this embodiment when implemented as Client-Server. In step 57601 a check is made to determine if there are any active client connections. If so, message is sent to the clients to disconnect from this server since it is shutting down. In either case the process proceeds to step 57603, where all the active sessions are terminated .and the knowledge base is updated in step 57604 and the process returns.
Other exemplary configurations of the system are furthered described below.
Fig. 77 shows a File Server type implementation of this embodiment.
The figure illustrates an example File Server type implementation of embodiment of Fig. 2. Multiple clients 501 have KPT C2 System 502, Knowledge Base Management 503, and communicate with Server 504. Server 504 is equipped with Date Base 406. Server 504 can also communicate with other servers to access their information stored in the database. This File Server type implementation differs from the Client Server type implementation only to the fact that all the processing is done at the client side and only the database is stored on the server, thus allowing multiple clients to share the data stored on the server. The server side does not have any processing module, but for the database.
Fig. 78 shows a Distributed Clients type implementation of this embodiment. The figure illustrates an example Distributed Clients type implementation of embodiment of Fig. 2. Multiple clients 601 have KPT C3 System 602, Knowledge Base Management 603, Database 604 and communicate with other clients to access their information stored in individual databases. The Distributed Clients implementation differs from the Client Server type implementation only to the fact that all the processing is done at the client side and each individual client is able to access data stored on other clients, thus allowing multiple clients to share the data stored across clients in an distributed environment.
Fig. 79 shows another example of Client-Server type implementation of this embodiment. The figure illustrates another example Client-Server type implementation of embodiment of Fig. 2. Multiple clients 701 have KPT C4 system 702, Knowledge base Management 703 and Index DB and communicate with Server 403. Server 403 is equipped with KPT Sl System 404, knowledge base management 405 and Database 406. Server 403 can also communicate with other servers to access their information stored in database, via knowledge base management. The client in this case has the indexes of the information in index DB
of the information stored in the server to enable it to process and display the information in a very efficient way, since during retrieve or sorting the client does not need to connect and fetch the information from the server, thus speeding up the process considerably.
Fig. 80 shows an example implementation of this embodiment in which the server acts as a proxy server and all the connections to the Internet are via the proxy server. By combining the KPT Server and Proxy server, the information 1 S browsing and fetch is speeded up to considerable extent, since the proxy server has an in-built cache.
Fig. 81 shows an example web server based implementation of this embodiment in which the server is a WebServer with KPT S1 System, Knowledge base management and DB. The clients 601 themselves are mere browsers. Thus, the entire processing of this embodiment is done at the server end and the clients only act as a means of displaying the information and getting information from the user.
Fig. 82 shows an example mixed implementation in which the clients can communicate not only with server, as in a File Server implementation, but also to other clients, as in a Distributed Client implementation. As can be seen from the figure, numerous other combinations, like the client communicating with a web server based implementation, proxy server based implementation can also be implemented.
Fig. 83 shows another example of implementation of this embodiment, in which the knowledge base management 804 at the server end, not only communicates with Database 406, but also to other external databases 806 and other external web information 805. Thus, the clients not only view the contents of the Internet, but can also view the contents of a local database or local web information, along the same lines described in detail earlier in this embodiment.
Fig. 84 shows another example of compounded implementation of this embodiment, in which the client 902 not only has knowledge base management 903, at the client end not only communicates with Database 904, but also to other external databases 906 and other local web information 905 on the client but also to other clients or servers explained earlier in this embodiment.
Fig.85 displays an example of Show All links User Interface for Distributed client implementation of this embodiment. The left hand side displays the links sorted on the specified attribute (Travel, in this example) of the current users' information and information on other client for example as can be seen in this figure, Taro's kee<p>oint and Suzuki's kee<p>oint. The right hand side view shows the contents of the saved information selected by the user for viewing on the left-hand side. It is obvious from the figure that it is possible that in case of Client Server implementation, the left-hand side view can be based on multiple servers and clients. It is also possible that only selected or customized servers or clients can be specified or defined in the left hand side view and also allow other clients to refer only after obtaining the necessary authentication or permission required to access the information.
Fig.86 displays an example of Show All links User Interface for Client Server implementation of this embodiment. The left-hand side displays the links sorted on the specified attribute (Sports, in this example) of the current users' information and information on other Server for example, I~PT Server and Saora Server. The right hand side view shows the contents of the saved information selected by the user for viewing on the left-hand side. It is obvious from the figure that it is possible that in case of File Server implementation, the left-hand side view can be based on multiple servers and clients.
Figs. 87 and 88 display other examples of Show all links User Interface for external Database implementation of this embodiment. The left hand side displays the links sorted in the specified attribute (Organization Chart, Designation in these examples respectively). The right hand side view shows the contents of the saved information selected by the user for viewing on the left-hand side.
Fig. S9 displays an example of Session User Interface for external Database implementation of this embodiment. The left hand side displays the links sorted in the time or session order. The right hand side view shows the contents of the saved information selected by the user for viewing on the left-hand side.
Fig. 90 displays another example of Show all links User Interface for local web information implementation of this embodiment. The left-hand side displays the links sorted in the specified attribute (Product DB, in this example).
The right hand side view shows the contents of the saved information selected by the user for viewing on the left-hand side.
Fig. 91 displays another example of Session User Interface for File System implementation of this embodiment. The left hand side displays the links sorted in the time or session order. The sessions as can be seen from the figure are defined as from start of the working day till the end , or say from start of the day till lunch break and after lunch break to end of.the day etc. The right hand side view shows the contents of the information selected by the user for viewing on the left-hand side. Thus, as it becomes obvious from this figure that the human beings keep track of the actions performed based on time and session and the contents of the proposed embodiment can be. applied to any invention to sort and present the actions of an entity in time sorted, session fashion.
The present invention described above may be applied to a system constituted of a plurality of computers, or a specific computer within a system. the object of the present invention can also be achieved by supplying a storage medium storing program codes of software for implementing the function of the above embodiment to a system or an apparatus, and reading out and executing the program codes stored in the storage medium by a computer (or a CPU or MPU) of the system or apparatus. In this case, the program codes read out from the storage medium implement the function of the present invention, and the storage medium storing these program codes constitutes the invention. Also, besides the function of the above embodiment is implemented by executing the readout program codes by the computer, the present invention includes a case where an OS (Operating System) or the like running on the computer performs a part or the whole of actual processing in accordance with designations by the program codes and thereby implements the function of the above embodiment.
Furthermore, the present invention also includes a case where, after the program codes read out from the storage medium are written in a memory of a function extension board inserted into the computer or of a function extension unit connected to the computer, a CPU or the like of the function extension board or function extension unit performs a part or the whole of actual processing in accordance with designations by the program codes and thereby implements the function of the above embodiment.
It is to be understood that the above description is only representative of illustrative examples of embodiments and implementations. For the reader's convenience, the above description has focused on a representative sample of all . possible embodiments, a sample that teaches the principles of the invention.
Other embodiments may result from a different combination of portions of different embodiments. The description has not attempted to exhaustively enumerate all possible variations.
It should be recognized that the method, system and apparatus for monitoring connectivity across disparate networks has many applications, and is not limited to the representative examples disclosed herein. Alternate embodiments may not have been presented for some of the specific portions of the invention.
Some alternate embodiments may result from a different combination of described portions, or other un-described alternate embodiments may be available for a portion. This is not to be considered a disclaimer of those alternate embodiments, because many of those un-described embodiments are within the literal scope of the following claims, and others are equivalent.
It is to be further understood that the tasks described in the following claims can be sequenced in many different orders to achieve the desired result.
Thus, the scope of the present invention covers conventionally known variations and modifications to the system components and the method steps described herein, as would be known by those skilled in the art.

Claims

WHAT IS CLAIMED IS:

1. A data processing system, comprising:
data acquisition means for acquiring data;
determination means for determining whether user requests saving of the acquired data;

indexing means for assigning a predetermined index to the data requested for saving, said index dynamically assigned to the data; and saving means for saving the requested data and the assigned index in a predetermined storage unit.

2. The system according to Claim 1, wherein said data acquisition means acquires data from a browser client, said browser client allowing browsing of data in an internet.

3. The system according to Claim 1, wherein the predetermined storage is a database, and said system further comprising data retrieving means for retrieving data from the database based on a user-supplied index, said user-supplied index specified by a user.

4. The system according to Claim 1, further comprising:
sorting means for sorting indices of the data in the storage unit; and display means for displaying a result of the sorting by said sorting means.

5. The system according to Claim 4, wherein said sorting means performs the sorting based on a plurality of types of indices.

6. The system according to Claim 4, further comprising:
selecting means for selecting an index from the indices displayed on said display means; and retrieval means for retrieving data corresponding to the index selected by said selecting means from the database.

7. The system according to Claim 4, further comprising:
deleting means for deleting at least one index from the indices displayed on said display means; and removal means for removing data corresponding to the index deleted by said deleting means from the database.

8. The system according to Claim 4, wherein at least one of the data has a plurality of values for an index, and said sorting means places the plurality of values at positions corresponding to respective values.

9. The system according to Claim 2, said saving means comprising:

folder creation means for creating a new folder for newly browsed data;

file name assigning means for assigning a predetermined name to the newly browsed data without intervention by a user; and file saving means for saving the newly browsed data in the new folder with the assigned file name.

10. The system according to Claim 9, wherein said folder creation means creates the new folder with a folder name created based on a predetermined rule.

11. The system according to Claim 10, wherein the folder name is a fixed name.

12. The system according to Claim 2, said saving means comprising:

file name generation means for generating a unique file name for the newly browsed data without intervention by a user; and file saving means for saving the newly browsed data with adding the generated file name.

13. The system according to Claim 2, wherein said indexing means acquires a URL of the data from the browser as the index.

14. The system according to Claim 2, wherein said indexing means acquires at least one of a keyword or a title embedded in the data from the browser as the index.

15. The system according to Claim 14, wherein said indexing means displays the keyword or the title acquired from the browser.

14. The system according to Claim 1, wherein the index includes a time when the data is saved, said system further comprising:

node creation means for creating nodes corresponding to groups classified on the basis of the timing of saving, said node creation means creates a hierarchical nodes by dividing a group corresponding to a period into a plurality of sub group each corresponding to a shorter period and creating a node corresponding to each of sub group; and node displaying means for displaying a plurality of nodes created by said node creation means in an order of saving.

15. The system according to Claim 14, wherein the data is on the network and each of the group corresponds to a session for the network.

16. The system according to Claim 14, wherein the data is file data and each of the group corresponds to a period from a start to an end of a file system.

17. The system according to Claim 14, wherein the data is file data and each of the group corresponds to an operation in a period for a file system.

18. The system according to Claim 13, further comprising word assigning means for assigning a word specified by a user as a further index to the data to be saved by said saving means.

19. The system according to Claim 1, wherein if an index assigned to the data to be saved has been assigned to other data, said saving means saves the data as a new data or updates the other data according to a setting by the user.

20. The system according to Claim 1, wherein if an index assigned to the data to be saved has been assigned to other data, said saving means inquires to the user whether the data is to be saved as a new data or an updated data.

21. The system according to Claim 1, wherein said saving means saves the data in correspondence with an effective period, and said system further comprising:

comparing means for comparing the effective period with a current time at a predetermined timing; and removal means for removing data in correspondence with the effective period before the current time based upon the result of a comparison by said comparing means.

22. The system according to Claim 21, wherein the predetermined timing is a time when the system accepts no operations by a user.

23. The system according to Claim 21, wherein said removal means requests a user to confirm the removal of the data and removes the confirmed data.

24. The system according to Claim 21, wherein said removal means requests a user to confirm the removal of the data or removes the data without confirmation by the user in accordance with a setting by the user.

25. The system according to Claim 21, wherein if the effective period is not specified by the user, said saving means saves the data in correspondence with a non-limited effective period.

26. The system according to Claim 2, wherein said saving means saves the browsed data in a first save mode and saves the URL in place of the browsed data in a second save mode.

27. The system according to Claim 2, wherein said saving means saves the browsed data with data linked thereto.

28. The system according to Claim 2, wherein said saving means always saves the browsed data without any instruction for each of the browsed data by the user.

29. The system according to Claim 28, wherein said saving means saves the browsed data when the browsing is operated to move to another URL.

30. The system according to Claim 28, wherein said saving means is controlled not to save the browsed data in a URL specified by the user in advance.

31. The system according to Claim 2, further comprising index extracting means for extracting as an index a specific data from a data train constituting address of the browsed data in the network on the basis of a predetermined rule.

32. The system according to Claim 31, wherein the specific data is a domain name.

33. The system according to Claim 32, wherein the predetermined rule is a rule for eliminating a parameter, a protocol, an obvious address, and page data from the data train, and extracting a domain name from the rest of the data with referring to a knowledge base of domain names.

34. The system according to Claim 31, wherein the specific data is a name of organization.

35. The system according to Claim 34, wherein the predetermined rule is a rule for eliminating a parameter, a protocol, an obvious address, page data, and domain name from the data train, and determining the rest of the data as an organization name.

36. The system according to Claim 35, wherein the predetermined rule includes a rule for dividing the rest of the data into partial data with a predetermined symbol and determining each of the partial data as an organization name.

37. The system according to Claim 1, further comprising sending means for sending the acquired data or a specific part thereof to a destination.

38. The system according to Claim 37, wherein the specific part is a URL of the saved data.

39. The system according to Claim 37, wherein the specific part is the saved data except for an embedded image.

40. The system according to Claim 2, further comprising editing means for editing the browsed data.

41. The system according to Claim 40, wherein said editing means includes annotation means for adding an annotation to the browsed data.

42. The system according to Claim 41, wherein said annotation means adds an annotation in such a manner that the annotation is distinguishable from the browsed data.

43. The system according to Claim 40, wherein said editing means includes changing means for changing a display form of a designated portion in the browsed data.

44. The system according to Claim 2, further comprising:
extraction means for extracting a predetermined type of data from the browsed data; and extracted data saving means for saving the extracted data in the database.

45. The system according to Claim 44, wherein said extraction means extracts data in a predetermined column in response to a copying operation of data from a specified portion of the browsed data to the predetermined column, and said extracted data saving means saves the extracted data with an attribute corresponding to the predetermined column.

46. The system according to Claim 44, wherein the predetermined type of data includes at least one of an organization name, a person name, an E-mail address, a telephone number, a Fax number, and a keyword appended to the data.

47. The system according to Claim 2, wherein if the data requested to be saved includes data in other URL, said saving means downloads the included data from the other URL.

48. The system according to Claim 47, wherein if the data in the other URL has been downloaded, said saving means dispenses with the downloading of the data.

49. The system according to Claim 2, further comprising mode selection means for selecting an automatic save mode, and in the automatic save mode, said determination means always determines the user requests to save the browsed data without instruction for each of the browsed data.

50. The system according to Claim 3, wherein said data acquisition means, said determination means, said indexing means, said saving means, and said database are equipped in a server apparatus, and said system further comprising at least one client apparatus connected to said server apparatus, each of said client apparatus transmits a user request to said server apparatus and receives a response to the user request from said server apparatus.

51. The system according to Claim 50, wherein said data acquisition means in said server apparatus acquires data in an internet.

52. The system according to Claim 50, wherein said server apparatus further comprising:
a local database;

a web information storage device for storing web information acquires from an internet: and administration means for administrating data in either of said database, said local database, and said web information storage device.

53. The system according to Claim 52, wherein at least one of said client apparatus further comprising:
a client local database;
a client web information storage device for storing web information acquires from an internet: and client administration means for administrating data in either of said database, said local database, and said web information storage device.

54. The system according to Claim 3, wherein said database is equipped in a server apparatus, and said data acquisition means, said determination means, said indexing means, and said saving means are equipped in at least one client apparatus connected to said server apparatus.

55. The system according to Claim 3, wherein said system includes a plurality of client apparatuses, and said data acquisition means, said determination means, said indexing means, said saving means, and said database are equipped in each of said client apparatuses, and each of said client apparatuses can access the database equipped in another client apparatus.

56. The system according to Claim 3, wherein said database is equipped in a server apparatus, and index database for storing the indices of said database is equipped in at least one client apparatus connected to said server apparatus.

57. The system according to Claim 3, wherein said data acquisition means, said determination means, said indexing means, said saving means, and said database are equipped in a server apparatus, said data acquisition means acquires data in an internet, and said system further comprising at least one browser connected to said server apparatus, each of said browser browses web page in the Internet via said server apparatus and transmits a user action on the browses web page to said server apparatus.

58. A data processing method comprising:
acquiring data;
determining whether a user requests to save the acquired data;
assigning a predetermined index to the data requested to save, without inputting any index; and saving the requested data with the assigned index in a predetermined storage unit.

59. A computer-executable program for controlling a computer to perform data processing, said program comprising codes for causing the computer to perform:
a data acquisition step of acquiring data;
a determination step of determining whether or not a user requests to save the acquired data;
an indexing step of assigning a predetermined index to the data requested to save, without inputting any index; and a saving step of saving the requested data with the assigned index in a predetermined storage unit.

60. A data processing method comprising:
acquiring data;
receiving a user request to save the acquired data;
assigning a predetermined index to the data requested for saving; and saving the requested data with the assigned index in a predetermined storage unit.

61. The method of claim 60, wherein said predetermined index is dynamically generated.

62. The method of claim 61, wherein said predetermined storage unit is a database.

63. The method of claim 62, further comprising retrieving data from said database based on a user-supplied index.

64. The method of claim 62, further comprising:
sorting indices of the data saved in the database; and displaying a result of said sorting indices on a display unit.

65. The method of claim 64, wherein said sorting is performed on a plurality of index types.

66. The method of claim 65, further comprising:
selecting an index from the indices displayed; and retrieving data corresponding to the index selected from the database.

67. The method of claim 66, further comprising:
deleting at least one index from the indices displayed on said display unit; and removing data corresponding to said deleted index from the database.

68. The method of claim 67, further comprising assigning a user-specified word as a second index for the data to be saved.

69. The method of claim 68, further comprising sending the acquired data to a predetermined destination.

70. The method of claim 68, further comprising sending a specific part of the acquired data to a predetermined destination.

71. The method of claim 60, wherein said data is acquired from a browser client, said browser client allowing browsing of data in an internet.

72. The method of claim 71, further comprising creating a new folder for newly browsed data in said storage unit.

73. The method of claim 72, further comprising assigning a predetermined file name to said newly browsed data.

74. The method of claim 73, further comprising saving said newly browsed data in said new folder with said predetermined file name.

75. The method of claim 74, further comprising editing the browsed data.

76. The method of claim 75, wherein said editing includes adding an annotation to the browsed data, said annotation is distinguishable from the browsed data.

77. The method of claim 71, further comprising:
extracting a predetermined type of data from the browsed data; and saving the extracted data in the storage unit.