the present invention will be understood more fully from the detailed description given below and from the accompanying drawings of the preferred embodiment of the invention , which , however , should not be taken to limit the invention to the specific embodiment but are for explanation and understanding only . the present invention takes a different approach to plagiarism detection than the programs described previously . the present invention compares features of each pair of source code files completely , rather than using a sampling method for comparing a small number of hashed samples of code . this may require a computer program that implements the present invention to run for hours or in some cases days to find plagiarism among large sets of large files . given the stakes in many intellectual property theft cases , this more accurate method is worth the processing time involved . and it is certainly less expensive than hiring experts on an hourly basis to manually pore over code by hand . the present invention makes use of a basic knowledge of programming languages and program structures to simplify the matching task . there is a small amount of information needed in the form of a list of common programming language statements that the present invention must recognize . this list is specific to the programming language being examined . in addition , the present invention needs information on characters that are used to identify comments and characters that are used as separators . the present invention uses five algorithms to find plagiarism : source line matching , comment line matching , word matching , partial word matching , and semantic sequence matching . each algorithm is useful in finding different clues to plagiarism that the other algorithms may miss . by using all five algorithms , chances of missing plagiarized code is significantly diminished . before any of the algorithm processing takes place , some preprocessing is done to create string arrays . each file is represented by three arrays — an array of source lines that consists of lines of functional source code and does not include comments , an array of comment lines that do not include functional source code , and an array of identifiers found in the course code . identifiers include variable names , constant names , function names , and any other words that are not keywords of the programming language . in one embodiment of the present invention , each line of each file is initially examined and two string arrays for each file are created : sourcelines 1 [ ], commentlines 1 [ ] and sourcelines 2 [ ], commentlines 2 [ ] are the source lines and comment lines for file 1 and file 2 respectively . examples of these arrays are shown for a sample code snippet in fig6 . a sample snippet of a source code file to be examined is shown in part ( a ) 601 . the separation of source lines and comments lines for the code snippet is shown in part ( b ) 602 . note that whitespace is not removed entirely , but rather all sequences of whitespace characters are replaced by a single space in both source lines and comment lines . in this way , the individual words are preserved in the strings . separator characters such as {, }, and ; are treated as whitespace . the comment characters themselves , in this case /*, */, and //, are stripped off from the comments . we are only interested in the content of each comment but not the layout of the comment . special characters such as comment delimiters and separator characters are defined in a language definition file that is input to this embodiment of the present invention . note that blank lines are preserved as null strings in the array . this is done so that the index in each array corresponds to the line number in the original file and matching lines can easily be mapped back to their original files . next the source lines are examined from each file to obtain a list of all words in the source code that are not programming language keywords , as shown in part ( c ) 603 of fig6 . note that identifier j is not listed as an identifier because all 1 - character words are ignored as too common to consider . at this point , this embodiment of the present invention is ready to begin applying the matching algorithms . for each file pair , this embodiment of the present invention uses a “ word matching ” algorithm to count the number of matching identifiers — identifiers being words that are not programming language keywords . in order to determine whether a word is a programming language keyword , comparison is done with a list of known programming language keywords . for example , the word “ while ” in a c source code file would be ignored as a keyword by this algorithm . in some programming languages like c and java , keywords are case sensitive . in other programming languages like basic , keywords are not case sensitive . this embodiment has a switch to turn case sensitivity on or off depending on the programming language being examined . so for a case sensitive language like c , the word “ while ” would not be considered a language keyword and would not be ignored . in a case insensitive language like basic , the word “ while ” would be considered a language keyword and would be ignored . in either case , when comparing non - keyword words in the file pairs , case is ignored so that the word “ index ” in one file would be matched with the word “ index ” in the other . this case - insensitive comparison is done to prevent being fooled by simple case changes in plagiarized code in an attempt to avoid detection . this simple comparison yields a number w representing the number of matching identifier words in the source code of the pair of files . this number is determined by the equation w = σ ( a i + f n n i ) for i = 1 to m w where m w is the number of case - insensitive matching non - keyword words in the two files , a i is the number of matching alphabetical characters in matching word i , n i is the number of matching numerals in matching word i , and f n is a fractional value given to matching numerals in a matching word . the reason for this fractional value is that alphabetical characters are less likely to match by chance , but numerals may match simply because they represent common mathematical constants — the value of pi for example — rather than because of plagiarism . longer sequences of letters and / or numerals have a smaller probability of matching by chance and therefore deserve more consideration as potential plagiarism . this algorithm tends to uncover code where common identifier names are used for variables , constants , and functions , implying that the code was plagiarized . since this algorithm only eliminates standard programming language statements , common library routines that are used on both files will produce a high value of w . code that uses a large number of the same library routines also has a higher chance of being plagiarized code . the “ partial word matching ” algorithm examines each identifier ( non - keyword ) word in the source code of one file of a file pair and finds all words that match a sequence within one or more non - keyword words in the other file of a file pair . like the word matching algorithm , this one is also case insensitive . this algorithm is illustrated in fig7 . in part ( a ) 701 , the non - keyword words from the two files are displayed . in part ( b ) 702 , every word from one file that can be found as a sequence within a word from the other file is listed . so the identifier “ abc ” in file 1 can be found within identifiers “ aabc ”, “ abc1111111 ”, and “ abcxxxyz ” in file 2 . note that identifier “ pdq ” is not listed in the array of partially matching words because it matches completely and was already considered in the word matching algorithm . also note that identifier “ x ” is not listed in the array because 1 - character words are ignored . this algorithm works just like the word match algorithm on the list of partially matching words . it yields a number p representing the number of partially matching identifier words in the source code of the pair of files . this number is determined by the equation p = σ ( a i + f n n i ) for i = 1 to m p where m p is the number of case - insensitive matching partial words in the two files , a i is the number of matching alphabetical characters in matching partial word i , n i is the number of matching numerals in matching partial word i , and f n is a fractional value given to matching numbers in a matching partial word . the “ source line matching ” algorithm compares each line of source code from both files , ignoring case . we refer to functional program language lines as source lines and exclude comment lines . also , sequences of whitespace are converted to single spaces so that the syntax structure of the line is preserved . note that a line of source code may have a comment at the end , in which case the comment is stripped off for this comparison . source lines that contain only programming language keywords are not examined . for source lines to be considered matches , they must contain at least one non - keyword such as a variable name or function name . otherwise , lines containing basic operations would be reported as matching . fig8 illustrates this algorithm . part ( a ) 801 shows the lines of two files along with line numbers . part ( b ) 802 shows the source line numbers in the two files that are considered matching . this algorithm yields a number s representing the number of matching source lines in the pair of files . the “ comment line matching ” algorithm compares each line of comments from both files , again ignoring case . note that a line of source code may have a comment at the end . the source code is stripped off for this comparison , leaving only the comment . the entire comment is compared , regardless of whether there are keywords in the comment or not . fig9 shows two files along with line numbers and the comment lines that are considered matching . part ( a ) 901 shows the lines of two files along with line numbers . part ( b ) 902 shows the comment line numbers in the two files that are considered matching . this algorithm yields a number c representing the number of matching comment lines in the pair of files . the “ semantic sequence ” algorithm compares the first word of every source line in the pair of files , ignoring blank lines and comment lines . this algorithm finds sequences of code that appear to perform the same functions despite changed comments and identifier names . the algorithm finds the longest common semantic sequence within both files . look at the example code in fig9 part ( a ) 901 . in this case , the semantic sequence of lines 2 through 9 in file 1 matches the semantic sequence of lines 2 through 8 in file 2 because the first word in each non - blank line in file 1 is identical to the first word of the corresponding line in file 2 . there are 6 source lines in this sequence , so the algorithm yields a value of 6 . if a longer sequence of source lines is found in the file , this algorithm returns the number of source lines in the longer sequence . this algorithm yields a number q representing the number of lines in the longest matching semantic sequence in the pair of files . the entire sequence , applying all five algorithms , is shown in fig1 . in the first step 1001 , the source line , comment line , and word arrays for the two files to be created are created . in the second step 1002 , the source line arrays of the two files are compared using the source line matching algorithm . in the third step 1003 , the comment line arrays of the two files are compared using the comment line matching algorithm . in the fourth step 1004 , the word arrays of the two files are compared using the word matching algorithm . in the fifth step 1005 , the word arrays of the two files are compared using the partial word matching algorithm . in the sixth step 1006 , the source line arrays of the two files are compared using the semantic sequence matching algorithm . although all matching algorithms produce output for the user , in the seventh step 1007 , the results of all matching algorithms are combined into a single match score . the single match score t is a measure of the similarity of the file pairs . if a file pair has a higher score , it implies that these files are more similar and may be plagiarized from each other or from a common third file . this score , known as a “ total match score ,” is given by the following equation . t = k w w + k p p + k s s + k c c + k q q in this equation , each of the results of the five individual algorithms is weighted and added to give a total matching score . these weights must be adjusted to give the optimal results . there is also a sixth weight that is hidden in the above equation and must also be evaluated . that weight is f n , the fractional value given to matching numerals in a matching word or partial word . thus the weights that must be adjusted to get a useful total matching score are : these numbers are adjusted by experimentation over time to give the best results . however , unlike the other programs described in this paper , this invention is not intended to give a specific cutoff threshold for file similarity . there are many kinds of plagiarism and many ways of fooling plagiarism detection programs . for this reason , this embodiment of the present invention produces a basic html output report with a list of file pairs ordered by their total match scores as shown in fig1 . this basic report includes a header 1101 and a ranking of file pair matches for each file as shown in 1102 and 1103 . each match score shown is also a hyperlink . the user can click on a match score hyperlink to bring up a detailed html report showing exact matches between the selected file pairs . in this way , experts are directed to suspicious similarities and allowed to make their own judgments . a sample detailed report is shown in fig1 . the report includes a header 1201 that tells which files are being compared . the exact matching source lines and the corresponding line numbers are given in the next section 1202 . the exact matching comment lines and the corresponding line numbers are given in the next section 1203 . the number of lines in the longest matching semantic sequence and the beginning line numbers for the sequence in each file are given in the next section 1204 . the matching words in the files are shown in the next section 1205 . the matching partial words in the files are shown in the next section 1206 . the present invention is not a tool for precisely pinpointing plagiarized code , but rather a tool to assist an expert in finding plagiarized code . the present invention reduces the effort needed by the expert by allowing him to narrow his focus from hundreds of thousands of lines in hundreds of files to dozens of lines in dozens of files . various modifications and adaptations of the operations that are described here would be apparent to those skilled in the art based on the above disclosure . many variations and modifications within the scope of the invention are therefore possible . the present invention is set forth by the following claims .