Patent Publication Number: US-6658626-B1

Title: User interface for displaying document comparison information

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     This application is a continuation-in-part to co-pending U.S. patent application Ser. No. 09/127,105, filed Jul. 31, 1998, which is incorporated herein by reference in its entirety. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to computer applications and programming. More specifically, it relates to creating a user interface that enables a user to quickly evaluate similarities and differences among multiple documents of the same or different type. 
     2. Disxussion of Related Art 
     A common feature or utility in some word processing programs and operating systems is the ability to compare files and provide information on differences (or similarities) between the files. There are a variety of file comparison programs available which have different limitations and capabilities, for example, with regard to how and what comparison data is presented or the number of files that can be compared in one run. Many of these programs are adequate in certain aspects but have drawbacks in others making them poorly suited for certain applications. This is particularly true given the constantly growing trend to store, submit, transfer, copy, and otherwise manipulate information electronically. 
     One utility used to compare files in the UNIX operating system is known as diff This program can compare up to three files or documents. The output of this program is typically two columns of data. One column displays line numbers in one (subject) document across from a second column displaying line numbers in the query document that are different from corresponding line numbers in the subject document. Thus, the diff utility is used when the documents are assumed to be generally similar. The program uses a dynamic programming algorithm that computes the minimal “edit distance” between two documents. An “edit distance” between two documents, or strings, is the length of a minimal sequence of insertions, deletions, and substitutions that transforms one to the other. From information about how the minimal edit distance is derived diff computes matching passages in the two documents, which are presented to the user in the column format described earlier. The program can not find differences among sets or large bodies of documents, but typically between two or among three documents at most. 
     Other methods of comparing files can be broadly categorized as information retrieval methods. These methods compare statistical profiles of documents. For example, one strategy used by these methods is computing a histogram of word frequencies for each document, or a histogram of the frequency of certain pairs or juxtaposition of words in a document. Documents with similar histograms are considered to be similar documents. Refinements of these methods include document preprocessing (e.g. removing unimportant words) prior to computing the statistical profile and applying the same information retrieval method to subsections of documents. Some of the primary drawbacks of these methods include tendencies to provide false positive matches and presenting output or results in a form difficult to quickly evaluate. False positives arise because it is sometimes difficult to prevent dissimilar documents from having similar statistical profiles. With respect to presentation, these methods often simply provide correlations. In sum, these methods can often provide too little information about similarities or differences among documents thus requiring the user to closely evaluate the results and refer back to the files being compared to determine whether meaningful differences or similarities exist. 
     Another method is based on a procedure known as document fingerprinting. Fingerprinting a document involves computing hashes of selected substrings in a document. A particular set of substring hashes chosen to represent a document is the document&#39;s fingerprint. The similarity of two documents is defined as a ratio C/T where C is the number of hashes the two documents have in common and T is the total number of hashes taken of one of the documents. Assuming a well-behaved hash function, this ratio is a good estimate of the actual percentage overlap between the two documents. However, this also assumes that a sufficient number of substring hashes are used. Various approaches have been used in determining which substrings in a document are selected for hashing and which of these substring hashes are saved as part of the document fingerprint. One way is to compute hashes of all substrings of a fixed length k and retain those hashes that are 0 mod p for some integer p. Another way is partitioning the document into substrings with hashes that are 0 mod p and saving those hashes. The difference from the first way is that the substrings selected are not of fixed length. In this method, a character is added to a substring until the hash of the substring is 0 mod p, at which point the next substring is formed. In order to reduce memory requirements, the program can set p to 15 or 20 thereby saving, in theory, every 15th or 20th hash value. However, based on probability theory, for a large body of documents, there will be large gaps where no hash value will be saved. This can potentially lead to the situation where an entire document is bypassed without having a single substring hash value saved for a fingerprint. More generally, if gaps between stored hash values are too long, a document&#39;s fingerprint will be faint or thin and, thus, ill-suited for comparison to other documents. 
     Another drawback of current document comparison programs is the presentation of comparison results to the user. Most user interfaces displaying the comparison data are generally text-based. Some may have simple bar graphs or charts based on percentage of matching content. They do not present to the user more specific data on the location of the matching passages, their lengths, or the ability to immediately focus on matching content between two or more documents. Typically, user interfaces or output data from user comparison programs present information based on the total amount of matching content between documents. 
     Therefore, it would be desirable to create and present a user interface for a document comparison program that allows a user to easily and meaningfully evaluate the results of the comparison. It would be desirable to present as much information as possible in a simple, intuitive, and visually-appealing manner that also allows a user to quickly access portions of matching text in the documents. It would also be desirable to have the user interface function efficiently in a Web browser context. 
     SUMMARY OF THE INVENTION 
     To achieve the foregoing, and in accordance with the purpose of the present invention, methods, apparatus, and computer program products for monitoring a document being digitally transmitted within a computer network or outside a private network via the Internet. A digitally transmitted document, such as an email message, is received at a monitoring component or station. The document is compared against multiple previously stored documents, typically including confidential and otherwise sensitive content, and a comparison output or result is produced. It is then determined whether to alter the original transmission of the document based on the comparison result. Through this process, the dissemination of the document with respect to the computer network can be regulated if it contains confidential information. 
     In one embodiment an index, such as a hashtable, for the multiple previously stored documents is created that facilitates the comparison of the document against the previously stored documents, which are stored in a file system or database. In another embodiment it is determined whether the digitally transmitted document should be added to the multiple previously stored documents. The document is examined for predetermined indicators associated with characteristics of the multiple previously stored documents. In another embodiment a rule engine is provided with the comparison output and causes a particular action to occur based on the comparison result. The rule engine performs one of multiple rules based on the comparison output. In yet another embodiment the comparison result indicates whether the document matches any content in the previously stored documents above a predetermined threshold of similarity or percentage of overlap. In yet another embodiment the document is transmitted using an Internet email protocol or a stream-oriented protocol such as HTTP or FTP. 
     In another aspect of the present invention, a user interface having one or more frames for displaying results of a document comparison program is described. The user interface allows a user to efficiently and effectively examine the results of comparing two or more documents for similar or matching passages. One of the frames is an overview frame that contains two or more graphical representations of an equal number of documents that are were compared by the program. A graphical representation contains comparison information related to one or more passages in a selected document that closely resemble passages in other documents. The comparison information enables a user to directly access passages in the selected document thereby facilitating examination of similar passages found in the other documents. The direct access is in the form of an internal link between the comparison information in the graphical representation and the passages in the documents. Such a link is an HTML hypertext link. 
     In one embodiment of the present invention, the user interface contains other frames for displaying content from the documents. One frame contains content from the selected document, or the document being compared to the corpus of documents and the other frames contain content from the corpus of documents. In another embodiment the passages in the selected documents and in the other documents are assigned a color in order to associate matching passages. In yet another embodiment, matching passages in the documents are internally linked, such as through an HTML hypertext link, thereby allowing direct reference to matching corresponding passages among the documents. In yet another embodiment the graphical representation of a document in the overview frame is in the form of an overview bar having typically one or more sub-bands. Each sub-band is assigned a color which matches the color of two or more matching passages. Each sub-band also has a link to its corresponding passage in the document such that activating the link causes the corresponding passage to come up for display in one of the content frames so that the user can examine it. The overview bars are aligned or configured in such a manner that sub-bands in different bars can be compared to see which matching passages might be of interest to a user. 
     In another aspect of the present invention, a method of interacting with a user interface for displaying results of a document comparison program is described. The user interface includes one or more overview bars where each overview bar represents a document used in the comparison program. Each overview bar includes one or more sub-bands where a sub-band represents a passage in the document that matches a passage(s) in another document. A sub-band from an overview bar is selected thereby activating a link between the sub-band and its associated passage in the document. By activating this link, the associated passage is displayed to the user in another frame in the user interface. Upon being displayed to the user, the user selects the associated matching passage thereby activating another link between that passage and its matching passage in another document. By activating this link, the matching passage in the other document is displayed next to the original passage in yet another frame in the user interface. This allows the user to compare the two matching passages simply by clicking on either the sub-bands in the overview bars or the text in the documents. In one embodiment a sub-band is assigned a color that is the same as the color of its corresponding passage in the document. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The invention, together with further advantages thereof, may best be understood by reference of the following description taken in conjunction with the accompanying drawings in which: 
     FIG. 1 is a flowchart showing a method of hashing, comparing, storing a query documents against documents already stored in an index file in accordance with one embodiment of the present invention. 
     FIG. 2 is a block diagram of an index file and of records contained in the index file in accordance with one embodiment of the present invention. 
     FIG. 3 is a diagram showing a transformation of a raw data string to a series of substrings using l and g in accordance with one embodiment of the present invention. 
     FIG. 4 a  is a flowchart showing in greater detail step  126  of FIG. 1 b  in which a current document is clustered based on matches with documents previously loaded into the index file. 
     FIG. 4 b  is an illustration of a format of a match list in accordance with one embodiment of the present invention. 
     FIG. 4 c  is an illustration of a data structure showing how documents can be clustered in accordance with one embodiment of the present invention. 
     FIG. 5 is a flowchart showing in greater detail step  130  of FIG. 1 b  of coalescing matching data segments into passages and presenting output to users in accordance with one embodiment of the present invention. 
     FIG. 6 is an illustration of a screen shot of the user interface associated with the comparison program in accordance with one embodiment of the present invention. 
     FIG. 7 is a flow diagram of a process of creating a user interface for a document comparison program in accordance with one embodiment of the present invention. 
     FIG. 8 is a block diagram of a typical computer system suitable for implementing an embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION 
     Reference will now be made in detail to a preferred embodiment of the invention. An example of the preferred embodiment is illustrated in the accompanying drawings. While the invention will be described in conjunction with a preferred embodiment, it will be understood that it is not intended to limit the invention to one preferred embodiment. To the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims. 
     FIG. 1 is a flowchart showing a method of querying and loading a document into an index file in accordance with one embodiment of the present invention. At a step  102  a corpus or collection of documents that are to be compared against each other is gathered. A document can be any logical entity such as a set of files comprising one program or multiple sections (e.g. attachments) in an e-mail message. The documents in the collection can be of the same type or have different types. For example, each file is a computer program in a particular language or a database file organized according to a particular database program. At a step  104  the first or next document in the collection is selected for comparison against the documents already loaded. If it is the first document, the index file (described below) containing hash and position values is empty. In either case, in the described embodiment, a position corresponding to the beginning of the selected document is stored in a B-tree or similar structure. As described in FIG. 2, a page or block in the index file can be expanded or appended with additional pages if a current page becomes full. 
     At a step  106  the document is translated or preprocessed from its original (e.g. human readable) format to a format suitable for segmenting and hashing. For the purposes of illustrating the described embodiment, a document is referred to as a string, such as a string of alphanumeric characters. A sample string can be a string of characters comprising a sentence or a line of computer code. In the described embodiment, the string is translated to a token string that represents and preserves the structure and content of the original or raw data string. Each string (i.e. document) is translated according to its document type. Translation rules are tailored specifically for the type or types of documents being translated, such as the syntax and semantics of a particular programming language or common or frequent words expected in documents from a particular source. 
     An example of a raw data string and a translated version of the same string is shown in FIG.  3 . In that example, an English sentence is translated by having punctuation, white spaces, and capitalization removed. Further processing can include removing unimportant words such as “the” or “and.” In another example using a computer programming language, a string containing computer instructions having real variable names and operators is translated to a token string. Thus, in the described embodiment, the string: if sales_revenue &gt;operating_costs then projections=TRUE, can be translated to the token string: if &lt;var&gt;op &lt;var&gt;then &lt;var&gt;op true. In addition, in the described embodiment, the token string includes position data indicating the position of the tokens in the original document. This position data is used later in presenting the comparison data to a user. Thus, the result of translating or preprocessing is a series of token and position pairs &lt;T,P&gt; that are suitable for segmenting and hashing. In other preferred embodiments, the abstraction of the raw data string to a preprocessed data string can be performed using a variety of abstraction operations or translation sets that reduce the amount of data in the raw data string. This abstraction typically makes subsequent processing far more efficient. 
     At a step  108  the next or first substring of length l is selected and a position marker is incremented by one to indicate the beginning of the selected substring. An appropriate length l can be chosen empirically based on the type of documents that are being queried and loaded into the index file. Substring length l is the length of a substring within a translated string that is hashed and stored in the index file. The number of substrings within the translated string that is hashed is determined by an offset or gap g discussed in greater detail below and in FIG.  3 . These values, specifically 1, can be chosen based on experience working with the type of documents being hashed and loaded, or can be determined based on an intuitive or natural feeling of how many characters or words one has to see to suspect that some copying has occurred between two documents. However, in the described embodiment substring length l and offset g are each constant for all documents of a particular type that are compared against one another. Normal text documents may have a substring length in the 30 to 40 character range. For computer programs, 1 may be in the 40 to 50 character range depending on the programming language. For executable or binary files, 1 can be in the range of several hundred characters. 
     At a step  110  a hash function is applied to the selected substring within the translated string, or document. The hash function creates a hash value of a fixed length m. The hash value is stored in the index file which, in the described embodiment, is an extensible hashtable made up of a linked list of hash pages described in greater detail in FIG. 2 One purpose of using a hash function is to maintain a random distribution of hash values in the index file. Any well-behaved hash function can be used in the described embodiment. One criteria for a well-behaved hash function is not returning the same hash value for two different substrings. 
     An example of a hash function includes taking the product of a numeric representation of a character and a prime number. Each character in a substring must be part of an alphabet, such as the ASCII character set. Each member of this character set has an associated unique prime number. Another prime number, p, larger than any prime number corresponding to the character set is chosen. This number is raised to a certain power and multiplied by the prime number corresponding to a character. These products are then summed. For example, if the substring contains the prime numbers 7,3,9, the first part of the hash function would be the calculation 7p 3 +3p 2 +9p. The final hash value is the modulus of this sum by 2 32  which is the word length of the computer. This number can vary depending on the type of computer being used. In other preferred embodiments, hash functions using other formulas and calculations can be used. 
     At a step  112  the program queries the index file for the hash value calculated at step  110 . The index file will not contain any hash values to query against if the document is the first document in the collection. However, it is possible to have a substring occur more than once in a single document in which case the index file may contain a hash value to query against. As described in FIG. 2, the first n bits of the calculated hash value is used to identify a hash page in the index file. Thus, the first n bits of the current hash value are used to identify a certain hash page in the index file and that page is searched for the remaining m-n bits in the current hash value. In the described embodiment a hash page can have overflow pages associated with it that may also need to be searched. 
     At a step  114  the program stores data relating to any matches found in the index file after queried for a current hash value. In the described embodiment, a list of &lt;hash value, position&gt; pairs are stored in a temporary file. The index file stores positions of each hash value. Thus, at step  114  if a current hash value is found in the index file, the position and value stored in the index file matching the current hash value is stored in the temporary file until all the substrings in the query document (as described in step  108 ) have been hashed and searched for in the index file. In the described embodiment, a position value encodes (i.e. it does not explicitly state) the name of the document and an offset within that file where the hash value begins. Thus, this position value performs as an absolute position or address within the collection or corpus of documents insofar that it can be used to go directly to a position within a document regardless of where that document resides in the corpus of documents. If the collection of documents being compared against each other are expected to be dissimilar, step  114  will normally result in small amounts of matching data or none at all. However, this depends on the nature of the collection of documents being compared. 
     To save memory, not every substring&#39;s hash value is saved. In a preferred embodiment only those substrings beginning at or near fixed boundaries in a document (string) are saved. At a step  116  the program checks whether it has passed a particular position or boundary in the string. This position, referred to as the gth position (for example every 5th or 10th position in the string), is an offset or gap between the beginning of every new substring and the previous substring. At step  116  the program determines whether it has passed the gth position since having saved (or stored) the last hashed substring. Each time the program passes the gth position it will want to save another hash value and generally it will not want to save more than every gth substring. If the program has passed a gth position in the string, it will increment a g counter at a step  118 . 
     If the program determines that it has not passed a gth position at step  116  or if the program increments the g counter at step  118 , control goes to a step  120  where the program checks whether the g counter is greater than zero and whether the hash is 0 modulo j for a predetermined value j. In the described embodiment, j has a value that is less than g. By using 0 mod j to determine which substrings to save (described in step  122  below) in the described embodiment, the program is able to reduce the number of substring hashes that need to be queried at step  112 . Only those substrings that have a hash value that is evenly divisible by j need to be searched for in the index file. Returning to step  116 , once a gth boundary or position is passed, the program is ready to save another hash value. It will do this the next time it determines that 0 mod j is true for a hash value of the current substring. 
     At step  120 , if the g counter is greater than zero (indicating that the program is ready to save another hash value) and the hash value is evenly divisible by j, the hash value of the substring and its position in the document is saved in the index file at a step  122 . The g counter is also decremented by one at step  122 . Normally this will reset the counter to zero but it is possible that the counter was greater than one if the 0 mod j condition bad not been met within several substrings of length g. When the hash value and position are saved at step  122 , the index table may need to be updated. The size of the index file is increased if certain criteria are met. For example, if currently existing hash pages or blocks are appended with overflow pages to the point where access time for searching for a substring exceeds a predetermined value, the size of the entire index file can be doubled. This doubling of size will occur when the number of hash pages in the index file is set according to 2 n , where n is increased by one whenever the index file needs to be expanded. When this occurs, the addresses or boundaries of the newly formed hash pages change from their values before the index file was extended. The addresses of the hash pages do not change when individual hash pages are appended with overflow pages since the overall structure of the index file does not change. 
     The program checks whether the last position or character in the current document has been reached at a step  124  if it is determined at step  120  that the g counter is zero or the hash value of the substring is not evenly divisible by j. The program also goes to step  124  after saving a &lt;hash value, position&gt; pair and decrementing the counter at step  122 . If the end of the document has not been reached, control returns to step  108  where the next substring of length l is selected and the process is repeated. If the last character in the document has been read, the program performs a clustering operation that integrates or incorporates the current document into an existing cluster of documents if the program determines that the current document has a sufficient number of matches with any of the other previously loaded documents. The clustering is preferably done using the union/find operation. The union/find algorithm is a method known in the field of computer programming. Step  126  is described in greater detail in FIG.  4 . 
     Control then goes to step  128  where it is determined if there are any other documents in the collection of documents received at step  102 . If there are more documents, control goes to step  104  where the next document is selected, followed by preprocessing and the other steps described above. If the last document has been examined, the program goes to step  130  where the data relating to the matching hash values is coalesced into passages and presented to the user. This process is described in further detail in FIG.  5 . After the data has been coalesced at step  130  the comparison of the collection of documents is complete. 
     FIG. 2 is a block diagram of an index file and of records contained in the index file in accordance with one embodiment of the present invention. The index file, also referred to as a hashtable, contains a portion of a substring hash value followed by position data. In other preferred embodiments the index file can be implemented using other data storing constructs such as a neural network. For example, a neural network can be trained to recognize substrings it has seen before and a query document can then be run through the network in order to match substrings. In the described embodiment, a hash value is computed on a substring of length l (typically measured in characters) and is made up of m bits. A hash value  202  is shown at block  204 . In the described embodiment, m is 32 to 64 bits. A first portion of hash value  202  is an index  206  of length n bits, typically 8 to 16 bits, that acts as a pointer to a hashtable  208 . A value  210 , the remaining portion of hash value  202 , is stored in a hashtable record  212  in table  208 . Position data  214  is also 32 to 64 bits long and is stored following value  210 . As described above, position data  214  contains the name of the document or file that is being hashed and stored followed by the offset within the document where the substring is located. In other preferred embodiments, a non-numerical based hash function can be used to build the index file. For example, a semantic-based function where letters in a substring can be used to distribute substrings in the index file. More broadly, the index file can be seen as an association list in which substrings can be indexed to some other value. 
     In a preferred embodiment, preceding value  210  in record  212  is a single-bit field  216  that indicates whether value  210  represents a substring that appears more than once in the index file. In the described embodiment, if this bit is zero, value  210  represents only one substring in the index file, which is expected under most circumstances. That is, it is not expected that an exact duplicate of a substring appear even once in a set of documents. However, should this occur, field  216  will contain a one and a variation of record  212 , shown as a record  217  will have an additional count field  218  that will contain the number of times a substring appears in the index file. Count field  218  is followed by multiple position fields  222  each of which encodes the same data as position data  214 . 
     Index file  208  is typically comprised of multiple hash pages, an example of which is shown at  224 . In the described embodiment the number of pages is base two. Thus, there is initially one page in the index file which can expand to two, four, eight, 16, and so on, when needed. At the beginning of each page is a page header  226 . All the fields in header  226  are fields normally expected in a header for a page in a hashtable. One field worth noting is a page overflow field that indicates whether the hash page has overflow pages by containing a pointer to the first overflow page. Step  122  of FIG. 1 includes updating the index file and data structure for determining a position of a substring in a document and for storing data related to a particular document. The data structure referred to can be a B-tree type structure that contains information on which document and offset is described given a particular &lt;hash value, position&gt; pair. In other preferred embodiments, a binary tree or simple look-up table can be used to store this information. 
     Briefly, in the described embodiment, each leaf node in the B-tree contains a code indicating the name of a document and the range of bytes in that document. The B-tree can also contain the total number of hashes in a particular document. By following the nodes in the B-tree, the program can determine which document a particular position value belongs to or, similarly, the beginning and ending bytes of each document. In the described embodiment, the position value encodes the name of the document and the offset within that document where the hash value begins. This B-tree structure is used by the program to retrieve data regarding the boundaries of documents, the total number of hash values in a particular document, document type (if needed), and other related information. Thus, a position value can be inserted into the B-tree and a particular document and offset can be determined. 
     FIG. 3 is a diagram showing a transformation of a raw data string to a series of substrings of length l and gap g in accordance with one embodiment of the present invention. In a simple illustration, a raw data string  302  represents a text file such as a word processing document. Shown above string  302  are position indicators  304  that show positions  0  through  16  in string  302 . As discussed in step  106  of FIG. 1, the raw data string is preprocessed or translated to place it in a form suitable for segmenting and hashing. A translated data string  306  shows an example of how raw data string  302  can be translated. Translated string  306  is a string of characters with capitalization, white spaces, and punctuation removed. Further preprocessing of raw data string  302  could include removing words “this” and “is” under the assumption that they are words that would be used frequently anyway and would not be useful indicators of copying. 
     Substring length l and offset or gap g are then used to segment translated data string  306 . Length l can be determined empirically and can vary widely depending on the type of documents being stored for future comparison. For a normal text file  1  is typically in the range of 30 to 40 characters. Typically when a person sees this number of consecutive characters in two documents, copying is suspected. The number will likely be different for other types of documents such as computer programs or files storing records in a database. The offset or gap g between hashed substrings is determined by availability of storage and the level of success or probability in finding matches among documents. 
     For the purposes of illustration, in FIG. 3 length l is three and the offset g is two. In the described embodiment, g must be less than 1, and in most cases will be significantly smaller than 1. Brackets  308  illustrate how translated string  306  is segmented. Each segment is three characters long and each new segment begins two characters after the beginning of the previous segment. This results in six substrings  310 , which may include duplicate substrings. A hash function is applied to each of the substrings, as described in step  106  of FIG. 1, to derive a hash value  202 . Position data for each of the substrings is also stored in the index file. For example, a position value for substring “fol” encodes the name of raw data string  302  (e.g. “sample_text.doc”) and its offset within the string, which in this case is byte  11 . 
     In the example shown in FIG. 3,  1 +g is five characters long. If a second data string, i.e. a query document, is compared against data string  302  and contains a substring of length five that has the same consecutive characters as any substring of length five in string  302 , a comparison method based on a preferred embodiment will detect that three of the five characters in the substrings match. Thus, if the query document contains “thisi” or “tfolk” for example, this similarity to raw data string  302  will be detected and presented to the user. By increasing g, or l, a longer identical substring must be present in the query document in order for the comparison program to guarantee the detection of the similarity. Thus, in another example where index space is more limited and g is four instead of two (and l is greater than four), the query document would have to contain a substring (the sum of l and g) of length seven in order for the comparison program to detect the similarity. Substrings such as “thisisi” or “itfolks” would have to be present in the query document for the similarity to be detected. 
     As mentioned above with respect to step  120  of FIG. 1, in the described embodiment, the way a substring is chosen for storage in the index file depends not only on offset g but also on the condition 0 mod j criteria thereby introducing the variable j. Every hash value of the current substring that satisfies 0 mod j after having passed a g boundary in the string is stored in the index file. By using the 0 modj criteria for saving substrings, where j is relatively small compared to g, the offset or gap between each saved substring will very likely be close to g but will not be guaranteed to be g. Based on probability theory, the gap will typically vary between a few positions before and a few positions after each gth position in the string. If g is set to two and j is one, the segmenting would not be different from the segmenting shown in FIG. 3; that is, substrings would be chosen strictly by g (whenever j is set to one). In another preferred embodiment, every gth substring of length l is hashed and stored in the index file. By using this method, the program can guarantee that if there is the same passage of length l+g in two or more documents, the program will detect a same passage of length l. 
     FIG. 4 a  is a flowchart showing in greater detail step  126  of FIG. 1 b  in which a current document is clustered based on matches with documents previously loaded into the index file. The input for a step  402  is a list of matches that was created at step  114  of FIG. 1 a . FIG. 4 b  is an illustration of a format of a match list in accordance with one embodiment of the present invention. In the described embodiment, this list contains at least three items of information: a hash value  210 , its position  214  in the current document, and a list of positions 0 i  in other (previously indexed) documents that have the same hash value  214 . However, it is possible that a hash value may appear two or more times in the same document and may have been stored in the index file. In this case, the matching  0   i  position represents a position in the same document as opposed to the more typical situation of representing another document. The hash value and position pair is shown in FIG. 4 b  as tuple  416 . Associated with tuple  416  is a list  418  containing at least one position value 0 1 , shown as item  420 , indicating a position in another document that contains the same hash value  210 . The current document can have other hash values that were also matched with hash values in other documents represented by tuples  422  and their corresponding position lists. 
     At step  402  each list is expanded into pairs or tuples in which hash values have been eliminated and that contain only position values. FIG. 4 b  also shows an expanded position list  424  created at step  402 . This list is created by pairing each position in the current document with each matching position  0   i  in other documents. List  424  includes a series of tuples where each tuple  426  has a position value  214  from the current document and a position value  420  from another document. However, as mentioned earlier, it is possible that a hash value may appear two or more times in the same document and may have been stored in the index file. In this case, the matching 0 i  position represents a position in the same document as opposed to the more typical situation of representing another document. Thus, in each list  424 , position value  214  of the current document will be the same but the position values 0 i  from the other documents will be different. This is done for all position values in the current document that have matches in other documents. Typically, in applications where the documents are not expected to have many similar passages, these lists are not very long and can be stored in main memory for quick access. 
     At a step  404  the expanded list of pairs  424  created at step  402  is sorted based on the position values  420  indicating matching positions in the other documents. This creates a single list of tuples sorted such that position values  0   i  from a single other document (i.e. a document that has already been indexed) are grouped together sequentially in the list. FIG. 4 b  contains an illustration of a list sorted according to position values in other documents. As shown in a list  428 , position values  420  are increasing. As a result, position values from the current document become unordered or random. At a step  406 , list  428  is segmented where each segment  430 , for example, represents a single document. In the described embodiment, the segmenting is done using the B-tree described above. Using the B-tree, which contains the beginning and ending positions of documents stored in the index file, the program can determine where the boundaries of the documents are in the sorted list. 
     At a step  408  the program retrieves a segment, representing a single document, from the sorted list. At a step  410 , a ratio C/T is computed for the retrieved document. The similarity of two documents is defined as ratio C/T, where C is the number of hashes the two documents have in common and T is the total number of hashes taken of one of the documents, which can be the current document or the smaller document. In the described embodiment, the number of hashes the two documents have in common is equal to the number of position pairs in the segment representing the retrieved document. The total number of hashes T can be drawn from the B-tree which also stores the total number of hashes in each document. By using this ratio, the percentage similarity between the current document and the document chosen at step  408  from the sorted segment list can be calculated. 
     At a step  412  a threshold is used to discard the retrieved document if the document does not contain a certain match ratio. In the described embodiment, if C/T is less than the threshold (e.g. a predetermined system parameter), the matches associated with the retrieved document are discarded, thereby effectively eliminating the document from further analysis. By performing this filtering operation, only documents having an interesting or significant number of matches with the current document are retained. The value of the threshold is based on a policy decision as to what level of similarity is significant given external factors, such as the type of documents being compared. Thus, at step  412  the program determines if the retrieved document has a sufficient number of matches. If not, control returns to step  408  where the next document segment in the sorted list is retrieved. If the number of matches in the retrieved document is significant, control goes to a step  414 . 
     At step  414 , the program clusters the retrieved document with existing clusters of documents. The purpose for clustering is to determine whether there are other groups of documents of which the current document can be part based on similarities. In the described embodiment, the clustering is used to present in a meaningful way to the user passages of similar text from groups of documents where each group is expected to have at least some similar passages. If the current document is not grouped with an existing cluster, it creates its own single-document cluster, which can subsequently be clustered with incoming documents and existing clusters. In another preferred embodiment the clustering can be done after all the documents in the collection have been indexed, which can be referred to as batch clustering as opposed to incremental clustering described above. 
     FIG. 4 c  is an illustration of a data structure showing how documents can be clustered in accordance with one embodiment of the present invention. Shown are three clusters  432 ,  434 , and  436 . A current document  438  is brought in. The clustering operation may be performed using a standard union/find algorithm where the program first determines to which set or existing cluster the document belongs. The program then takes the union of the current document and the set of retrieved documents (i.e. those documents retrieved at step  408 ). This can be done by taking a representative element or document from an existing set or cluster and comparing it to the current document. If the element in the current document is found in the cluster, the document can be unioned with the cluster. The two previously existing sets (the current document being one set) are eliminated and a new cluster is formed. This is a well-known procedure and can be done in nearly linear time. The union either results in the current document being joined or clustered with a set of retrieved documents or, if there is no union, a new single-document cluster made up of the current document. It is also possible that the current document belongs to two or more existing clusters in which case the clusters are joined to form yet a larger cluster of documents. 
     FIG. 5 is a flowchart showing in greater detail step  130  of FIG. 1 b  of coalescing matching substrings into passages and presenting output to users in accordance with one embodiment of the present invention. For the purpose of illustrating a preferred embodiment of the coalescing operation of the present invention, a cluster containing two documents is described. The methods and techniques described below for a cluster of two documents can be extended to coalesce documents in a cluster containing multiple documents, and is not intended to be limited to clusters of a pair of documents. 
     The coalescing procedure operates on a cluster of documents that was formed at step  414  of FIG. 4 a  and shown in FIG. 4 c . Thus, documents that are potentially coalesced are those documents from a single cluster. At a step  502 , one is selected (the “current cluster”) from the group of clusters. In the described embodiment, the data structure representing the clusters can be kept in main memory instead of on disk given the typically small amounts of memory needed to store cluster data, although the size can vary according to the application and type of documents being compared. The coalescing operation is performed on a cluster because a cluster is a much smaller set of documents compared to the potentially huge collection of documents and are far more likely to have significant similarity. In another preferred embodiment, the coalescing operation can be performed without the clustering procedure thereby using the original full set of documents. This may be preferred if the original set of documents is small. At a step  504  the program flags all substrings that appear more than once in a document in order to process duplicate passages (appearing two or more times) in a document more efficiently. This is done by examining the hash values encoded in the 0&#39;s. At a step  506  the program finds all sequences of unique position pairs among all the documents in the current cluster and coalesces those pairs into longer segments. This operation begins by examining the sorted list created in steps  404  and  406  of FIG. 4 a  and illustrated in FIG. 4 b , where the list of position pairs are sorted according to previously indexed documents (0 i  values). At step  406  the sorted list is segmented into documents that have already been loaded in to the index file (i.e. hashtable). 
     Step  506  is performed by first checking each position (e.g., value  420  in FIG. 4 b ) in the sorted list corresponding to the documents in the current cluster. For each position pair in the sorted list, the program checks whether the 0 i  values  418  are in sequence by referring to the B-tree. In order to be in sequence, a value 0 +1  should not precede 0 i . Thus, the program scans the sorted list and determines whether the next 0 i  position in the list is adjacent to the current 0 i  position. Since the length l is fixed, adjacency can be determined to be true if 0 i ≧0 i+1 −l. This calculation indicates whether the two current 0 i  positions are adjacent (or overlapping), or whether there is a gap or disjoint between them. Data in the B-tree can be used to determine the values for the 0 positions. If the difference between those values is equal to or less than l, they are considered to be in sequence. Similarly, each P position (e.g., value  214  in FIGS. 2 and 4 b ) in the position pair is examined to see if it is in sequence with the P position in the next position pair, and whether the differences in length is the same as the difference in length between the 0 positions. In the described embodiment, this can be done by checking whether 0 i −0 i+1 =p i −p i+1 . If these conditions are met, the program coalesces position pairs to form a single position pair with an associated length where the length is greater than l depending on how many position pairs we e found to be in sequence. Thus, the resulting list of position pairs will likely have fewer position pairs than the original sorted list and some of the pairs will have an associated length value greater than l. This check can be extended to cover situations where the program detects similarities among three of more documents (in addition to or to the exclusion of detecting similarities between two documents). This can be done by checking whether 0 i −0 i+1 =p i −p i+1 =N i −N i+1 , where N represents a third document in the cluster. 
     At a step  508  pairs of passages that overlap are identified and split up for all documents in the current cluster. The purpose of step  508  is to eliminate overlapping pairs that have the same offsets (i.e. overlap the same amount) between two documents by segmenting the overlapping pairs into  10  three non-overlapping passages. This step simplifies processing since at this stage all disjoints in the string are eliminated. This is conveyed by the conditions described above with respect to step  506  (i.e. by checking if 0 i ≦0 i+1 −l, and whether 0 i −0 i+1 =p i −p i+1 ). Thus, every instance where the program detects the same overlapping pairs, the two overlapping passages are replaced with three segments: a first segment that consists of only the first passage, a second segment that corresponds only to the overlapping section, and a third segment that consists only of the remaining portion of the second passage. A new name is assigned to the middle overlapping portion and the hash values for the two segments are reassigned to the (now shorter) non-overlapping sections. 
     This is done by first scanning the sorted list (sorted by 0 i ) and making note of all places where there are overlapping 0 i &#39;s by examining their positions in the B-tree. In another preferred embodiment, the difference between 0 i+1  and 0 i  can be determined and compared to l. If the difference is less than or equal to 1, the segments overlap. This information is stored in a temporary data structure. The information is used to replace all instances of the overlapping passages with the three new passages. The program searches the index file for the hash value of the first passage. Once it is found, record  212  of FIG. 2 will indicate all the positions that the hash value occurs in the corpus of documents. Those positions that fall within any of the documents in the current cluster are replaced with the new hash values. 
     A similar procedure is applied to the P positions in the sorted list. First, the list is sorted based on p, instead of 0. The program then checks for overlaps in P by using position data in the B-tree. Similarly, in other preferred embodiments, overlaps in P can be determined by comparing the difference between p i −p i+1  to l since the position pairs have been segmented into documents and the program is checking for overlaps within a single document. For those overlaps that have the same offset as overlaps in the 0 positions, the information stored in the temporary data structure is used to replace the overlapping P passages. Since other position pairs may contain the P value being changed, the P value in those pairs are changed as well to keep the value consistent. In the described embodiment, the temporary data structure maps hash values of segments to positions of those segments in a document. 
     At a step  510  filler or dummy passages are inserted to fill any gaps between passages. This is done for each document in the current cluster to facilitate subsequent string operations. This gap should not be interpreted by the program to mean that the first pair and the pair following the gap are adjacent. The purpose is to create a continuous string of non-overlapping segments or passages. Step  510  further simplifies the string transforming it to an abstract of the original document. In the described embodiment, each filler passage is sized to exactly fit each gap in the sequence of passages making up a document. 
     At a step  512  the program finds the maximum length passage that matches between the two documents in the current cluster and then removes that passage. In the described embodiment, the steps preceding step  512  in FIG. 5 transform the documents in a cluster into efficient and manipulable strings of segments that can now be processed to detect similar passages. Because the documents have been simplified to the form of these strings, the problem of identifying similar passages has been substantially reduced. In the described embodiment, the program focuses attention on a few documents (i.e., a cluster) that actually do have some common material out of a potentially large collection of documents. 
     One method of performing step  512  is a brute force algorithm that keeps a marker and counter for the two documents or strings. For example, for the two strings: 
     
       
         
           
               
               
               
             
               
                   
                   
               
             
            
               
                   
                 string 1: 
                 HFLKXAB 
               
               
                   
                 string 2: 
                 ABZFLKW 
               
               
                   
                   
               
            
           
         
       
     
     the program first places a marker at H in string  1  and checks if there is an H in string  2 . In this case there is no H in string  2  so the counter is zero. The marker is then moved to F in string  1  and the program will increase the counter to one when it hits the first F in string  2 . The marker will then read the L in string  1 , match it with the L in string  2 , and increase the counter to two. After reading the K in both strings, the counter will be increased to three (the counter is incremented when the sequence of characters is the same). The program continues until the end of the strings and notes that the longest substring was three. The FLK substring is assigned a new identifier, such as a unique number or letter, and is then removed or flagged to indicate that it has already been examined, so the program can perform a step  514 . In another preferred embodiment, the edit difference between the strings can be computed and from that the maximal matching passages can be derived. This method can be used in place of the brute force algorithm described above or in conjunction with it. An “edit distance” between two documents, or strings, is the length of a minimal sequence of insertions, deletions, and substitutions that transforms one to the other. 
     At step  514  the same process is repeated for successively non-increasing length matches until the length of the matches decrements to single characters. Thus, the program would then detect the AB passage in the two strings and assign a unique identifier to it. In the described embodiment, all characters that had no matches, such as H or W in string  2 , keep as their identifier their original hash values. Thus, assuming the following identifiers for the passages in the two strings: 
     
       
         
           
               
               
               
               
               
             
               
                   
                   
               
             
            
               
                   
                 H: 
                 h 
                 Z: 
                 z 
               
               
                   
                 FLK: 
                 m 
                 W: 
                 w 
               
               
                   
                 X: 
                 x 
               
               
                   
                 AB: 
                 i 
               
               
                   
                   
               
            
           
         
       
     
     the strings can be represented as: “hmxi” and “izmw”. Thus, the strings on which matching is now performed have letters as identifiers that represent many more characters in the original document. Each of the identifiers in these strings have associated position and length information. 
     After step  514 , the program can use more expensive techniques on these simplified strings to present similar passages to the user at a step  516 . In a preferred embodiment, each lower case letter in the two strings can be represented by a color. The text represented by those passages are presented to the user in a particular color and the user can compare passages that have the color in two or more documents to see actual text and the location of the text that appears in those documents. For example, with the two strings above, the passage FLK can be shown in red in both documents and the passage AB can be shown in blue. The user can then determine quickly what passages are the same in the two documents. In other preferred embodiments, other indicators can be used to efficiently present similar passages in the documents to the user. For example, similarities among documents can be shown using graphical summaries, such as colored histograms or multiple color bars, which correspond to the colored text described above. In addition, passages from multiple documents can be aggregated in different ways depending on the user interface and user needs. For example, information on a subset of documents within a cluster can be presented to a user in cases where information on the full set of documents would be skewed. This can occur because of one unusual document in the cluster having properties that throw off similarities present in the other documents, where those similarities may be more informative to the user. At a step  518  the program retrieves the next cluster of documents as derived in step  414  of FIG. 4 a  and repeats the process from step  502 . If there are no more clusters the process is done. 
     In other preferred embodiments of the present invention, the comparison program has a user interface (“UT”) component. The UI of the present invention displays output results of a comparison between two or more documents. The UI includes numerous display frames of which there are typically at least three, one for displaying overview bars and two frames for the minimum two documents being compared with one another. The output of the document comparison program is displayed to the user in a visually meaningful manner that allows the user to quickly evaluate the results of the comparison and examine portions of text that match. In the described embodiment, the use of color to indicate portions of text that match between documents allows the user to see where the matching portions are relative to each document. It also allows the user to see the relative length of the matching portion and to go directly to the particular matching portion by “clicking” on the colored portion of the overview bar, as described below. 
     FIG. 6 is an illustration of a screen shot of the user interface associated with the comparison program in accordance with one embodiment of the present invention. As mentioned above, the UI screen is divided into three or more frames. The screen shot in FIG. 6 has three frames: overview bar frame  602 , a first document content frame  604 , and a second document content frame  606 . In another preferred embodiment, there can be additional document content frames displayed, for example, to the right of frame  606 . The user can view those frames by scrolling to the right or left side of the screen. 
     Frame  602  contains two overview bars  608  and  610 . Each overview bar corresponds to a document and is identified by the location (e.g. path) and name of the document. Frame  604  contains the actual content of a Document A. Document A has numerous content segments (e.g. paragraphs in a written report, methods in a computer program, etc.). Frame  606  contains a Document B which was compared to Document A. Document B is also made up of numerous content segments. The content segments in both documents are shown to illustrate features of the user interface and do not necessarily represent logical “segments” of content when each document is viewed individually. 
     Returning to overview bar frame  602 , in the described embodiment, color is used to show matching content between the documents. Overview bar  608 , corresponding to Document A, contains numerous sub-bands of varying width, such as bands  612 A,  614 A, and  616 A. Similarly, overview bar  610  for Document B also contains numerous sub-bands of varying width, such as bands  612 B,  614 B, and  616 B. Each overview bar represents the length of a document. Each of the sub-bands represents a portion of content in a document and is assigned a color other than the default color of the bar (e.g. gray or white). The portions of text represented by the sub-bands contain text that has a match in the other document(s). The space between the sub-bands represent content that does not match. For example, sub-band  612 A corresponds to text segment  618 A in Document A and sub-band  612 B corresponds to text segment  618 B in Document B. Notice that segments  618 A and  618 B match each other. Because they match, they are assigned the same color, such as blue (i.e., the text itself is blue instead of the normal black lettering). Sub-bands  612 A and  612 B are also filled in with blue. Since text segment  618 B is a little further down in Document B than segment  618 A is in Document A, sub-band  612 B is slightly further down in the overview bar than band  612 A. This is also illustrated by sub-bands  614 A and  614 B and  616 A and  616 B. For example, Content Segment  4  in Document A matches Segment  4  in Document B and, thus, are assigned the same color, such as green. Its corresponding sub-bands  616 A and  616 B (the third sub-band in the overview bar since Segment  4  is the third matching content segment) are also assigned green. In other embodiments, other visual aids such as symbols, shapes, or icons can be used to show matching text and sub-bands. 
     Overview bars  608  and  610  have lengths proportional to the length of their respective documents. In FIG. 6 Document A is longer than Document B as indicated by the length of the bars. If Document A were twice as long as Document B, bar  608  would be twice as long as bar  610 . Also related to the scale of the overview bars, color and links (described below) for matching content segments are added to each bar at the corresponding positions in the bars. For example, if a run or segment colored red extends from position  10  to  20  in Document A, and bar  608  is a 100 units long, the portion from unit  10  to unit  20  is colored red in the overview bar. This same concept of proportionately coloring the overview bar also applies to other overview bars in frame  602 . By coloring the bars proportionately, the user can quickly see the comparative size of matching segments and their sizes compared to the entire document. 
     Another aspect of the UI of the present invention are the links between the sub-bands and the matching text in the documents. Some of these links are shown by dashed arrows  620 ,  622 , and  624 . These links allow a user to bring into “focus” matching text in another document. For example, while examining text in Document A, a user reaches Content Segment  1  and notices it is colored, e.g. red. Typically, the user will want to see the matching text segment in Document B and compare the two segments side-by-side. In the described embodiment, the user can click on the colored text in Document A and bring up to the top portion of frame  606  Content Segment  1  in Document B so that the two segments are aligned for the user to visually compare. This can be particularly useful when large documents are being compared and matching segments are scattered throughout each document. It allows the user to quickly bring into focus matching text segments. 
     There are also links between the sub-bands and the content segments. These are links between sub-bands in an overview bar and the corresponding text segment in the document associated with the overview bar. For example, if a user places the cursor on sub-band  614 B and clicks on it, Content Segment  1  in Document B is brought up to the top (into focus) in frame  606 . This allows the user to examine the overview bar for a document, select a sub-band, and bring up the content associated with the sub-band for easy viewing. In another preferred embodiment, clicking on sub-band  614 B can also bring up the matching text segment (Content Segment  1 ) in Document A as well as in Document B. This would require a link between sub-bands in overview bar  610  and Document A. These links and the links described above allow a user to quickly bring up matching text segments and align them to facilitate visual comparison by the user. 
     In the described embodiment, the links are implemented using HTML hyperlinks. The UI is used in a browser context which allows the use of HTML commands such as “href” for creating hyperlinks between pages within the same document or between different documents. In the described embodiment, the UI is a set of static HTML pages. In other embodiments, other formats can be used, such as generating color postscript to printout. Using an HTML hyperlink for a specified byte range, such as the byte range for  618 A in Document A, makes the byte range of text active; thus, when it is clicked on by the user, it causes the matching text in Document B ( 618 B) to come into focus. Similarly, the byte range for segment  618 B is hyperlinked (line  620 ) to byte range  618 A in Document A. In the UI of the present invention, the documents are displayed in the two side-by-side frames. In other embodiments, alternative frame configurations can be used depending on the needs of the users. If more than two documents are displayed side-by-side, the hyperlink from one matching content segment should change the focus in all the other documents or frames. For example, if there are three documents A, B, and C, clicking a matching segment in A will cause the focus to move to the corresponding matching segments in both documents B and C in their respective frames. The use of HTML hyperlinks is well-known in the field of computer and Internet programming and one of ordinary skill in these fields can implement hyperlinks in this content. 
     FIG. 7 is a flow diagram of a process of creating a user interface for a document comparison program in accordance with one embodiment of the present invention. A process for creating and presenting the user interface of the described embodiment is performed once the comparison program has created a series of disjoint or non-overlapping passages (also referred to as position pairs wherein a position pair is the start and end positions in Documents A and B). A series of disjoint passages is created after step  510  of FIG.  5 . At that stage, an overlapping segment of two passages is effectively disjoined from both passages and treated as a separate passage. Thus, two overlapping passages become three non-overlapping passages. A single passage, r i =&lt;0 i , 0 i+1 ), P i , P i+i &gt;, where O i  is a start position of the passage in a first document (e.g. Document A) and 0 i+1  is an end position of the passage in the first document. The P variables have similar values for a second document (e.g. Document B). Thus, the same passage or run r i  in two or more documents represents a segment of text or content that matches and, consequently, are given the same color and appropriate links as described above. By using passages that do not overlap, each passage can be assigned one color. 
     At a step  702  a passage, r i , is selected from the series of non-overlapping passages. As described in FIG. 5, a document is segmented into a series of runs or passages of content that matches a passage in another document. A passage is represented by two pairs of offsets (typically measured in bytes) where each pair is a beginning offset measured from the first byte of the document and an end offset. The difference between the two offsets is the length of the passage. Once a passage is selected, at a step  704  a color, for example red, is assigned to the passage. This color is then used to represent the passage both in the overview bars and in the text of the documents as described below. If necessary, the same color can be used to represent different passages, such as when there are many matching paragraphs and a linked number of colors. In this case it is preferable to keep the same color separated by as many passages as possible to maintain an effective visual appearance of the overview bars to the user. 
     At a step  706  the same color is assigned to the segment of content in Documents A and B that correspond to the selected passage and to the sub-bands in the overview bars. Although this step is described after step  704 , the operations associated with each can be performed concurrently or in an order different from that of the described embodiment. The colors and hyperlinks, discussed below, can be assigned to the segments and sub-bands at different times without effecting the overall configuration of the UI as described in FIG.  6 . After step  706 , the sub-bands and content segments have been assigned the same color. At a step  708  links are added between each sub-band and its corresponding text and between matching text segments in the documents (e.g. link  618 ). As described above, the links can be HTML hypertext links which activate a section of text or other area on the screen, such as a sub-band within an overview bar. 
     At a step  710  the necessary frames to display the overview bars and content of the documents being compared are generated and configured on the screen. In the described embodiment, there are three frames displayed in the UI as shown in FIG.  6 . In another preferred embodiment, only one frame containing overview bars can be shown in the initial UI if there are many documents being compared. In this case it may be desirable to the user to see the overview bars for all the documents first and bring up frames containing text of documents as selected by the user after examining the overview bars. Pulling up the documents selected by the user can also be achieved using hyperlinks associating a sub-band in a particular overview bar with a document. 
     Once the frames are created and configured on the screen, the user can begin interacting with the interface. Typically, the user&#39;s attention will first be drawn to the frame containing the overview bars. The multi-colored overview bars allow a user to quickly evaluate the results of a comparison and decide which segments in which documents might be of interest. As described above, the user c an easily pull up the matching segments in the documents by clicking on either the colored sub-bands or th e colored text in the documents with a pointer device such as a mouse or track pad. In the configuration of the described embodiment, the matching segments of data in the different documents are displayed side-by-side so the user can visually compare the matching segments. 
     The present invention also relates to a device, system or apparatus for performing the aforementioned operations. The system may be specially constructed for the required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. The processes presented above are not inherently related to any particular computer or other computing apparatus. In particular, various general purpose computers may be used with programs written in accordance with the teachings herein, or, alternatively, it may be more convenient to construct a more specialized computer system to perform the required operations. 
     FIG. 8 is a block diagram of a general purpose computer system  800  suitable for carrying out the processing in accordance with one embodiment of the present invention. FIG. 8 illustrates one embodiment of a general purpose computer system. Other computer system architectures and configurations can be used for carrying out the processing of the present invention. Computer system  800 , made up of various subsystems described below, includes at least one microprocessor subsystem (also referred to as a central processing unit, or CPU)  802 . That is, CPU  802  can be implemented by a single-chip processor or by multiple processors. CPU  802  is a general purpose digital processor which controls the operation of the computer system  800 . Using instructions retrieved from memory, the CPU  802  controls the reception and manipulation of input data, and the output and display of data on output devices. 
     CPU  802  is coupled bi-directionally with a first primary storage  804 , typically a random access memory (RAM), and uni-directionally with a second primary storage area  806 , typically a read-only memory (ROM), via a memory bus  808 . As is well known in the art, primary storage  804  can be used as a general storage area and as scratch-pad memory, and can also be used to store input data and processed data. It can also store programming instructions and data, in the form of message stores or shared allocated memory holding thread-specific data cells, in addition to other data and instructions for processes operating on CPU  802 , and is used typically used for fast transfer of data and instructions in a bi-directional manner over the memory bus  808 . Also as well known in the art, primary storage  806  typically includes basic operating instructions, program code, data and objects used by the CPU  802  to perform its functions. Primary storage devices  804  and  806  may include any suitable computer-readable storage media, described below, depending on whether, for example, data access needs to be bi-directional or uni-directional. CPU  802  can also directly and very rapidly retrieve and store frequently needed data in a cache memory  810 . 
     A removable mass storage device  812  provides additional data storage capacity for the computer system  800 , and is coupled either bi-directionally or uni-directionally to CPU  802  via a peripheral bus  814 . For example, a specific removable mass storage device commonly known as a CD-ROM typically passes data uni-directionally to the CPU  802 , whereas a floppy disk can pass data bi-directionally to the CPU  802 . Storage  812  may also include computer-readable media such as magnetic tape, flash memory, signals embodied on a carrier wave, PC-CARDS, portable mass storage devices, holographic storage devices, and other storage devices. A fixed mass storage  816  also provides additional data storage capacity and is coupled bi-directionally to CPU  802  via peripheral bus  814 . The most common example of mass storage  816  is a hard disk drive. Generally, access to these media is slower than access to primary storages  804  and  806 . Mass storage  812  and  816  generally store additional programming instructions, data, and the like that typically are not in active use by the CPU  802 . It will be appreciated that the information retained within mass storage  812  and  816  may be incorporated, if needed, in standard fashion as part of primary storage  804  (e.g. RAM) as virtual memory. 
     In addition to providing CPU  802  access to storage subsystems, the peripheral bus  814  is used to provide access other subsystems and devices as well. In the described embodiment, these include a display monitor  818  and adapter  820 , a printer device  822 , a network interface  824 , an auxiliary input/output device interface  826 , a sound card  828  and speakers  830 , and other subsystems as needed. 
     The network interface  824  allows CPU  802  to be coupled to another computer, computer network, or telecommunications network using a network connection as shown. Through the network interface  824 , it is contemplated that the CPU  802  might receive information, e.g., data objects or program instructions, from another network, or might output information to another network in the course of performing the above-described method steps. Information, often represented as a sequence of instructions to be executed on a CPU, may be received from and outputted to another network, for example, in the form of a computer data signal embodied in a carrier wave. An interface card or similar device and appropriate software implemented by CPU  802  can be used to connect the computer system  800  to an external network and transfer data according to standard protocols. That is, method embodiments of the present invention may execute solely upon CPU  802 , or may be performed across a network such as the Internet, intranet networks, or local area networks, in conjunction with a remote CPU that shares a portion of the processing. Additional mass storage devices (not shown) may also be connected to CPU  802  through network interface  824 . 
     Auxiliary I/O device interface  826  represents general and customized interfaces that allow the CPU  802  to send and, more typically, receive data from other devices such as microphones, touch-sensitive displays, transducer card readers, tape readers, voice or handwriting recognizers, biometrics readers, cameras, portable mass storage devices, and other computers. 
     Also coupled to the CPU  802  is a keyboard controller  832  via a local bus  834  for receiving input from a keyboard  836  or a pointer device  838 , and sending decoded symbols from the keyboard  836  or pointer device  838  to the CPU  802 . The pointer device may be a mouse, stylus, track ball, or tablet, and is useful for interacting with a graphical user interface. 
     In addition, embodiments of the present invention further relate to computer storage products with a computer readable medium that contain program code for performing various computer-implemented operations. The computer-readable medium is any data storage device that can store data which can thereafter be read by a computer system. The media and program code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known to those of ordinary skill in the computer software arts. Examples of computer-readable media include, but are not limited to, all the media mentioned above: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and specially configured hardware devices such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and ROM and RAM devices. The computer-readable medium can also be distributed as a data signal embodied in a carrier wave over a network of coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion. Examples of program code include both machine code, as produced, for example, by a compiler, or files containing higher level code that may be executed using an interpreter. 
     It will be appreciated by those skilled in the art that the above described hardware and software elements are of standard design and construction. Other computer systems suitable for use with the invention may include additional or fewer subsystems. In addition, memory bus  808 , peripheral bus  814 , and local bus  834  are illustrative of any interconnection scheme serving to link the subsystems. For example, a local bus could be used to connect the CPU to fixed mass storage  816  and display adapter  820 . The computer system shown in FIG. 8 is but an example of a computer system suitable for use with the invention. Other computer architectures having different configurations of subsystems may also be utilized. 
     Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Furthermore, it should be noted that there are alternative ways of displaying and using the user interface of the present invention. For example, links other than HTML hypertext links can be used to associate the sub-bands with passages and passages with other matching passages. The documents can also be displayed in other formats instead of the side-by-side configuration shown in FIG.  6 . In another example, only one frame is displayed in the user interface for displaying overview bars of many documents being compared with each other. In another example, indicators other than color can be used to distiguish text and sub-bands. Similarly, graphical representations other than an overview bar can be used to represent a document, such as a “pie” chart or graph. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.