Method and System for Reconciling Sections of Documents

The present invention relates generally to data processing systems and, more particularly, to reconciling sections of documents.

A typical network includes a central computer with a central memory, containing central files, and includes several local computers that each have a local memory, containing local files. Through the use of a network, a user of the central computer or a user of one of the local computers may access both the central files and the local files. In addition, a user of one of the local computers may copy a central file to a local memory as a local file. The local file corresponds to the central file. Then, the user may modify the local file in the local memory or may modify the central file in the central memory. When either the local file or the central file is modified, they are no longer in synch (i.e., contain the same modifications) Moreover, after modifying a file, a user may save the file in memory. Typically, a conventional system stores a date and time along with the file to indicate the last time the file was saved.

Some conventional systems offer a method of reconciling a central file and a local file which correspond. The reconciliation process updates a file based on the modifications made in the corresponding file so that the two files are in synch. The updating is typically done by replacing the unmodified file with the modified file (i.e., by copying the modified file over the unmodified file). Typically, a conventional system determines whether the local file or the central file has been modified based on the last date and time that the files were saved. Then, the modified file is copied over the corresponding file.

In accordance with a first aspect of the present invention, a method is practiced in a data processing system. A first document is provided which contains a first section which constitutes a grouping of data for processing by an application program. In addition, a first history list is provided which is associated with the first section and which identifies modifications made in the first section. Also, a second document is provided that contains a second section which constitutes a grouping of data for processing by an application program. Moreover, a second history list is provided which is associated with the second section and which identifies modifications made in the second section. The first section and the second section are reconciled using the first history list and the second history list so as to maintain the first section and the second section with the same identified modifications.

In accordance with another aspect of the present invention, a method is practiced in a data processing system. A first document is provided having a first section which constitutes a grouping of data for processing by an application program and is identified by a first section identifier. A second document is provided having a second section which constitutes a grouping of data for processing by an application program and is identified by a second section identifier. It is determined whether the first section identifier and the second section identifier match. When the first section identifier and the second section identifier match, the first section and the second section are reconciled.

In accordance with an additional aspect of the present invention, a method is practiced in a data processing system. A first document is provided having a first section, which constitutes a grouping of data for processing by an application program, where the first section is identified by a first globally unique identifier. A second document is provided having a second section, which constitutes a grouping of data for processing by an application program, where the second section is identified by a second globally unique identifier. The first globally unique identifier is compared to the second globally unique identifier. When the first globally unique identifier matches the second globally unique identifier, the first section and the second section are reconciled.

In accordance with yet another aspect of the present invention, a method is practiced in a data processing system. A first document is provided with a first section which constitutes a grouping of data for processing by an application program and which has a history list. Also, a second document is provided with a second section which constitutes a grouping of data for processing by an application program and which has a history list. It is determined that the first section and the second section match. Then, using the history lists, it is determined which of the sections have been modified. Next, the user is notified of which of the sections have been modified.

In accordance with a further aspect of the present invention, a method is practiced in a data processing system. A document is provided which has a plurality of sections. Each of the sections has a history list. Each of the history lists has a plurality of version identifiers. Each of the version identifiers indicates a version of the section and is identified in a temporal order. Each of the sections also has a reconciliation indicator which indicates whether the section has been reconciled. First, user input is received requesting that the document be stored in memory. In response to the user input, for each of the sections, it is determined whether that section has been reconciled using the reconciliation indicator. When that section has not been reconciled, that section is associated with the most recent one of the version identifiers in the history list. When that section has been reconciled, if it has also been modified, a new version identifier is generated. The new version identifier is added to the history list, and that section is associated with the new version identifier.

In accordance with yet another aspect of the present invention, a method is practiced in a data processing system which includes a first document having first sections, and each of the first sections has an associated history list. Each associated history list identifies versions of the associated sections in a temporal order, where each version is associated with a set of modifications made to a section. In addition, the data processing system includes a second document having second sections, and each of the second sections has an associated history list. Each associated history list identifies versions of the associated section in a temporal order, where each version is associated with a set of modifications made to a section. Moreover, the first section matches the second section. In the data processing system, a reconciler is provided for reconciling matching sections of the first document and the second document. The reconciler includes a correlator for determining matching sections. The reconciler also includes a comparator for determining which of the matching sections has been modified. In addition, the reconciler includes an updator for updating the matching sections based on which of the matching sections has been modified and for setting a reconciliation indicator.

In accordance with yet another aspect of the present invention, a reconciliation application program is stored on a computer readable storage medium. The reconciliation application program includes a retriever for retrieving a first document and a second document. Each of the documents contains sections, where each of the sections has a section identifier and a history list. Each of the history lists has version entries which are associated with modifications to a version of the section. The reconciliation application program also includes a correlator for determining that the section identifiers match. In addition, the reconciliation application program includes a comparator for determining which of the matching sections has been modified using the version entries in each of the history lists. Furthermore, the reconciliation application program includes an updator for updating the matching sections based on which of the matching sections has been modified.

FIG. 1 is a block diagram of a computer system which is suitable for practicing the preferred embodiment of the present invention.

FIG. 2 illustrates a sample user interface provided by a "MICROSOFT BINDER" application for generating and editing a "MICROSOFT BINDER" document in accordance with the preferred embodiment of the present invention.

FIG. 3 illustrates a sample section identifier with an associated History List in accordance with the preferred embodiment of the present invention.

FIG. 4 illustrates sections within two "MICROSOFT BINDER" Documents before they have been reconciled in accordance with the preferred embodiment of the present invention.

FIG. 5 illustrates sections within two "MICROSOFT BINDER" Documents after they have been reconciled in accordance with the preferred embodiment of the present invention.

FIG. 6 is a flowchart illustrating the steps performed when the reconciliation mechanism is used in accordance with the preferred embodiment of the present invention.

FIG. 7 is a flowchart illustrating the steps performed by the reconciliation mechanism in accordance with the preferred embodiment of the present invention.

FIG. 8 is a flowchart illustrating the steps performed to reconcile a first section in a first document and a second section in a second document in accordance with the preferred embodiment of the present invention.

FIG. 9 is a flowchart illustrating the steps performed to use the reconciliation flag in accordance with the preferred embodiment of the present invention.

A preferred embodiment of the present invention enables reconciliation of corresponding groupings of data for processing by application programs ("sections") which are contained within files ("documents"). In particular, the preferred embodiment provides a reconciliation mechanism for reconciling a first section in a first document with a corresponding second section in a second document. Each section has a history list which identifies versions of that section. Specifically, the reconciliation mechanism uses the history lists to compare versions of corresponding sections in order to determine which section has been modified. When one of the corresponding sections has been modified and the other has not been modified, the reconciliation mechanism updates the unmodified section with the modified section. When both sections have been modified, then the reconciliation mechanism provides a user with options for reconciling the sections. In addition, when one document has a new section which is not in the other document, the reconciliation mechanism adds the new section to the other document.

More specifically, when reconciling two corresponding sections, the reconciliation mechanism determines whether either or both the first section and the second section have been modified. If neither section has been modified, then no updating is needed. If only the first section has been modified, then the second section is updated based on the first section. If only the second section has been modified, then the first section is updated based on the second section. If both the first section and the second section have been modified, then the user is provided with an option of updating either section using the other section. Modifications include additions to data within a section, changes to data within a section, deletions of data within a section, or deletions of entire sections. In addition, after updating corresponding documents, the reconciliation mechanism determines which sections exist only in the first document and adds these to the second document. Then, the reconciliation mechanism determines which sections exist only in the second document and adds these to the first document.

FIG. 1 is a block diagram of a computer system 100 which is suitable for practicing the preferred embodiment of the present invention. The computer system 100 includes a first processing unit (CPU) 102. The computer system 100 also includes a memory 104, which contains an operating system 106, a first document 108, and a second document 110. In addition, the computer system 100 includes an input device 112, such as a mouse or a keyboard. The computer system 100 additionally includes an output device 114, such as a video display. The components of the computer system 100 are connected by a connection mechanism 116, such as a bus. In the preferred embodiment of the present invention, the operating system is Windows of Microsoft Corporation, which supports the Microsoft OLE 2.01 protocol developed by Microsoft Corporation of Redmond, Washington.

The "MICROSOFT BRIEFCASE" application reconciles a "MICROSOFT BRIEFCASE" document (i.e., a first document which is maintained with this application) and a non-"MICROSOFT BRIEFCASE" document (i.e., a second document which is not maintained by this application), rather than reconciling sections of documents. The "MICROSOFT BRIEFCASE" application is sold by Microsoft Corporation of Redmond, Wash. When modifications are made to either the first document or the second document, the "MICROSOFT BRIEFCASE" application provides a method of reconciling the documents. In particular, the "MICROSOFT BRIEFCASE" application determines whether the first document or the second document has been more recently modified based on the last date and time that the documents were saved. When only one document has been modified, the updated document is copied over the corresponding document. When both documents have changed, the "MICROSOFT BRIEFCASE" application is unable to reconcile the documents and notifies the user of this.

The "MICROSOFT BINDER" application generates a "MICROSOFT BINDER" document (i.e., file) which contains sections (i.e., groupings of data for processing by application programs). Each section may be processed by the same or a different application program, such as "MICROSOFT WORD" or "MICROSOFT EXCEL." The "MICROSOFT BINDER" application is sold by Microsoft Corporation of Redmond, Wash. Each section in a "MICROSOFT BINDER" document has an associated globally unique identifier ("GUID"). A GUID is generated by calling the CoCreateGUID() function provided by the Microsoft OLE 2.01 protocol. A GUID is a 128-byte integer which uniquely identifies the section.

FIG. 2 illustrates a sample user interface provided by a "MICROSOFT BINDER" application for generating and editing a "MICROSOFT BINDER" document 202 in accordance with the preferred embodiment of the present invention. The "MICROSOFT BINDER" document 202 contains sections, including a "MICROSOFT WORD" document 204 and a "MICROSOFT EXCEL" worksheet 206. When two corresponding "MICROSOFT BINDER" documents are to be reconciled, the reconciliation mechanism can reconcile the corresponding sections within them.

The reconciliation mechanism enables a user to reconcile sections of "MICROSOFT BINDER" documents rather than entire documents. In particular, in a preferred embodiment, the reconciliation mechanism reconciles a first document which is a "MICROSOFT BINDER" document maintained by the "MICROSOFT BRIEFCASE" application and a second document which is a "MICROSOFT BINDER" document which is not maintained by the "MICROSOFT BRIEFCASE" application. For example, if one section in the first document were modified one day and a different section in the second document were modified the next day, the "MICROSOFT BRIEFCASE" application does not perform reconciliation. Instead, the "MICROSOFT BRIEFCASE" application notifies the user that both documents have changed and so cannot be reconciled. However, with the reconciliation mechanism, both modified sections would be in both the first and second documents. By updating sections that have changed rather than the entire document, the reconciliation mechanism enables reconciliation of two documents when different sections have been modified in the documents.

FIG. 3 illustrates a sample section identifier and its associated History List in accordance with the preferred embodiment of the present invention. Each section of a document has a section identifier 305 and a History List 306. The Section GUID entry identifier of entry 308 identifies a section with a globally unique identifier. The entry value of entry 308 is 2468. Each History List has several entries, and each entry contains an entry identifier 302 and an entry value 304. The fReconciled entry identifier (i.e., reconciliation indicator) of entry 310 indicates whether this section has already been reconciled and is used to determine whether to generate a new version GUID when saving a document, as will be discussed in further detail below. The entry value of entry 308 is set to TRUE, indicating that this section has already been reconciled. When the fReconciled entry is set to FALSE, however, it indicates that this section has not been reconciled since the last time it was saved. The Number of Versions entry identifier of entry 312 indicates the number of versions of this section which have been generated. The entry value of entry 312 indicates this section has 3 versions. The History List also contains version GUIDs (i.e., version identifiers) which identify each version of the section. For a preferred embodiment of the present invention, the most recent ten version GUIDs of a section are stored in the History List. One skilled in the art would recognize that the illustration of ten versions above is not intended to be limiting of the present invention. The version GUIDs are listed in a temporal order, with the version GUID for the most recently modified version listed as the first version GUID. For example, the Version GUID 1 entry identifier of entry 314 identifies the most recent version of this section with a globally unique identifier, which is entry value 3298. A new version GUID is generated and added to the History List when a section is modified and then saved while the fReconciled entry is TRUE. Furthermore, in each "MICROSOFT BINDER" document, there is a header portion of the document which contains information for each section, including a section identifier and History List. The grouping of data which constitutes the most recent version is also stored with the section information of the "MICROSOFT BINDER" document.

FIG. 4 illustrates sections within two "MICROSOFT BINDER" Documents before they have been reconciled in accordance with the preferred embodiment of the present invention. "MICROSOFT BINDER" Document A 402 contains three sections, a "MICROSOFT WORD" section 406, another "MICROSOFT WORD" section 408, and a "MICROSOFT EXCEL" section 410. Each section contains a section identifier and an associated History List. FIG. 4 illustrates the History List 412 associated with the "MICROSOFT WORD" section 408. In addition, FIG. 4 illustrates "MICROSOFT BINDER" Document B 404 having three sections, a "MICROSOFT EXCEL" section 430, another "MICROSOFT EXCEL" section 432, and a "MICROSOFT WORD" section 434. FIG. 4 also illustrates the History List 436 for the "MICROSOFT WORD" section 434.

In performing reconciliation, the reconciliation mechanism first determines which sections correspond by comparing their section GUIDs. For example, in FIG. 4, the "MICROSOFT WORD" section 408 has a Section GUID value of 123 in the entry 414, and the "MICROSOFT WORD" section 434 has a Section GUID value of 123 in the entry 438. These sections correspond because they have the same section GUID. Then the reconciliation mechanism determines whether either or both sections have been updated by comparing Version GUIDs. In this example, the first version GUID 9620 in the entry 420 for "MICROSOFT BINDER" Document A's section is not found in the version GUID entries for the "MICROSOFT BINDER" Document B's section, which indicates that Version GUID 9620 in the entry 420 contains modifications which are not in the corresponding section. Then, the reconciliation mechanism determines that the first Version GUID 422 of "MICROSOFT BINDER" Document B's section is also the Version GUID 444 "MICROSOFT BINDER" Document B's section, indicating that the section in "MICROSOFT BINDER" Document B has not been modified since it was last reconciled with "MICROSOFT BINDER" Document A. Therefore, the reconciliation mechanism updates the "MICROSOFT BINDER" Document B's History List to add the latest version GUID and updates the "MICROSOFT BINDER" Document B's section information to include the new version.

FIG. 5 illustrates sections within two "MICROSOFT BINDER" Documents after they have been reconciled in accordance with the preferred embodiment of the present invention. The History List 520 for "MICROSOFT BINDER" Document B has 3 versions now, as indicated by the entry value in the entry 524. The History List 520 has a new first version entry, Version GUID 1 which has an entry value of 9620 in the 526 entry, corresponding to the entry value of 9620 in the 516 entry of the "MICROSOFT BINDER" Document A's History List 510. The original two version entries of "MICROSOFT BINDER" Document B's section's History List have been listed after the newly added version entry, indicating that they were earlier versions. Also, the reconciled entry identifier of each History List has an entry value of TRUE in the entries 512 and 522, indicating that these sections have been reconciled.

FIG. 6 is a flowchart illustrating the steps performed when the reconciliation mechanism is used in accordance with the preferred embodiment of the present invention. First, the reconciliation mechanism receives user input requesting to know whether documents were modified (step 602). Then, the reconciliation mechanism uses the reconciliation process, which will be discussed in detail below, to determine whether the documents have been modified (step 604). The reconciliation process determines which sections correspond and which have been modified, as well as, which have been newly added. If the documents were not modified (step 606), then the reconciliation mechanism displays a message indicating that the documents were not modified (step 608). If the documents were modified (step 606), then the reconciliation mechanism provides the user with the results of the reconciliation process and with an option to update the documents (step 610). This allows a user to view the results of the reconciliation process before deciding whether or not to update the documents. Then, the reconciliation mechanism receives user input requesting to update the documents (step 612). Next, the reconciliation mechanism updates the sections in the documents and sets their reconciliation flags to TRUE (step 614) to indicate that these sections have been reconciled.

FIG. 7 is a flowchart illustrating the steps performed by the reconciliation mechanism in accordance with the preferred embodiment of the present invention. Once the reconciliation mechanism determines that it has corresponding documents, the reconciliation mechanism determines which sections correspond in the corresponding documents (step 702). Each document has a globally unique identifier (a "document GUID") which identifies that document. Two documents correspond when they have the same document GUID. In addition, each section has a globally unique identifier (a "section GUID") which identifies that section. Two sections correspond when they have the same section GUID. Moreover, each section may have several versions. Each of the versions represents a set of modifications made to a document, such as a "MICROSOFT WORD" document. Each version has a globally unique identifier (a "version GUID") which identifies that version. Two versions correspond when they have the same version GUID. Continuing with the flow diagram of FIG. 7, after determining corresponding sections (step 702), the reconciliation mechanism performs the reconciliation process (step 704), which will be discussed below. The reconciliation process compares the versions of the sections and updates sections as is appropriate. Then, the reconciliation mechanism updates the remaining sections (step 706), which are new sections added to the documents and which do not have corresponding sections.

FIG. 8 is a flowchart illustrating the steps performed to reconcile a first section in a first document and a second section in a second document in accordance with the preferred embodiment of the present invention The reconciliation process performs reconciliation using History Lists. For each section in a document, there is an associated History List. yThe History List contains version entries with version GUIDs.

First, the reconciliation process determines whether only the first section has been modified (step 802). In particular, when the second section's first version GUID matches the second or higher version GUID of the first section, then the first section has been modified since the last reconciliation and the second section has not been modified since then. If only the first section has been modified, then the reconciliation process indicates to the user that the first section has been modified (step 804). Otherwise, the reconciliation process determines whether only the second section has been modified (step 806). When the first section's first version GUID matches the second or higher version GUID of the second section, then the second section has been modified since the last reconciliation and the first section has not been modified since then. When only the second section has been modified, then the reconciliation process indicates to the user that the second section has been modified (step 808). Otherwise the reconciliation process determines whether both the first section and the second section have been modified (step 810). In particular, the reconciliation process determines whether the first section's first version GUID matches the second section's first version GUID. If these match, then neither the first section nor the second section have been modified and the reconciliation process returns. Otherwise, the reconciliation process has determined that both the first section and the second section have been modified and the reconciliation process indicates to the user that both sections have been modified (step 812). When both the first section and the second section have been modified, the reconciliation mechanism provides a user with the option of either updating the first section with the second section or with updating the second section with the first section.

FIG. 9 is a flowchart illustrating the steps performed to use the reconciliation flag in accordance with the preferred embodiment of the present invention. First, a request is received from the user to save a document (step 902). Next, the first section in the document is selected (step 904). Then it is determined whether all sections have already been selected (step 906). When all sections have already been selected, the reconciliation mechanism returns. Otherwise, it is determined whether the reconciliation flag is set to TRUE or to FALSE (step 908). If the reconciliation flag is set to FALSE, the section has not been reconciled since the last time it was saved. When the reconciliation flag is set to FALSE, the selected section is associated with the most recent version GUID in the History List (step 910). By not generating a new version GUID when reconciliation has not occurred, the reconciliation mechanism saves time and memory. Otherwise, when the reconciliation flag is set to TRUE, the selected section is associated with a newly generated version GUID which is added to the History List (step 912). Then the reconciliation flag is set to FALSE (step 914) to indicate that the latest version of this section has not been reconciled. After this, the next section is selected for processing (step 916).

In summary, the reconciliation mechanism provides efficient reconciliation of large documents by updating sections which have been modified rather than by copying an entire document in place of another. In addition, the reconciliation mechanism provides the results of the reconciliation process to a user and allows the user to determine whether or not the updates should be performed. This enables a user to review the results of the reconciliation process before deciding whether to update documents. Moreover, using a reconciliation flag, the reconciliation mechanism determines whether or not to generate a new version of a section, which maintains the History List at a minimum required size. Furthermore, the reconciliation mechanism enables reconciliation when different sections of two documents are modified.

Although the methods and systems of the present invention have been described in terms of a preferred embodiment, it is not intended that the invention be limited to this embodiment. Modifications within the spirit of the invention will be apparent to those skilled in the art. For example, although the preferred embodiment discussed above indicates that a user requests reconciliation, the reconciliation may be automatically performed. In addition, although the preferred embodiment has been discussed using a first document processed by the "MICROSOFT BRIEFCASE" application and a second document which is not processed by this application, any document may be reconciled with another using the present invention. For example, a central document and a local document on a network may be reconciled. Moreover, when both a first section and a second section have been modified, it is possible that another reconciliation process may be used to reconcile those sections rather than updating one with the other. The scope of the present invention is defined only by the claims that follow.