Abstract:
A system and method and related computer readable media for creating a system of linked documents. The method includes: storing a file, the file including a document and being linked to a macro, on a data processing system, the data processing system having an operating system; the operating system controlling the data processing system to execute the macro in response to a predetermined trigger event; and the macro controlling the data processing system to inspect other files and link selected ones of the other files to the stored file in accordance with predetermined criteria. The macro can be stored centrally, either on the data processing system or on a network, and the stored file linked to the macro by a pointer; or the macro can be incorporated in the stored file. The predetermined criteria are derived in accordance with values of predetermined data elements of the document, and the other files includes keywords and the macro controls the data processing system to inspect the keywords and list the one of the other files if the keywords meet the predetermined criteria. Alternatively, the other files are selected from the listed files after inspection of the other files&#39; full contents in accordance with the predetermined criteria. The operating system can include a virtual machine and the macro can be expressed in executable code for the virtual machine. The trigger event can be the creation or input of a new file on the data processing system.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    The present invention relates to linked information retrieval. More particularly it relates to a method and system for creating links between files that define documents (i.e. formatted data) and for using such links to enable a flow of information among such files.  
           [0002]    While present data processing techniques for accessing, updating and applying data residing in digital documents have been highly successful they are in many ways inefficient and cumbersome. A typical personal computer (hereinafter “PC”) will contain files in many formats. Most of these files are documents; digital representations of what could as well be paper documents. Heretofore, it has been difficult to provide active (i.e. process) links between documents, and such links have only been infrequently provided between specifically identified documents. (Languages such as HTML are capable of providing links between data in documents, but do not provide process links.) Users, and particularly ordinary users of PC&#39;s, rely on software developers to provide programs to carry out any desired processes. As a result when a user wishes to carry out an application the user is dependent upon the software developer to understand the application desired by the user (at least approximately) and the developer must somehow know or control the particular files to be accessed. The confusion, delay, and general aggravation that result from this arrangement are too well known to require comment here.  
           [0003]    Accordingly, there is a need for a method and system to enable interaction between documents to increase access to and networking of information, and to improve workflow processes.  
         BRIEF SUMMARY OF THE INVENTION  
         [0004]    These and other needs are addressed by the present invention by a system and method and related computer readable media for creating a system of linked documents. The method includes: storing a file, the file including a document and being linked to a macro, on a data processing system, the data processing system having an operating system; the operating system controlling the data processing system to execute the macro in response to a predetermined trigger event; and the macro controlling the data processing system to inspect other files and link selected ones of the other files to the stored file in accordance with predetermined criteria.  
           [0005]    In accordance with one aspect of the invention the macro is stored centrally, either on the data processing system or on a network, and the stored file is linked to the macro by a pointer.  
           [0006]    In accordance with another aspect of the invention the macro is incorporated in the stored file.  
           [0007]    In accordance with another aspect of the invention the predetermined criteria are derived in accordance with values of predetermined data elements of the document.  
           [0008]    In accordance with another aspect of the invention at least one of the other files includes keywords and the macro controls the data processing system to inspect the keywords and list those files where the keywords meet the predetermined criteria.  
           [0009]    In accordance with another aspect of the invention the selected ones of the other files are selected from the listed files after inspection of the other files&#39; full contents in accordance with the predetermined criteria.  
           [0010]    In accordance with another aspect of the invention the selected ones of the other files consist of the listed files.  
           [0011]    In accordance with another aspect of the invention the selected ones of the other files are selected from the other files after inspection of the other files&#39; full contents in accordance with the predetermined criteria.  
           [0012]    In accordance with another aspect of the invention at least one of the other files comprises self-describing data organized in a manner that can be interpreted by the macro.  
           [0013]    In accordance with another aspect of the invention the operating system includes a virtual machine and the macro is expressed in executable code for the virtual machine.  
           [0014]    In accordance with another aspect of the invention the trigger event is the changing, deleting or moving of an existing file on the data processing system.  
           [0015]    In accordance with another aspect of the invention the trigger event is the creation or input of a new file on the data processing system.  
           [0016]    The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to data processing systems for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks. Volatile media includes dynamic memory. Transmission media includes coaxial cables, copper wire and fiber optics. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0017]    The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:  
         [0018]    [0018]FIG. 1 shows a schematic block diagram of a data processing system for managing networks of linked documents (sometimes hereinafter “Rheodocs”) in accordance with an embodiment of the present invention.  
         [0019]    [0019]FIG. 2 shows a data structure for Rheodocs.  
         [0020]    [0020]FIG. 3 shows a schematic block diagram of a data processing system for managing networks of linked documents in accordance with another embodiment of the present invention.  
         [0021]    [0021]FIG. 4 shows a network of Rheodoc systems implementing an application of Rheodocs.  
         [0022]    [0022]FIG. 5 shows a flow diagram of the operation of one of a host system in managing a credit card Rheodoc.  
         [0023]    [0023]FIG. 6 shows a flow diagram of the operation of one of a home system in managing a credit card Rheodoc.  
         [0024]    [0024]FIG. 7 shows a more detailed flow diagram of the operation of a system to determine if an input data file is a Rheodoc.  
         [0025]    [0025]FIG. 8 shows a more detailed flow diagram of the operation of a system to execute existing Rheodocs.  
         [0026]    [0026]FIG. 9 shows a more detailed flow diagram of the operation of a system in carrying out steps of a Rheodoc process (hereinafter sometimes “macro”).  
         [0027]    [0027]FIG. 10 shows a more detailed flow diagram of the operation of a system in carrying out steps of another macro.  
         [0028]    [0028]FIGS. 11 and 12 show a flow diagram of a process for deleting a Rheodoc. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0029]    A method and system, and related computer readable media are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.  
         [0030]    [0030]FIG. 1 shows Rheodoc system  10 , which is a data processing system for managing Rheodocs. As used herein the term “Rheodoc” refers to a file that defines both a document (i.e. structured data) and an associated process which identifies and links to other files of interest, which can be other Rheodocs to form systems of linked files and enable flows of information among such linked files. (Note that the combining form ‘“rheo”’ means flow.) The associated process is implemented by a program (sometimes hereinafter “macro”) that is linked to the file. System  10  includes Processing Unit  12 , Memory  14 , Local Storage  16  and Rheodoc File Storage  20 . Memory  14  stores program code for controlling processing unit  12  to manage Rheodocs and for carrying other applications, file pointers to Rheodoc files on system  10 , a list of event triggers which initiate execution of the macros. Preferably memory  14  will also store a byte code engine, or virtual machine, to execute macros, as will be described further below. (A byte code engine, or virtual machine, is an application on an actual data processing system that responds to the machine code for, and, emulates the operation of, a different system, which typically does not exist in physical form. Such virtual machine code is referred to as “byte code” by those skilled in the art.) Local Store  16  stores byte code for Rheodoc macros and variable data. Variable data is temporarily stored data including intermediate results, history and audit data. Rheodoc File Store  20  stores Rheodocs as files that comprise a document and linking data linking the file to the byte code and variable data. In FIG. 1 the linking data are pointers. In one embodiment of the present invention the pointers link to Local Store  16 . In another embodiment the pointers link to Network Store  26  through Network  22 .  
         [0031]    [0031]FIG. 2 shows a preferred Rheodoc file structure. The Rheodoc includes content  29 , macro linking data  31 , and volatile linking data  33 . The content includes descriptors  29 - 1  describing the data structure in a conventional self descriptive data format, optional keywords  29 - 2 , full content inspection enable flag  29 - 3 , and data  29 - 4 . Files having content  29  only can be linked by Rheodoc macros but, of course, cannot link other files.  
         [0032]    [0032]FIG. 3 shows another embodiment of the present invention. In FIG. 3 Processing Unit  12  and Memory  14  are substantially as described with respect to FIG. 1 above. Rheodoc File Store  30  store files where the documents, byte code and variable data are linked directly in each Rheodoc file.  
         [0033]    (While implementation of macros as byte code is preferred as efficiently providing compatibility across various types of systems, it should be noted that any convenient form of implementation is within the contemplation of the present invention. For example, if Rheodocs are used on only a single type of system the macros can be implemented in the machine language of that type system; or the macros can be written in a high level language and compiled as the Rheodocs are installed.)  
         [0034]    [0034]FIG. 4 shows a network of Rheodoc systems implementing an exemplary application of Rheodocs: linking credit card receipt information to an expense report template. Pluralities  40  of point of sale systems (hereinafter sometimes “POS&#39;s”) communicate with corresponding ones of a plurality of host systems  42 . Host systems  42  communicate over network  44  with home system  48 . (In general communication among the systems of FIG. 4 can be carried out in any convenient manner details of which form no part of the present invention.) Host systems  42  and home system  48  are Rheodoc systems. Systems  42  manage “credit card” Rheodocs that inspect and identify files that contain receipt information for particular credit card transactions and send a file of linking data to home system  48 . The linking data can be pointers to files containing relevant receipt information or can be the relevant information abstracted from the identified files. Preferably, Rheodoc macros will only provide access to the portions of identified files that contain relevant information. Home system  48  manages an expense report Rheodoc, which includes an expense report template document, and which links the linking data files received from host systems  42  to the expense report template. When an expense report application is opened the receipt information is transferred to the template. (It should be noted that the terms “host system” and “home system” as used herein are not intended to connote any particular architectural differences between systems  42  and system  48  or imply that network  44  is hierarchal; but only to indicate the roles played by these systems in the preferred embodiment described. Preferably systems  42  and  48  comprise a peer-to-peer network and can have other functions in other applications.)  
         [0035]    [0035]FIG. 5 shows a flow diagram of the operation of one of host systems  42  to manage a credit card Rheodoc. In accordance with the present invention a credit card is modified so as to constitute a Rheodoc by the incorporation of a pointer to a Credit Card Rheodoc macro along with conventional credit card information such as card number and expiration date. At step  50  system  42  responds to a trigger event, here the input of transaction data and a pointer to a Credit Card Rheodoc macro from one of POS&#39;s  40 , to update and process its receipt files, as will be described further below. At step  52  system  42  evaluates security and priority rules to decide if execution is permitted. These rules typically determine whether the execution of this macro is allowed, in the general case, by the system. At step  56 , if execution is permitted, system  42  goes to step  58  to inspect and process the transaction data and update the receipt files, as will be described further below. Otherwise system  42  exits and waits for another trigger event. Then at step  60  system  42  inspects and processes the next existing Rheodoc, as will be described further below. That is the Rheodoc next in priority in the class of Rheodocs whose execution is permitted at step  52 . At step  62  system  42  determined if execution of another Rheodoc is permitted and, if so returns to step  60  and otherwise exits to wait for the next trigger event.  
         [0036]    When the receipt files are opened for updating at step  58  another trigger event occurs and, at step  61 , system  42  responds. At step  63  system  42  evaluates security and priority rules to decide if execution is permitted. These rules typically determine whether the specific executing macro is allowed to access this file at this time. At step  65 , if execution is permitted, system  42  goes to step  67  to inspect and process the receipt file data and send a pointer to the receipt file data of interest to home system  48 , as will be described further below. Otherwise system  42  exits and waits for another trigger event. Then at step  69  system  42  inspects and processes the next existing Rheodoc, as will be described further below. That is the Rheodoc next in priority in the class of Rheodocs whose execution is permitted at step  63 . At step  71  system  42  determined if execution of another Rheodoc is permitted and, if so returns to step  69  and otherwise exits to wait for the next trigger event.  
         [0037]    [0037]FIG. 6 shows a flow diagram of the operation of home system  48  to manage a credit card Rheodoc. At step  70  system  48  responds to a trigger event, here the input of pointers to receipt data to initiate execution of the expense Rheodoc, as will be described further below. At step  72  system  48  evaluates security and priority rules to decide if execution is permitted. At step  76 , if execution is permitted, system  48  goes to step  78  to inspect and process the receipt data pointer file, as will be described further below. Otherwise system  48  exits and waits for another trigger event. Then at step  80  system  48  inspects and processes the next existing Rheodoc, as will be described further below. That is the Rheodoc next in priority in the class of Rheodocs whose execution is permitted at step  82 . At step  82  system  48  determined if execution of another Rheodoc is permitted and, if so returns to step  80  and otherwise exits to wait for the next trigger event.  
         [0038]    It should be noted that while in the described embodiment of the present invention trigger events are the input of data, i.e. the creation or updating of an input data file, other events can be defined as triggers for the execution of the same or different classes of Rheodocs. Such events include, but are not limited to: opening a file to read, write, or execute; closing a file; copying a file; and Rheodoc macro-to-Rheodoc macro messages.  
         [0039]    [0039]FIG. 7 shows a more detailed flow diagram of the operation of systems  42  and  48  in executing steps  58  and  67 , and  78  respectively to determine if the input data file is a Rheodoc. Note that in other embodiments of the present invention priority and security rules may not permit of the possibility that files that initiate some or all trigger events are Rheodocs. At step  90  the system inspects the input data file, i.e. the input receipt data file for systems  42  and the linking data file for system  48  for the presence of an associated macro, i.e. actual code in the file, or for pointers to such a macro. At step  92  the system determines if a pointer is present, at step  94  if the system is able to fetch a macro over network  22  (shown in FIG. 1), and at step  98  if a macro is present on network store  26 . If the result of all these steps is positive then at step  100  the system fetches the macro and at step  102  executes it, as will be described further below and at step  104  posts abstracted keywords that can have been incorporated in the file. (By posting the abstracted keywords, herein is meant that the keywords in this Rheodoc are sent to all other Rheodocs on the system. This allows the macros in those other Rheodocs to be executed and allows those other Rheodocs to inspect this new file.) If the result at any of steps  92 ,  94  or  98  is negative then the system goes to step  106  to determine if a macro is directly present in the file and, if so goes to step  102  to execute it and then to step  104 , and otherwise goes directly to step  104 . Thus the present invention provides a capability to retrieve the most current update of a macro over network  22  if one is available and, otherwise if it is not possible to retrieve a macro over network  22 , to execute the macro present in the Rheodoc as a “second best” alternative.  
         [0040]    [0040]FIG. 8 shows a more detailed flow diagram of the operation of systems  42  and  48  in executing steps  60  and  80  respectively to execute existing Rheodocs. At step  110  the system inspects the next existing Rheodoc for the presence of an associated macro, i.e. actual code in the file, or for pointers to such a macro. At step  112  the system determines if a pointer is present, at step  114  if the system is able to fetch a macro over network  22  (shown in FIG. 1), and at step  118  if a macro is present on network store  26 . If the result of all these steps is positive then at step  120  the system fetches the macro and at step  122  executes it, as will be described further below. If the result at any of steps  112 ,  114  or  118  is negative then the system goes to step  126  to determine if a macro is directly present in the file and, if so goes to step  122  to execute it.  
         [0041]    [0041]FIG. 9 shows a more detailed flow diagram of the operation of systems  42  at step  102  in carrying out steps of a macro. At step  140  system  42  determines if files are to be inspected for keywords. Keywords are preselected words, phrases, or other data items that at least partially identify files incorporated in those files. Rheodoc files may limit the files exposed to a Rheodoc macro by only considering files containing keywords specified by the macro. If files are to be inspected, at step  142  system  42  lists those files whose keywords match predetermined criteria incorporated in the macro. At step  144  system  42  determines if the listed files are to be inspected in full. If so, the full content of listed files is inspected at  146  for those files which enable full content inspection (for reasons of security full content inspection may be prohibited for some files) and at  150  system  42  sends a file of pointers to identified files: i.e. listed files which match the full content criteria and listed files which do not enable full content inspection, to home system  48 . Otherwise, at step  150  system  42  (i.e. the macro running on system  42 ) sends pointers to all listed files to home system  48 . If files are not to be inspected for keywords, at  152  system  42  inspects the full content of all files and at  150  sends a file of pointers to identified files whose content matches the criteria.  
         [0042]    In some applications of the present invention, macros will simply send pointers of files with matching keywords. The benefit of this is to reduce the time and resources to identify files to be processed by the Rheodocs macro. In other applications, the macro will further qualify files that match the keyword criteria (that is to say that not all files that match the keyword criteria will be of interest, so the macro will need look through the full contents to see if the information is of interest). In still other applications, where it is not possible to determine if files can be limited by keyword and all files will need to be inspected in full. In this manner, in the preferred embodiment described above, macros which are executed in response to input of transaction data to one of host systems  42  can act as “scouts” for home system  48 ; identifying only files which are of interest to system  48 . For example such macros can be structured to only identify receipt files which evidence spending patterns that fall outside predetermined limits, such as restaurant receipts that exceed certain amounts. Decisions made among these various applications allow the macro designer to make tradeoffs between using computer time and resources to inspect each file and send a smaller number of pointers over the network, or to use less computer resources and send more pointers over the network at the expense of network resources.  
         [0043]    [0043]FIG. 10 shows a more detailed flow diagram of the operation of systems  48  at step  122  in carrying out steps a macro. At step  160  system  48  determines if files are to be inspected for keywords. Keywords are preselected words, phrases, or other data items that at least partially identify files incorporated in those files. If so at step  162  system  48  lists those files whose keywords match predetermined criteria incorporated in the macro. At step  164  system  48  determines if the listed files are to be inspected in full. If so, the full content of listed files is inspected at  166  for those files which enable full content inspection and at  170  system  48  creates local pointers to identified files: i.e. listed files which match the full content criteria and listed files which do not enable full content inspection, to home system  48 . Otherwise, at step  170  system  48  creates local pointers to all listed files to home system  48 . If files are not to be inspected for keywords, at  172  system  48  inspects the full content of all files and at  150  creates local pointers to identified files whose content matches the criteria.  
         [0044]    Macro criteria can be predetermined but preferably are paramatized. For example in the present embodiment an expense report template in the expense report Rheodoc will typically include fields defining persons, projects, date ranges, etc. With paramatized criteria, criteria values can be derived from these fields in the Rheodoc document and specific instances of expense reports generated using data from files linked to the template by the Rheodoc macro using these parameters. Those skilled in the art will recognize that compatibility of file formats will be critical for Rheodoc webs of any significant size. In a preferred embodiment fields in a Rheodoc may be stored in an XML (eXtensible Markup Language) format. XML is a well known technology that provides a flexible way to create “self-describing data”, and to share both the format and the data on the World Wide Web, intranets, and elsewhere.  
         [0045]    [0045]FIGS. 11 and 12 show the process for deleting a Rheodoc. In FIG. 11 when a Rhedoc is deleted on a host system all local pointers created by that Rheodoc are deleted at step  190  and the home system that originated the deleted Rheodoc is informed at step  192 . In FIG. 12 the home system responds to the information as a trigger event and calls one or more related Rheodocs that delete any local pointers to the deleted Rheodoc they may have created at step  196 . At step  198  the called Rheodocs inform the systems which created them of the deleted Rheodoc. This allows other Rheodocs that were interested in the deleted Rheodoc to clean up their pointers. Preferably the macro that discovered and sent the file pointers to the home system will send the fact that file has been deleted to the home system to clean up the home system&#39;s local pointers.  
         [0046]    In the preferred embodiments of the present invention described above Rheodocs include pointers to centrally stored macros that are stored on a network. In other embodiments such centrally stored macros can be stored on local storage as described above with respect to FIG. 1. Central storage of macros is preferred to having macros actually present in the Rheodocs since centrally stored macros can be shared and are easier to maintain.  
         [0047]    From consideration of the above preferred embodiment it can be seen that, in accordance with the present invention, the introduction of a Rheodoc to a system causes the system to be extended to perform “safe actions” on behalf of the creator of the Rheodoc. The mere input of the document by a system causes the system to perform services on the behalf of the input document&#39;s owner. In the present embodiment input of a Credit Card Rheodoc triggers a macro to update receipt files with current transaction data, opening of these receipt files for updating in turn triggers a macro which sends pointers to a home system, and receipt of these pointers triggers yet another macro which inspects the receipt files in accordance with predetermined criteria. It will be apparent that such a structure can readily be adapted to create a net work of linked Rheodoc documents (credit card, receipt file, expense report) which can readily be adapted to, for example, identify and track patterns of credit card usage. It will also be apparent to those skilled in the art that such a network of linked documents can readily be extended to carry out other applications simply by the addition of relatively simple macros triggered by appropriate events. For example, a hold on further credit could be easily implemented by a skilled software developer by means of a simple macro incorporated into an expense report Rheodoc to be triggered by detection of a predetermined unusual credit usage pattern, without need for the developer to understand the entire credit card application or to know or control the particular files to be accessed. And such a network of Rheodocs can be easily extended to “scout” for other unanticipated situations by addition of relatively simple macros, with appropriately chosen triggers, to Rheodocs in the network.  
         [0048]    While this invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.