Method and system for reconciling sections of documents

Reconciliation of corresponding groupings of data for processing by application programs ("sections") which are contained within files ("documents") is performed using history lists. In particular, a section in one document which corresponds to a section in another document is reconciled. Each section has a history list which identifies versions of that section. The reconciliation is performed by using 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 unmodified section is modified with the other section. When both sections have been modified, then the user is provided with options for reconciling the sections. In addition, when one document has a new section which is not in the other document, the new section is added to the other document.

TECHNICAL ENTRY 
The present invention relates generally to data processing systems and, 
more particularly, to reconciling sections of documents. 
BACKGROUND OF THE INVENTION 
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. 
SUMMARY OF THE INVENTION 
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.

DETAILED DESCRIPTION OF THE 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.