Patent Publication Number: US-2007112821-A1

Title: Transferring electronic file constituents contained in an electronic compound file using a forensic file copy

Description:
This application claims priority to U.S. Provisional Application No. 60/737,059, filed Nov. 16, 2005, the entire content of which is herein incorporated by reference.  
     CROSS REFERENCE TO RELATED APPLICATIONS  
      Subject matter disclosed herein is disclosed and claimed in the following copending applications, all assigned to the assignee of the present invention:  
      Mapping An Electronic File To A File Class In Accordance With A Derivative Attribute Based Upon A Terminal File Extension And/Or MIME Type (CL-3103 USPRV);  
      Identifying Electronic Files In Accordance With A Derivative Attribute Based Upon A Predetermined Relevance Criterion (CL-3063 USPRV);  
      Using The Quantity Of Electronically Readable Text To Generate A Derivative Attribute For An Electronic File (CL-3105 USPRV);  
      A Data Structure Generated In Accordance With A Method For Identifying Electronic Files Using Derivative Attributes Created From Native File Attributes (CL-3107 USPRV);  
      Mapping Parent/Child Electronic Files Contained In A Compound Electronic File To A File Class (CL-3334 USPRV); and  
      Mapping Electronic Files Contained In An Electronic Mail File To A File Class (CL-3336 USPRV). 
    
    
     FIELD OF THE INVENTION  
      The present invention relates to a computer-implemented method of transferring individual electronic file constituents contained in a compound electronic file, and to a computer readable medium having instructions for controlling a computing system to perform the method.  
     DESCRIPTION OF THE PRIOR ART  
      During the discovery phase of a lawsuit it is often necessary to gather large volumes of documents regarding the litigation. The documents need to be individually reviewed and, if found to be relevant to the issues of the case, delivered to opposing counsel. Counsel for all parties must agree on sets of key words that will cause a document to be considered relevant to the proceedings and, consequently, necessary to produce during the discovery process.  
      Increasingly, the documentation presented for review is created using any of a wide variety of software application programs. The electronic documentation is stored in a wide variety of storage media [floppy discs, hard drives, compact discs (CD&#39;s), digital video discs (DVD&#39;s)] and in a wide variety of formats. The documentation may be text, audio, visual or any combination.  
      All the documents, or electronic files, gathered in response to any discovery request must be read to discover key word content. Every electronic file must be accounted for in the process. A human being can process approximately two hundred such files a day. A typical litigation can easily include 150,000 to 250,000 files. The time to review this amount of documentation is on the order of eight thousand reviewer-hours (four reviewer-years!!). A large litigation can contain millions of electronic files that require review.  
      It is therefore apparent that an electronic processing solution is necessary to handle electronic files in a reliable, consistent manner. In order to avoid the extensive human component of document identification a computer-implemented operating agent program, often called an “indexing agent”, is employed.  
      A “batch”, which is a collection or set of electronic files, is presented to the operating agent. The operating agent opens each electronic file using specific document filters that allow the information within that electronic file to be “read” by the operating agent. Every character string found by the operating agent in the electronic file is entered into an index. The electronic files thus able to be read and indexed by the operating agent define a first subset of electronic files (all “indexable” files).  
      Many electronic files cannot be opened and read by the operating agent. For example, if no document filter exists for a particular type of electronic file, the operating agent is incapable of opening that file.  
      Similarly, an electronic file may be unreadable by the operating agent if it is encrypted, password protected, a compound file (such as a zipped file or an e-mail file), corrupted, written in another language or character set, or contains other anomalies.  
      All these remaining files define a second subset of electronic files (all “non-indexable” files). Information regarding the identity of each such electronic file is entered by the operating agent in a “log file” or another suitable document tracking construct such as a database. Each log file entry (or database entry) includes a notation regarding the problem(s) found with the electronic file.  
      It is not uncommon that upwards of thirty percent (30%) of the electronic files presented are unable to be opened by the operating agent. Human intervention is required to review all electronic files in the log file to insure that all files relevant to a litigation are included in a response to a discovery request.  
      Of course, the greater the number of electronic files requiring review by human interveners, the higher is the cost.  
      Even if the operating agent is able to open an electronic file the following issues need to be considered.  
      First, merely opening an electronic file is not always trustworthy or reliable in the sense that the information within the file is not necessarily processed. The operating agent may be unable to recognize and read the text in that file. For instance, if the text is in image format (e.g., scanned image in a pdf file) it may need to have human review.  
      Second, images could contain relevant material, but since their text content cannot always be read by the operating agent the image must be reviewed by a person.  
      Third, duplicates, dictionaries, and executable files are harvested and production of these files adds to the cost. If they are not recognized by the software during processing they will often be delivered and reviewed by a human unnecessarily.  
      Fourth, the file could contain confidential information or information protected by attorney-client privilege which may require additional review/handling.  
      A significant complication is introduced when compound files need to be considered. Typical examples of compound files are electronic mail files and “zip” files. These compound files contain one or more individual electronic files and/or one or more file groups. For example, an e-mail message with a document attachment is a file group. For many reasons the electronic files in the file group must be kept together. For instance, during litigation document discovery it is often important to track who sent and who received a specific electronic file, as well as when this occurred.  
      A second significant complication of compound files comprised of file constituents is that these file constituents are stored in a non-individually manipulable manner. Because individual file constituents cannot be easily extracted or removed from the compound file without significantly modifying the file data, delivery of a subset of electronic files to a recipient is difficult.  
      In view of the foregoing it is believed advantageous to provide a computer-implemented electronic file identification method that is cheaper, easier, more trustworthy and more accurate. For instance, given that a set of electronic files to be reviewed contains a potentially large fraction of electronic files that are not readable by the indexing agent, it would be valuable if the operating agent were capable of making reliable decisions regarding these files where possible. Since all non-indexable files contain at least one or more readable native attribute(s), there exists the opportunity for the operating agent to make some determinations using those native attribute(s).  
      It is believed to be of further advantage that file groups can be tracked together. It is believed to be of yet further advantage to be able to segregate and to manipulate the file constituents from within the native compound file.  
     SUMMARY OF THE INVENTION  
      The present invention relates to a computer-implemented method, program and data structure for identifying selected electronic files contained within a set of electronic files. The set of electronic files may include at least one mail file. An electronic files is selected based upon one or more derivative attribute(s). Each derivative attribute is created from one or more identified native attribute(s) inherent in each electronic file. The derivative attributes, whether taken alone or considered combinatorily, serve as a basis for deciding various recommended actions regarding the electronic files.  
      As preliminary steps an operating agent is utilized to subdivide a collection, or set, of electronic files into a first subset and a second subset. The first subset contains each electronic file that is able to be opened by the operating agent. The second subset contains each electronic file in the remainder of the collection of electronic files that is not able to be opened by the indexing agent.  
      For each electronic file in the first subset the operating agent identifies at least one native attribute, such as the MIME type of the electronic file or the file locator of the file. The file locator may itself be considered to include one or more native attributes of the file, such as a file extension.  
      In one aspect the present invention is directed to a computer-implemented method for identifying selected electronic files from a set of electronic files that contains at least one mail file. The mail file itself includes a plurality of electronic files. Each electronic file in the mail file includes a document locator having one or more mail message markers therein.  
      The method includes the steps of: 
          (i) using an operating agent and a mail server gateway, opening the mail file;     (ii) for each of the plurality of electronic files in the opened mail file,     creating a derivative attribute having a value representative of the file class of that electronic file,     the creation of each file class derivative attribute itself comprising the steps of: 
            (a) determining the number of mail message markers in the file locator of that file; and     (b) mapping that file to a file class if the file locator includes a predetermined number of mail message markers.    
               

      For each electronic file whose file locator does not include the predetermined number of mail message markers (or if the set of electronic files does not contain a mail file), a derivative attribute having a value that is representative of the file class for the electronic file is created. The value of this file class derivative attribute indicates the software application used to create the electronic file and/or the type of software application intended to open the electronic file. If a native attribute identified by the operating agent for each electronic file in the first and second subsets is a terminal file extension for that electronic file (without MIME type) the file class derivative attribute is created by mapping that file extension to a file class. If the MIME type of a file is also one of the native attributes identified by the operating agent the file class derivative attribute is created using a combination of the identified terminal file extension and the MIME type to map the file to a file class. The mapping is determined by the MIME type so long as the MIME type falls within a predetermined set of approved MIME types; otherwise, the mapping is determined by the terminal file extension.  
      In another aspect the present invention is directed to a computer-implemented method for identifying electronic files from a set of electronic files that contains at least one compound file, the compound file itself including a plurality of electronic files,  
      the method including the steps of: 
          (i) using an operating agent and a gateway, opening the compound file; and     (ii) from the plurality of electronic files in the opened compound file, 
            identifying a subset of parent electronic files, wherein each parent electronic file includes one or more file pointer native attributes;     identifying each child file corresponding to each file pointer native attribute in each parent electronic file; and 
 
 for each file group comprising a parent file and each child file corresponding thereto, classifying the group into one of the predetermined plurality of recommended actions based upon the highest ordered recommended actions in the group. 
   
               

      In other embodiments the present invention is directed to a computer readable medium having instructions for controlling a computing system to perform any of the aspects of the method above discussed, and to a computer readable medium containing a data structure created during the implementation of the various aspects of the method of the present invention.  
      In yet another aspect the present invention relates to a computer-implemented method and program for separating one or more selected file constituents from a compound file that contains a plurality of file constituents each containing one or more native attributes. The file constituents are stored in a non-individually-manipulable manner in the compound file.  
      The method comprises the steps of: 
          creating a list identifying one or more selected file constituents;     creating a forensic copy of the compound file; and     using a functional module, segregating from the copy of the compound file the file constituents on the list, without removing them from the forensic file and without changing any native attribute of a file constituent.        

      The segregation step is performed by deleting from the forensic copy all file constituents not present on the list. If desired, the selected file constituents identified on the list may be grouped into two or more categories. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
      The present invention will be more fully understood from the following detailed description, taken in connection with the accompanying drawings, which form a part of this application and in which:  
       FIG. 1  is a stylized diagrammatic view of a computer-implemented electronic file identification method utilizing an operating agent program of the prior art interfaced with a program embodying the teachings of the present invention;  
       FIG. 2A  is a stylized illustration of a typical electronic document or non-document file, while  FIG. 2B  is a stylized illustration of a typical electronic mail file;  
       FIG. 3A  is a definitional diagram indicating the various components of a file locator for a typical electronic file, while  FIG. 3B  is a definitional diagram indicating the various components of a file locator for a typical e-mail message;  
       FIGS. 4A through 4O  are stylized illustrations of various electronic files used to explain and to exemplify the operation of the present invention;  
       FIG. 5  is an illustration of a portion of a log file produced by an operating agent of the prior art;  
       FIGS. 6A and 6B  are an overall flow diagram of the method of the present invention;  
       FIG. 7  is a flow diagram of the determination of various derivative attributes and the populating of a data structure in accordance with the method of the present invention;  
       FIG. 8  is a diagrammatic representation of a data structure created during the operation of the method of the present invention;  
       FIGS. 9A and 9B  are a flow diagram of the routing logic that utilizes derivative attributes to assign identified electronic files to various recommended actions;  
       FIG. 10  is a flow diagram of the exporting and processing for delivery of file constituents from a compound file in accordance with the present invention; and  
       FIG. 11  is a stylized representation of an exported text file with instructions as to how to manipulate the file constituents within a compound file. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
      Throughout the following detailed description similar reference numerals refer to similar elements in all figures of the drawings.  
      It should be understood that although the following description is framed in the context of the identification and selection of electronic files in connection with the discovery phase of a litigation, the various embodiments of the present invention may be applied to any of a wide range of knowledge mining operations that include document identification and selection tasks where proper handling and tracking of every document is important.  
      Investigations involving antitrust issues, government inquiries, and Sarbanes-Oxley audits serve as typical examples.  
      As used herein, the term “electronic file” or “electronic files” is construed to include any electronically stored information, including, but not limited to, electronic document file(s), electronic non-document file(s) (e.g., image, audio or other files) and electronic mail files. An electronic mail file is itself comprised of one or more electronic mail messages [herein “e-mail message(s)”]. An electronic mail file may also include electronic document file(s) and electronic non-document file(s).  
       FIG. 1  includes a stylized diagrammatic view of a computer-implemented electronic file identification method of the prior art that utilizes an operating agent program A. Those elements contained within a typical prior art implementation are indicated in the Figures by alphabetic reference characters.  
      The present invention, indicated generically by the reference character  10 , is directed in one embodiment to a method that is implemented by a computing system generally indicated by the reference character  12 . The computing system  12  includes a processing unit (“processor”)  14  and an associated data repository  16 . The data repository  16  stores a data structure  18  produced during the implementation of the method of the present invention on a suitable computer readable medium. The processing unit  14  writes to and reads from the data repository  16  over a bus  20 . A computer readable medium read by the processing unit  14  contains a program  22  of instructions for controlling the computing system  12  to perform the method in accordance with the present invention  10 . The data structure  18  and the program  22  define other embodiments of the present invention  10 .  
      The computing system  12  may be configured using any suitable computer, such as a desktop computer or an application server having a Microsoft Windows® operating system. The data repository  16  may be implemented using any data storage arrangement controlled by a suitable database management system, such as Oracle Database® database software available from Oracle® Corporation, or as MySQL® database software available from MySQL® AB.  
      In the preferred implementation of the present invention  10  certain functional modules within the operating agent A are called upon for use by the processor  14 . Accordingly the processor  14  must be able to interface and to interoperate with operating agent A. To this end a functional connection diagrammatically by reference character  24  extends between the computing system  12  implementing the method of the present invention and the operating agent A. Of course, it also lies within the contemplation of the present invention that such functions may be performed without direct reliance upon the operating agent A. An internet connection, diagrammatically indicated by reference character  28 , that facilitates web-based access and delivery of results is also desirable.  
      The present invention in its method, program and data structure embodiments is useful to identify electronic files of particular interest from a collection of native format electronic files. The electronic files so identified using the present invention are selected for suitable handling and disposition.  
      The overall collection of native format electronic files is generally indicated by reference character E. For purposes of the discussion herein the collection E contains a set of electronic files indicated diagrammatically by the reference characters F 1  through F 15 .  
      In a typical instance the electronic files F 1  through F 15  are gathered from a variety of custodians and locations and are presented in a variety of storage media. For convenience of accessibility the electronic document and non-document files F 1  through F 11  and F 15  in the collection E are stored in a suitable document repository, such as a document server G. The collection E includes a mail file stored in a suitable message repository, such as an e-mail server H. In  FIG. 1  the mail file is shown to contain e-mail messages F 12  through F 14 . The e-mail messages F 13  and F 14  have respective electronic document files F′ 5  and F′ 1  as attachments. The treatment of such e-mail messages is discussed in full detail herein.  
      The e-mail messages F 13  and F 14  and the electronic non-document file F 15  are also compound file groups, in that each comprises a parent file having one or more child files attached thereto. The treatment of such compound file groups is also discussed in full detail herein.  
      A stylized illustration of a typical electronic document file or electronic non-document file F is illustrated in  FIG. 2A . A stylized illustration of a typical electronic mail file is shown in  FIG. 2B .  
      As seen from  FIG. 2A , in general, each electronic document file or electronic non-document file in the collection includes a file locator R, a header H, a body B, and a termination N. All of these file aspects are generated by the application software used to create the file.  
      A typical electronic mail file, shown in  FIG. 2B , can be comprised of a number “n” of e-mail message(s), identified in  FIG. 2B  as File Constituents 1, 2, . . . n . Each of these e-mail messages could contain electronic document file(s) and/or electronic non-document file(s) as attachments. It should be noted that these file constituents, while individual electronic files or messages in and of themselves, are stored in a non-individually-manipulable manner in the compound electronic file in which they reside. Thus, an individual electronic file or e-mail message cannot be easily extracted or removed from the overall compound file without significantly modifying the file data. For instance, extracting an e-mail message from a mail file can be accomplished by printing it, forwarding it, or saving it in a text format or in a portable document format such as that used by Adobe Acrobat® electronic document distribution and exchange creation program available from Adobe Systems Incorporated. The use of any of these alternatives will modify the original electronic format of the electronic file and will modify the data attached to the file, e.g., date, file name, format, MIME type. Accordingly, a file constituent in a compound file is not individually manipulable without significant modification.  
      Each of these File Constituents includes similar file aspects as an electronic document file and an electronic non-document file ( FIG. 2A ). The file locator R specifies the file path within the repository G or H by which each electronic file in the collection E may be accessed. The syntax of a file locator R for a typical electronic document file or an electronic non-document file F is indicated in  FIG. 3A , while the syntax of a typical file locator R for a typical e-mail message (or attachment) is shown in  FIG. 3B . The full extent of the file locator R is contained within the braces “{ }”.  
      Other forms of compound files, such as a “.zip” file exhibit the same file aspects as the mail file represented in  FIG. 2B . In such a case the File Constituents are comprised of electronic document file(s) and/or electronic non-document file(s).  
      As shown in  FIG. 3A , in the case of an electronic document file or electronic non-document file, the file locator R comprises a full file path and one or more file extension(s). The full file path includes both a storage file path and a relative file path. The storage file path specifies the identity of the system and location hierarchy where the electronic document file or electronic non-document file currently resides. In the context of the specific example shown in  FIG. 3A  the storage file path is “G:\Documents and Settings”. This indicates that the electronic document file or electronic non-document file is stored on the “G” server, in the folder “Documents and Settings”. Additional folders in the folder hierarchy (if present) would also be specified.  
      The relative file path sets forth the custodian of the file, the hierarchy of folder(s) containing the electronic document file or electronic non-document file, and the file name. In the context of the example shown in  FIG. 3A  the relative file path is “John Doe\My Docs\Projects”. The custodian of the electronic document file or electronic non-document file is “John Doe”. The file named “Projects” is stored in the folder “My Docs”.  
      Generally speaking, one or more file extensions of any arbitrary length, as created by the author or as applied by the software application used to create the electronic document file or electronic non-document file, may be included in the file locator R. As a typical example (not shown) the well-known file extension “.doc” appended to the end of a document indicates that the electronic document file is created using the Microsoft Word® word processor program available from Microsoft Corporation.  
      An electronic document file or electronic non-document file may contain more than one file extension. In the example in  FIG. 3A  a cascade of hypothetical file extensions “.xxx.yyy” follows the file name. The file extension following the last-appearing period in the file locator (in the example of  FIG. 3A , “yyy”) is herein termed the “terminal” file extension.  
      It should be noted that some creating application programs do not insert a default file extension or require an author to insert a file extension. Moreover, an extension that is appended to a file name or required by the creating application may nevertheless be deleted or altered by the author. In these situations where the extension is omitted or deleted it is considered to be a “null” extension (herein indicted as “[NULL]”). Because of the possibility of omission, deletion or alteration, basing a decision as to file identification upon a file&#39;s extension is believed not a totally reliable practice.  
      As shown in  FIG. 3B , in the case of an e-mail message, the file locator R comprises a full file path and message and attachment information.  
      The full file path again includes both a storage file path and a relative file path. The storage file path specifies the identity of the system and location hierarchy where the e-mail message currently resides. In the context of the specific example shown in  FIG. 3B  the storage file path is “H:\Litigation E-Mail”. This indicates that the e-mail message is stored on the “H” server, in the folder “Litigation E-Mail”. Additional folders in the folder hierarchy (if present) would also be specified.  
      The relative file path sets forth the custodian of the file, the hierarchy of folder(s) (if any) containing the e-mail message, and the mail file name. In the context of the example shown in  FIG. 3B  the relative file path is “John Doe\doej2”. The custodian of the e-mail message is “John Doe”. The name of the mail file in which this particular message is “doej2“. As is typical for an e-mail message, there is no further hierarchy in the relative file path. It should be noted that other messages sent by or received by this custodian could potentially also be stored in this mail file.  
      The mail file extension typically identifies the program used to generate the mail file. For instance, the Lotus® Notes® mail program available from IBM Corporation uses the standard mail file extension “.nsf”. Mail files created using the Microsoft Outlook® mail program available from Microsoft Corporation use the standard mail file extension “.pst”.  
      A mail message marker is typically used in mail message identification in a fashion similar to the use of the “\” used to distinguished folders on servers. In  FIG. 3B  the mail message marker takes the form of one or more characters “!!”.  
      The message and attachment information portion of the file locator R includes detailed identification information on both the e-mail message and any possible attachment(s).  
      The mail message identifier is often constructed of a unique string of numbers and letters (in the instance illustrated, a sequence of hexadecimal characters) used to identify uniquely a mail message in the mail file.  
      In the instance where an e-mail message contains an attachment, attachment information is also available in the file locator R to identify uniquely the attachment in the mail file. In  FIG. 3B  the attachment information includes the Attachment Identifier which gives the Attachment File Name and the Attachment File Extension(s). The same considerations for file extensions as discussed in connection with  FIG. 3A  are applicable in the case of the file locator R shown in  FIG. 3B .  
      With reference again to  FIGS. 2A  or  2 B the header H of an electronic file is a character string containing information about the file, such as the file title, the file size, the identity of the author, the date and time that the file was created or last modified, file pointers and privacy flags.  
      The header H may also have embedded therein information regarding the identity of the software used to create the file. This information string is also sometimes referred to as the MIME-content type (“MIME type”) of the file.  
      “MIME” is an acronym for Multipart Internet Mail Extension. The general categories of MIME types assigned and listed by the Internet Assigned Numbers Authority (“IANA”) include: application, audio, image, message, model, multipart, text, video. Each general category contains numerous subcategories.  
      Although it is believed to be a better practice, not all files include a MIME type in the header. Under some operating systems the MIME type, if inserted by the creating application, can be changed by the author. Moreover, even if present and not altered, the MIME type can be misread. Accordingly, since the MIME type may be omitted, altered, or misread, it is also believed not a totally trustworthy indicator upon which to base file identification.  
      The communicative content contained within the electronic file (as opposed to information about the electronic file contained in the file locator and header) is carried in the file body. As will be developed in connection with the various sample electronic files illustrated among  FIGS. 4A through 4O , the file body B may include one or more computer-readable character strings, non-readable locked or encrypted text, or non-readable image or audio/visual data.  
      The file termination N contains at least an end-of-file marker. This marker is typically denoted by the symbol “&lt;eof&gt;”. In the case of a compound file the internal separation between messages (e.g., e-mail messages) is a message terminator denoted by the symbol “&lt;eom&gt;”.  
      Native Attributes For the purposes of the present invention all of the parameters intrinsically found within an electronic file are collectively termed the “native attributes” of the electronic file.  
      For the purposes of this discussion of the present invention, the file locator R itself, as well as the various elements contained therein [such as the file name, the file paths, and the file extension(s)], the various pieces of information listed earlier about the file contained within the header H [e.g., the MIME type, privacy flag, pointer(s)], and the character strings that comprise the communicative content carried in the body, are each to be considered among the native attributes of an electronic file. Native attributes further include the date of the electronic file, the title and the author. For purposes of the present invention the gateway type used to open the file and the subset S 1  or subset S 2  in which the electronic file resides may also be considered as native attributes even though they are generated by the operating agent A.  
      For purposes of an example of the function and operation of the various aspects of the present invention that is to be developed throughout the discussion in this specification, the collection E is assumed to include the following electronic files F 1  through F 15  (each of which is illustrated in the respective stylized representations shown in  FIGS. 4A through 4O ).  
      A stylized depiction of the electronic file F 1  is shown in  FIG. 4A . This electronic file is a memorandum created using Microsoft Word® word processor program. The header H of this file indicates the MIME type as “application/msword”. The file is password locked, as represented by the padlock symbol, rendering it immune from being opened by the operating agent A.  
       FIG. 4B  is a stylized depiction of the electronic file F 2 . The body of this electronic file contains a scanned document created using the Adobe Acrobat® electronic document distribution and exchange creation program available from Adobe Systems Incorporated. The MIME type contained in the header H of this file indicates the MIME type as “application/x-pdf”.  
       FIG. 4C  depicts an audio/visual file F 3 . No MIME type is available in the header H.  
      Electronic file F 4 , depicted in  FIG. 4D , is an example of an image file. The MIME type available from the header H of this document is “image/jpeg”.  
       FIG. 4E  illustrates electronic file F 5 . This electronic file F 5  is a hypothetical, fanciful memorandum created using Microsoft Word® word processor program. The header H of this file includes the MIME type “application/msword”. The body of this file includes computer-readable text.  
       FIG. 4F  is a representation of an executable program file F 6 . The MIME type indicated in the header is “application/octet-stream”.  
      Electronic file F 7 , illustrated in  FIG. 4G , contains readable text in spreadsheet form. The file is created using Microsoft Excel® spreadsheet program available from Microsoft Corporation. The typical file extension (”.xls”) for such a file has been deleted by the author. Thus, the file is considered to have a [NULL] extension. The header H of this file includes the MIME type “application/ms-excel”.  
       FIG. 4H  is a compound file in the form of a mail file F 8 . A compound file is itself an amalgamation of a plurality of individual records or messages. No MIME type is available for this compound file. This mail file is treated as a single undecipherable file. In this instance the individual messages contained in the mail file are not distinguishable as separate e-mail messages.  
       FIG. 4I  is a rendering of an electronic dictionary file F 9 . Such a file is usually lengthy and almost invariably contains one or more key words of interest. No MIME type is usually available in the header H for such a file. However, as will be discussed, it is possible that the operating agent A could assign a “text”-class MIME type to the file. Accordingly, in  FIG. 4I  the MIME type “text/plain” is indicated in italics in the header H.  
       FIG. 4J  is a stylized depiction of an electronic drawing file F 10  created using a computer-aided drafting program. The MIME type available in the header H is “image/vnd.dwg”.  
      Electronic file F 11  shown in  FIG. 4K  is meant to represent a file of an unknown type that is not previously encountered and is, therefore, unable to be handled.  
       FIGS. 4L through 4N  depict individual e-mail messages F 12  through F 14 . As indicated in the file locator section R, each of these individual e-mail messages is contained in the same mail file (“doej2.nsf”) stored on the mail server H. For a reason similar to that discussed in connection with  FIG. 4I  the MIME type for each of these e-mail messages is “text/plain” and is indicated in italics in each header H.  
      The individual e-mail message F 12  (shown in  FIG. 4L ) has an asserted (“ON”) privacy flag native attribute in its header H. The presence of an asserted privacy flag renders the text in body B of this individual e-mail messages unreadable by the operating agent A. This is represented by the padlock symbol.  
       FIGS. 4M and 4N  show respective individual e-mail messages F 13  and F 14  that have an unasserted (“OFF”) privacy flag native attribute in their header H, rendering the text in their body B readable by the operating agent A. Each of these individual e-mail messages has an attachment, thus requiring the presence of a file pointer native attribute in the header H. The file pointer native attribute indicates the storage location of the attachment. The attachment is also indicated graphically by the icon in the body B.  
      In the case of individual e-mail message F 13  the attachment is an exact copy of all of the native attributes and full text of the original electronic file F 5 . However, since this attachment is a copy that is stored in a different location than the original electronic file F 5  (mail server H as part of the “doej2.nsf” mail file), it has a different file locator and is represented by the different reference character F′ 5 . The file pointer for the attachment F′ 5  includes the full file path, the mail file extension and the message identifier of its parent (i.e., the individual e-mail message F 13 ). It also includes as the attachment identifier the file name and file extensions of the original electronic file F 5 .  
      The attachment to individual e-mail message F 14  is an exact copy of all of the native attributes and full text of the original electronic file F 1 . Similarly, since this attachment is a copy is also stored in a different location than the original electronic file F 1 , it also has a different file locator and is represented by the different reference character F′ 1 . The file pointer for the attachment F′ 1  includes the full file path, the mail file extension and the message identifier of its parent (i.e., the individual e-mail message F 14 ) and also includes as its attachment identifier the file name and file extensions of the original electronic file F 1 .  
       FIG. 4O  is a stylized depiction of compressed compound electronic file F 15 . The header H of this file indicates its MIME type as “application/zip”.  
      The body of this file electronic file F 15 contains an exact copy of all of the native attributes and full text of three original electronic files F 2 , F 5  and F 7 . These copies are represented in  FIG. 4O  by the respective reference characters F′ 2 , F″ 5 , and F′ 7 . The copy of original electronic file F 5  in this file is denoted by the reference character F″ 5  because it is different both the original electronic file F 5  and the copy F′ 5  attached to the e-mail message F 13 . The file pointer native attribute indicating the storage location of these copies are found in the header H of the electronic file F 15 .  
      It should be noted that, as shown in  FIG. 1 , the attachments and/or copies F′ 1 , F′ 2 , F′ 5 , F″ 5 , and F′ 7  are included as individual electronic files in the overall collection of native format electronic files E.  
      Prior art computer-implemented electronic file identification methods for identifying and selecting electronic files from the collection E of electronic files utilize the operating agent program A. The operating agent program A resides on a suitable host computer C and communicates over a bus D with the servers G and H in which the collection E is stored. An operating agent program preferably utilized with the present invention is the program Verity K2 Enterprise available from Verity Incorporated, Sunnyvale, Calif.  
      In accordance with one aspect of the invention the operating agent A serves to subdivide the collection E of electronic files into two subsets. The first subset S 1  of electronic files includes those files able to be opened by (i.e., accessible to) and indexable by the operating agent A. The second subset S 2  contains all other electronic files in the remainder of the set of electronic files.  
      Using one or more internal gateways and a library of available document filters the operating agent program A attempts to open each of the electronic files F 1  through F 15  (including the attachments and/or copies F′ 1 , F′ 2 , F′ 5 , F″ 5 , and F′ 7 ) in the collection E presented to it. For each electronic file that it is successfully able to open the operating agent includes a functionality able to create an index I, or organized list, containing every accessible character string used in the electronic file. The index I is stored in a memory M I . The index I is organized in a predetermined manner, typically in alphabetic order. Since the files physically remain in the servers G and H,  FIG. 1  depicts the files grouped into the first subset S 1  in outline form, indicating that only information about and information from the files is stored in memory M I .  
      The gateway is the module of the operating agent A that enables the agent A to open the document repository (server G or H, as the case may be) to access the individual electronic files. For instance, a suitable gateway enabling the operating agent A to open the document server G is a Windows® Document gateway. This gateway is indicated by the reference character W 1 . Other suitable document server gateways include a Unix document gateway or an HTTP document gateway. A suitable gateway enabling the operating agent A to open the mail server H is a Lotus® Notes® gateway. Other suitable mail server gateways include Microsoft Exchange gateway and ODBC gateway. This gateway is indicated by the reference character W 2 .  
      The result of the use of an inappropriate gateway is able to be understood by a comparison of the mail file F 8  “John Mail.nsf” stored on server G ( FIG. 4H ) with the individual e-mail messages F 12  through F 14  ( FIGS. 4L  through  4 N) contained in the electronic mail file “doej2.nsf” stored on server H. Since the file F 8  is read by the Windows® Document gateway it is treated as a single indivisible compound file in which individual e-mail messages are not distinguishable. Conversely, the use of a Lotus® Notes® gateway on the mail file “doej2.nsf” results in the three separate e-mail messages shown in  FIGS. 4L through 4N .  
      The operating agent A also identifies one or more of the various native attributes contained in the electronic files it is able to open, such as the file locator R and the MIME type. For purposes of the example being developed, it is assumed that the operating agent A contains a set of filters for documents created by (1) Adobe Acrobat® electronic document distribution and exchange creation program [F 2 ,  FIG. 4B ]; (2) Microsoft Word® word processor program [F 5 ,  FIG. 4E ]; (3) Microsoft Excel® spreadsheet [F 7 ,  FIG. 4G ]; as well as a generic filter [F 9 ,  FIG. 4I ]. Thus, electronic files F 2 , F 5 , F 7 , F 9 , F 12 , F 13 , F 14 , and F 15  would be opened using the operating agent A. Note that, in all cases to be discussed, a copy of any electronic file (such as the electronic files F′ 2 , F′ 5 , F″ 5  and F′ 7 ) would be receive the same treatment as its counterpart original. That is, these copies would be able to be opened by the operating and would be included in the subset S 1 .  
      The operating agent A identifies and stores the electronic files it is able to open (i.e., for the files in the first subset S 1 ) the file locator native attribute R in toto, as well as the individual native attributes included therewithin: file name; full file path; relative file path;; custodian; mail file name, and attachment identifier. The operating agent A also attempts to identify and store various pieces of header information, including the native attribute MIME type.  
      The operating agent also may identify additional native attributes present in the electronic file, such as file date (i.e., date the file is last modified), file title, author, file pointer(s), privacy flag and file size.  
      Since the files F 5 , F 7 , F 9 , F 13  and F 14  contain computer-readable text the operating agent A is able to create an index entry for each character string (each string of alpha-numeric characters separated by a space or a punctuation mark) in the body B of these files. For purposes of the discussion of this invention these character strings are considered native attributes of the particular file.  
      The treatment accorded to the file F 2  ( FIG. 4B ) by the operating agent A merits attention. Even though, as seen from the representation shown in  FIG. 4B , the body of this file is intelligible to humans, the content of this file is a scanned image, not computer-readable text. So although the operating agent A is able to open this file, to the operating agent A this file does not contain any readable character strings.  
      The electronic file F 12  has its privacy flag asserted. The operating agent A is not allowed access to the full text body B of that electronic file. Therefore the only readable character strings are derived from the header H. The electronic file F 15  itself does not contain any readable character strings in its body. Instead, the body B contains exact copies of three original electronic files. The readable character strings for each of these three copies are indexed in the same manner as the corresponding originals.  
      The assignment of MIME type by the operating agent also merits some discussion. In general, the operating agent relies upon the file header H to identify the MIME type of the file. For the files F 2 , F 5  and F 7 , which are opened using the respective filters for Adobe Acrobat® electronic document distribution and exchange creation program [F 2 ], Microsoft Word® word processor program [F 5 ] and Microsoft Excel® spreadsheet program, these files are assigned MIME types corresponding to these applications, viz., “application/x-pdf” [F 2 ], “application/msword” [F 5 ], and “application/ms-excel” [F 7 ], respectively.  
      The files F 9 , F 12 , F 13  and F 14  are opened using the generic filter. Although these files do not contain a MIME type embedded within their header, since the files does contain readable text in some portion of the file, it is likely that the operating agent A would assign its default MIME type, e.g., “text/plain”, to these files. The default MIME type is indicated in italic text in  FIGS. 4I, 4L ,  4 M and  4 N. The assignment of such a default MIME type to a file would not provide a clear indication as to the application program used to create this file. As such the use of the default MIME type is misleading.  
      The prior art operating agent A also typically includes a search function operator Q that imparts the capability to the operating agent A to make a determination of the relevance of each file that it is able to open to particular issues. The determination is based upon a comparison of the character strings in each native attribute of each file against a set of target character strings (key words) contained in one or more target character lists.  
      In the context of file identification for purposes of a litigation a relevance target character list T, a privilege target character list P and a confidentiality target character list V are usually defined. The relevance target character list T contains a set of target character strings that, if found in a given file, would indicate that the file is relevant to issue(s) in the litigation. Similarly, the privilege target character list P contains a set of target character strings that, if found in a given file, would indicate that the file contains information to which a privilege is attached. The confidential target character list V contains a set of target character strings that, if found in a given file, would indicate that the file contains information contains personal or confidential material.  
      The various target characters strings for the different topics may be applied hierarchically (in which a determination of privilege or confidentiality would occur only if relevance is satisfied) or as independent inquiries.  
      By way of example, if it is assumed that the subject matter of a litigation involves an issue around the a bio-scientific development project for a blue-green mold referred to by the codename “Project Blue”, the relevance target character list T would likely include the key words “blue”, “green”, “turquoise”, and some number of additional synonymous words.  
      A well-devised relevance target character list would also include a context filter X. This is a logical device whereby the operating agent is able to distinguish the relevance of a document containing a key word term by the context in which the key word appears. For example, in connection with a litigation involving “Project Blue” a file that contains only a message to the effect that the author feels “blue” on a particular day is unlikely to be identified as relevant. Thus, the context filter might be configured to exclude and ignore cases in which the operating agent finds terms like “feeling” and “mood” near the term “blue” where it has a different kind of meaning within the context of that document.  
      The privilege target character list P would likely include as key words the names of counsel, and the terms “Legal” and “opinion”, for example. Key words for a confidential target character list V would likely include the term “confidential”, “secret”, “special control”, and terms relating to health or financial condition (e.g., social security and/or credit card numbers).  
      Applying the various target character lists to the electronic files F 2 , F 5 , F 7 , F 9 , F 12 , F 13 , F 14 , and F 15  the operating agent A would likely identify the document F 9  as relevant and identified for production to opposing counsel. The document F 5  would be identified as relevant but privileged. The documents F 2 , F 7 , F 12 , F 13 , F 14 , and F 15  would be identified as not relevant because, to the operating agent, these files do not contain any character string matching a key word in the relevance target character list.  
      For convenience, some of the native attributes for the electronic files in the first subset S 1  as identified by the operating agent A during the creation of the index I, together with the results of the comparison against the target characters set T, P and V are summarized in the following Table 1.  
               TABLE 1                          Native Attributes (Subset S 1 )                                                                 Relevant/                       Privacy   File   Privileged/       File   Full File Path   Extension(s)   MIME Type   Flag   Pointer   Confidential               F 2     G:\Documents and Settings\   .123   Application/   N/A   N/A   Not           John Doe\MyDocuments\Projects\       x-pdf           Relevant           Red Projects\Memo.123       F′ 2     G:\Documents and Settings\John   .123   Application/   N/A   N/A   Not           Doe\MyDocuments\Projects\Red       x-pdf           Relevant           Projects\Memos.zip!!Memo.123       F 5     G:\Documents and Settings\John   .12 2003.   Application/   N/A   N/A   Relevant &amp;           Doe\MyDocuments\Projects\   rev.1   msword           Privileged           Blue Projects\Memo Sept.12           2003.rev.1       F′ 5     H:\Litigation E-mail\John Doe\   .12 2003.   Application/   N/A   N/A   Relevant &amp;           doej2.nsf!!2F07DF673EC9!!Memo   rev.1   msword           Privileged           Sept.12 2003.rev.1       F″ 5     G:\Documents and Settings\John   .12 2003.   Application/   N/A   N/A   Relevant &amp;           Doe\MyDocuments\Projects\Red   rev.1   msword           Privileged           Projects\Memos.zip!!Memo           Sept.12 2003.rev.1       F 7     G:\Documents and Settings\   [NULL]   Application/   N/A   N/A   Not           John Doe\My Documents\Projects\       ms-excel           Relevant           Red Projects\John       F′ 7     G:\Documents and Settings\   [NULL]   Application/   N/A   N/A   Not           John Doe\MyDocuments\Projects\       ms-excel           Relevant           Red Projects\Memos.zip!!John       F 9     G:\Documents and Settings\   .ctl   Text/plain   N/A   N/A   Relevant           John Doe\MyDocuments\Programs\           program.ctl       F 12     H:\Litigation E-mail\John   [NULL]   Text/plain   “On”   N/A   Not           Doe\doej2\nsf!!244BFE5B9C92                   Relevant       F 13     H:\Litigation E-mail\John   [NULL]   Text/plain   “Off”   See  FIG. 4M ,   Not           Doe\doej2\nsf!!2F07DF673EC9               “File Pointer 1”   Relevant       F 14     H:\Litigation E-mail\John   [NULL]   Text/plain   “Off”   See  FIG. 4N ,   Not           Doe\doej2\nsf!!401F645E221A               “File Pointer 1”   Relevant       F 15     G:\Documents and Settings\John   .zip   application/   N/A   See  FIG. 4O ,   Not           Doe\MyDocuments\Projects\Red       zip       “File Pointer 1”,   Relevant           Projects\Memos.zip               “File Pointer 2”,                           “File Pointer 3”                  
 
      The electronic files in the that are unable to be opened by the operating agent A are relegated to the second subset S 2 . Thus, in the context of the example being developed, the electronic files F 1  (and its copy F′ 1  in  FIG. 4A ), F 3  ( FIG. 4C ), F 4  ( FIG. 4D ), F 6  ( FIG. 4F ), F 8  ( FIG. 4H ), F 10  ( FIG. 4J ) and F 11  ( FIG. 4K ) are contained within the second subset S 2 . Information regarding each electronic file in the second subset S 2  is entered into a “log file” L (or another suitable document tracking database) created by the operating agent A and stored in the memory M L . Again, since the files grouped into the second subset S 2  physically remain in the servers G and H, they are depicted in  FIG. 1  in dashed-line outline form, indicating that only information about these files is stored in memory M L .  
       FIG. 5  illustrates an excerpt of the log file L. The log file L is a single file that includes an entry for each file in the second subset S 2 . The entries for each file are separated from each other by a carriage return “&lt;cr&gt;&lt;lf&gt;”.  
      As seen from  FIG. 5 a  typical entry in the log file L for a given electronic file includes the file locator R native attribute of that file, in toto. The file locator R itself includes native attributes such as file name and one (or more) file extension(s). Thus, at least one native attribute for each electronic file in the second subset S 2  is contained within an entry in the log file L for an electronic file. An entry may also include an error notation indicating the problem(s) encountered by the operating agent with the electronic file.  
      The operating agent A also determines whether any file is a duplicate of a file already indexed. The operating agent A generates a hash code for each electronic file that is able to be opened thereby. The hash code of a given electronic file is compared with the hash code of each of the other electronic files opened by the operating agent. If the given file is determined to be a duplicate it is assigned to the second subset S 2  and an appropriate entry included within the log file L. An example of an entry denoting a duplicate file F D  in is indicated in  FIG. 5 . This entry indicates that the file F D  in the custody of “Earl Warren” is a duplicate of a file named “110603” in the custody of “Hugo Black”.  
      Note that that copies of electronic files that are designated by a file pointer (F′ 1 , F′ 2 , F′ 5 , F″ 5 , and F′ 7 ) are not considered duplicates by the operating agent A.  
      In one aspect the present invention is directed to a computer-implemented method for identifying selected electronic files from a set of electronic files that contains at least one mail file, to a computer-readable medium containing instructions for controlling a computing system implement the method, and to a computer-readable medium containing a data structure produced by the implementation of the method.  
      In another aspect the present invention is directed to a computer-implemented method for identifying and mapping compound electronic files to a file class, to a computer-readable medium containing instructions for controlling a computing system implement the method, and to a computer-readable medium containing a data structure produced by the implementation of the method.  
       FIGS. 6A and 6B  show an overall block diagram of the program of the present invention  10  as implemented by the processor  14  ( FIG. 1 ). See also, “Code Listing 6” in the Appendix. In general,  FIG. 6A  shows the treatment of individual electronic files and  FIG. 6B  shows the aggregation of individual electronic files into file groups and the treatment of such groups. With reference to  FIG. 6A , summarizing the operation of the operating agent explained above, the operating agent A performs various preliminary steps, as generally by the block  100 . These preliminary activities include subdividing the set of electronic files into the first and second subsets S 1  and S 2 . For the files it is able to open using one of the available gateways and document filter (i.e., the files in the first subset S 1 ) the operating agent A creates an index I that includes the various native attributes present in the file. Two of the more pertinent native attributes for the present discussion, viz., file extension and MIME type, are summarized in Table 1.  
      The preliminary activities also include use of the operating agent A to extract all available native attributes for each electronic file. These native attributes may include the file locator R itself, as well as the various elements contained therein [such as the file name, the file paths, and the file extension(s)], the various pieces of information listed earlier about the file contained within the header H [e.g., the MIME type, privacy flag, pointer(s)]. Native attributes may further include the date of the electronic file, the title, the author, the gateway type used to open the file, and the subset S 1  or subset S 2  in which the electronic file resides.  
      For the files that are not able to be opened and indexed (i.e., the files in the second subset S 2 ) the operating agent A creates a log file L having an entry for each file ( FIG. 5 ). Each log file entry includes the file locator native attribute, which is itself comprised of various native attributes, such as the full file path and the file extension(s) for the file.  
      As indicated in the block  102  the first major action of the method of the present invention is to utilize the identified native attributes of the electronic files in both the first and second subsets S 1  and S 2  to generate one or more derivative attributes. These include a derivative attribute representative of the file class of the electronic file and a derivative attribute representative of the file&#39;s readability (that is, the presence of at least some predetermined number of readable characters in the accessible character strings in the file). In addition, a derivative attribute representative of the relevance of each file in the second subset S 2  is also created. As the derivative attributes for each electronic file in the first subset and second subset are created a data structure  18  ( FIGS. 1 and 8 ) grouping the numerical value indicators for these attributes is also generated.  
      The state of a particular derivative attribute is indicated by a value indicator. In general, a value indicator representative of a derivative attribute may take any designed numerical, alphabetical, textual or symbolic form. In the present invention numerical value indicators are preferred because they require less memory when stored in the data structure and are amenable to easier and faster comparisons than textual string comparisons.  
      As indicated in the block  104  the method of the present invention includes routing logic ( FIGS. 9A and 9B ) that uses the derivative attributes contained in the data structure as the basis for identifying each electronic file in each subset for one of at least three predetermined specific recommended actions (or “destination states”). The set of recommended actions is indicated collectively by the reference character  112 . The recommended actions include segregation into an archive listing as indicated at block  106 , review by a human reviewer as generally indicated at block  108 , or identification as fully responsive as indicated at block  110 . The human review can take the form of review by an information technology expert as indicated by the block  108 A, or review by a subject matter expert as indicated at the block  108 B. The value representative of the recommended action is indicated in the corresponding block in  FIG. 6A .  
      The function of the information technology expert is to open each assigned file. The file, once opened can be returned by the information technology expert to the operating agent A for the processing in accordance with blocks  100 - 104 . The file can be referred to the subject matter expert for a subject matter determination. The file may also be sent to the archive. The subject matter expert may identify the file as responsive or marked for the archive. It should be noted that the electronic files remain physically resident in the repositories G and H, each flagged with an appropriate marker indicating the action recommended by the method of the present invention. It lies within the contemplation of the present invention that additional recommended actions could be defined.  
      Each recommended action is assigned a predetermined value in a hierarchical order. The value for each recommended action is indicated in the respective blocks  106 ,  108 A,  108 B and  110  in  FIG. 6A  by alphabetic characters. The values are in alphabetical order with the value “A” assigned to the recommended action  108 A being the highest value in the hierarchy. The value “D” assigned to the recommended action  106  is the lowest value in the hierarchy. The values “B” and “C” are assigned to the recommended actions  110  and  108 B, respectively.  
      Once each electronic file has been individually treated and classified into one of a predetermined plurality of recommended actions ( FIG. 6A ) the pointer native attribute is used to identify file groups and treat the identified groups.  
      In accordance with another aspect of the invention, as indicated in the block  115 , the overall collection E of electronic files is subdivided into two different subsets S 3  and S 4 . The subset S 3  identifies each electronic file that includes one or more file pointer native attributes. Such an electronic file is termed a “parent” or “parent file”. Each electronic file corresponding to each file pointer native attribute in each parent electronic file is termed a “child” or “child file” (collectively, “children”).  
      Once the subset of parent files is identified all remaining electronic files are relegated to the subset S 4 . Thus, the subset S 4  identifies all non-parent files. Note that not every file in the subset S 4  is a child file. Many files are individually independent, with no parent-child relationship.  
      Each parent file and its child(ren) define a file group. Three such file groups, FG 1 , FG 2 , and FG 3  are illustrated in  FIG. 6B . Each file group comprises one parent file and each child file corresponding thereto. Each file group is itself classified into one of the predetermined plurality of recommended actions  106 ,  108 A,  108 B and  110 . This action is indicated by the block  117 . As will be explained herein a file group is classified into one of the recommended actions based upon the highest hierarchical value of the recommended actions of each of the electronic files in the group. An Appendix containing a listing of program code implementing the steps in accordance with the method of the present invention is included in this description immediately preceding the claims. The code is written in SQL, HTML, Java, Verity&#39;s Java APIs and ColdFusion.  
       FIG. 7  is a more detailed flow diagram of the steps undertaken in the block  102  ( FIG. 6A ) involved in the creation of derivative attributes and the generation of the data structure  18 . It should be understood that the various steps may be performed in any convenient order. See also “Code Listing 7-S1” and “Code Listing 7-S2” in the Appendix.  
      Each electronic file in each subset S 1  and S 2  is analyzed in turn, as generally indicated in the block  116 . In the preferred implementation of the method of the present invention the operating agent A is called upon to perform various functions and derive certain conclusions, with the results being returned to the processor  14  implementing the method of the invention. However, as noted earlier, it also lies within the contemplation of the present invention that such functions may be performed by the processor  14  without direct reliance upon the operating agent A.  
      In the case of electronic files in the subset S 1  search instructions for locating the desired native attributes are sent in appropriate search language to the operating agent A which performs the desired comparisons and returns resulting information.  
      Native attributes for the electronic files in the second subset S 2  are identified by importing the entry in the log file L ( FIG. 5 ) for each electronic file into the processor  14  implementing the program of the present invention. The log file entry is parsed to identify the file locator R native attribute of that file. Contained within the file locator native attribute R are the full file path and file extension native attributes (for files having a file locator as shown in  FIG. 3A ) and the full file path, the attachment file identifier and attachment file extension native attributes (for files having a file locator as shown in  FIG. 3B ). These attributes are used by the processor  14  to create certain derivative attributes. For other derivative attributes information with appropriate search instructions is passed to the operating agent A and the results returned.  
      Table 2 is a summary table listing some of the native attributes able to be isolated by parsing the log file entry for a file in the second subset. It is noted that since the MIME type is usually present in the file header of a file and since a file is relegated to the subset S 2  because it cannot be opened by the operating agent A, it follows that the log file entry for an electronic file would likely not contain the MIME type. However, it is possible that an operating agent may itself be able to extract the MIME type from the file header of a file relegated to the second subset S 2  or may include an auxiliary operating agent (not shown) to perform this function. This possibility is addressed by the inclusion in Table 2 of a column containing the MIME type.  
               TABLE 2                          Native Attributes (Subset S 2 )                                     Exten-           File   Full File Path   sion(s)   MIME type               F 1     G:\Documents and Settings\   .doc   application/           John Doe\MyDocuments\       msword           Projects\Blue Projects\           memo.doc       F′ 1     H:\Litigation E-mail\   .doc   application/           John Doe\doej2.nsf!!       msword           401F645E221A!!memo.doc       F 3     G:\Documents and Settings\   .mp3   NOT           John Doe\MyDocuments\       AVAILABLE           Projects\Red Projects\           music.mp3       F 4     G:\Documents and Settings\   .jpg   image/jpeg           John Doe\MyDocuments\           Projects\Red Projects\           picture.jpg       F 6     G:\Documents and Settings\   .exe   application/           John Doe\MyDocuments \       octet-stream           Programs \program. exe       F 8     G:\Documents and Settings\   .nsf   NOT           John Doe\MyDocuments\       AVAILABLE           Projects\Red Projects\           John Mail.nsf       F 10     G:\Documents and Settings\   .dwg   image/           John Doe\MyDocuments\       ind.dwg           Projects\Blue Projects\           Plant Electrical System.dwg       F 11     G:\Documents and Settings\   .flpr.239   NOT           John Doe\MyDocuments\       AVAILABLE           Programs\file.flpr.239                  
 
      The manner in which the various derivative attributes for an electronic file in each subset S 1  and S 2  are created is next discussed.  
      Duplicate The operating agent A, as part of the preliminary operations, determines using a hash code analysis whether a given electronic file is a duplicate of another electronic file. If so, that file is relegated to the subset S 2  and an appropriate indication is made in the log file entry for that file (see file F D ,  FIG. 5 ). Accordingly, as indicated by the block  120 , if in parsing a log file entry it is determined that a file is a duplicate a predetermined value indicator (e.g., “1”) is assigned to that file. A different value indicator (e.g., “−1”) is assigned to that file if it has not been previously identified as a duplicate.  
      In general, before the data structure  18  is populated with the numeric value indicators for each derivative attribute all entries are reset to a predetermined initial (or, default) value (e.g., “0”). Accordingly, it is preferred that, in most cases, each numeric value indicator assigned by the present invention is different from the default value.  
      Date As indicated in functional block  124  the operating agent A may be used to determine whether a given electronic file in the first and second subsets falls within a predetermined defined target date range. Assuming that a native attribute containing a date indicator is available either in the index I for a file in the first subset S 1  or in the log file L for a file in the second subset S 2 , that date indicator is arithmetically compared by the operating agent A to a target date range. If the date of the file falls within the predetermined defined target date range a predetermined value indicator (e.g., “1”) is assigned to that electronic file; otherwise, a different value indicator (e.g., “−1”) is assigned.  
      File Class Derivative Attribute The derivative attribute representative of the file class of the electronic file is generated in functional block  128 . For each electronic file in the first and second subsets S 1  and S 2  a derivative attribute having a value representative of a file class of the electronic file is created. The value of this file class derivative attribute provides an indication of the software application used to create the electronic file and/or the type of software application intended to open the electronic file.  
      Each electronic file in the subsets S 1  and S 2  is mapped uniquely to one of nine distinct file classes. These file classes (and their corresponding numerical value indicator) are:  
                                          I.   Critical    (2)       II.   Image   (−2)       III.   Audio/Visual   (−4)       IV.   System   (−1)       V.   Dictionary   (−3)       VI.   Compound (Further Processing)   (−5)       VII.   Other Known    (1)       VIII.   Unknown (Not Mapped)    (0)       IX.   E-mail Message    (3)                  
 
      Except for the E-mail message file class each of the file classes has assigned to it one or more file extensions.  
      A file having as its terminal file extension the extension “.doc”, “.xls”, “.ppt”, or “.pdf” is included in the “Critical” file class. The file extension “.doc” indicates that the file is created by the Word® word processor program available from Microsoft Corporation. A file created using the Excel® spreadsheet program available from Microsoft Corporation includes the extension “.xls”. A file created using the PowerPoint® presentation graphics program available from Microsoft Corporation has the extension “.ppt”. A file created using portable document format from Adobe Acrobat® electronic document distribution and exchange creation program available from Adobe Systems Incorporated includes the extension “.pdf”.  
      Files within the “Image” file class typically include files having the generic graphic image format file extension “.gif” or the bit-map image file extension ”.bmp”. Electronic files containing photos have the extensions “.jpg” , “.jpeg” “.jpe” are also included within this file class. A non-exhaustive list of other common file extensions included within the “Image” file class is set forth in the following List:  
                               List 1: Image File Extensions                                                            .ai   .clp   .dcx   .dib   .dwg           .eps   .fpx   .img   .jif   .mac           .msp   .pet   .pcx   .pic   .png           .ppm   .psp   .raw   .rle   .tif               .tiff       .wpg                      
 
      Exemplary among files included in the “Audio/Visual” file class are those having as a terminal file extension the extensions “.mp3”, “.wav”, or “.au”.  
      Commonly used extensions for files in the “System” file class include the extension “.exe” for executable files and the extension “.dll” for directory files. A non-exhaustive list of other common file extensions for this file class is set forth in the following List:  
                               List 2: System File Extensions                                                            .aba   .acq   .bat   .bi$   .bin           .cab   .cfm   .cls   .clx   .co$           .com   .ctx   .daz   .dbd   .ddd           .did   .dsk   .ex?   .ex —     .exa           .exz   .gid   .grd   .hdr   .hl$           .hip   .hiz   .li$   .lib   .lic           .lnk   .ncf   .ob?   .ocx   .pkg           .qdat   .ql$   .tda   .tlb   .ttf                      
 
      Exemplary of a file assigned to the “Dictionary” file class is a file having the terminal file extension “.ctl”.  
      Files in the “Compound” file class are files which, when examined by a human with the correct reader, contain a plurality of individual records which need to be handled with independent further processing. Some examples of file extensions typically encountered include in this file class include files with the terminal extension “.nsf”, “.mbx” or “.pst”. These extensions are all associated with electronic mail files. The file extension “.nsf” is used with the Lotus® Notes® email program available from IBM Corporation. The extension “.mbx” is included with messages using the Eudora® email program available from Qualcomm Incorporated. The extension “.pst” is included with the Outlook® communications program available from Microsoft Corporation. Other files included within the “Compound” file class include database files with the extension “.mdb” and a compressed file with an extension “.zip”.  
      As examples of file extensions typically encountered in the “Other Known” file class are the following: files having the extension “.afm” created using Abassis Finance Management Software from SmartMedia Informatica; files having the extension “.mso” created using the Microsoft FrontPage Web site creation and management program available from Microsoft Corporation; hypertext extensions “.htm” or “.html”; print extension “.prn”; and comma-separated values extension “.csv”.  
      An example of a file extension included within the “Unknown (Not Mapped)” file class includes the file extension [Null].  
      The generation of the file class derivative attribute for a collection E that includes at least one mail file is governed by a mail mapping rule (“Mail Message Mapping Rule”) and two electronic file mapping rules (“Electronic File Mapping Rule I”) and (“Electronic File Mapping Rule II”), respectively. The Mail Message Mapping Rules is indicated in the tables by the reference character “M”. The particular Electronic File Mapping Rule is indicated in the tables by the reference characters “I” and “II”, respectively.  
      For a set of electronic files that contains at least one mail file the operating agent A and a mail server gateway (e.g., the gateway W 2 ) are used to open the mail file. The file locator R for each of the plurality of electronic files in the opened mail file is parsed to determine the number of mail message markers (e.g., “!!”) found therein.  
      In accordance with the Mail Message Mapping Rule the electronic file is mapped to a predetermined file class based upon the number of mail message markers in the file locator. For example, in the preferred implementation of the present invention, the presence of only a single mail message marker in the file locator R serves as the basis for assignment of that file to a predetermined file class (here, file class IX-E-mail Message). The file class derivative attribute has a value of +3.  
      If two or more mail message markers are present in the file locator R the two Electronic File Mapping Rules are used to define the file class derivative attribute. In accordance with the Electronic File Mapping Rule I”, if for a given electronic file the terminal file extension native attribute is identified and the MIME type native attribute is not available, the value of the file class derivative attribute representative of that electronic file is determined by mapping that terminal file extension to its corresponding file class.  
      The application of this Electronic File Mapping Rule I is made clear from examples derived from Table 2. Recall that, in the typical instance, the MIME type for each electronic file in the second subset S 2  is not available. Accordingly, the file class for each of these electronic files is determined the terminal file extension.  
      In the case of electronic file F 1  ( FIG. 4A ) the file extension “.doc” maps this file to File Class I-Critical and is accorded a numerical value indicator of “2”.  
      For electronic file F 3  ( FIG. 4C ) the file extension “.mp3” mandates a mapping to File Class III-Audio/Visual. A numerical value indicator of “−4” is accorded to this file.  
      The file extension “.jpg” for electronic file F 4  ( FIG. 4D ) maps that file to File Class II-Image, with a numerical value indicator of “−2”.  
      The “.exe” extension for file F 6  ( FIG. 4F ) results in a mapping for that file to File Class IV-System. A numerical value indicator of “−1” is assigned.  
      The file F 8  ( FIG. 4H ), having the extension “.nsf”, results in a File Class VI-Compound (Further Processing). The numerical value indicator assigned is “−5”.  
      Electronic file F 10  ( FIG. 4J ) has the file extension “.dwg”. This extension results in that file being mapped to File Class VII-Other Known and the assignment of a numerical value indicator of (1). The “.239” terminal file extension for file F 11  ( FIG. 4K ) causes that electronic file to be mapped to File ClassVIII-Unknown. The numerical value indicator assigned has the value “0”.  
      The Electronic File Mapping Rule II is applied in instances in which both the terminal file extension and the MIME type native attributes are identified for an electronic file. In this situation a combination of these attributes is used to create the value of the file class derivative attribute and numerical value indicator.  
      In general, if the MIME type of a given file is an approved MIME type, then the mapping is determined by the MIME type. However, if that MIME type is not an approved MIME type the mapping is determined by the terminal file extension. Basically, if there is a mismatch between the MIME type and the file extension for a given file, the MIME type governs the mapping so long as the MIME type is an approved (trustworthy) MIME type. Otherwise, the file extension governs the mapping.  
      Whether a MIME type is an approved MIME type can be determined by testing the MIME type of a given file against a reference set of MIME types. The reference set may be configured in two ways: viz., to contain a list of approved MIME types; or to contain a list of unapproved MIME types. If the reference set is a list of approved MIME types, and if the MIME type under test falls within that list, then the MIME type is an approved MIME type. Alternatively, if the reference set is a list of unapproved MIME types, and if the MIME type under test falls within that list, then the MIME type is would be unapproved MIME type.  
      The MIME types included within a reference set of approved MIME types can be selected in any desired manner. The set can include any combination of the general MIME type categories and/or selected subcategories. The selection of the MIME types within the predetermined set of approved MIME types is usually determined empirically.  
      Generally speaking, the MIME types included within this set have proven to be trustworthy indicia of the application program creating a given file.  
      Accordingly, with this empirical baseline a representative reference of set of approved MIME types could be defined to include the following collection of general categories and subcategories:  
                               List 3: Representative Set of Approved MIME Types                                        [a]   image/gif       [b]   image/x-ms-bmp       [c]   image/x-photo-cd       [d]   audio/basic                         [e]   audio/x-wav                             [f]   x-music/x-midi                             [g]   video/x-msvideo           [h]   application/msword                     [i]   application/vnd.ms-excel       [j]   application/x-msexcel       [k]   application/x-excel       [l]   application/x- dos_ms_excel       [m]   application/vnd.ms-powerpoint       [n]   application/mspowerpoint       [o]   image/vnd.dwg       [p]   application/x-dvi       [q]   application/zip       [r]   application/mac-binhex40                  
 
      A reference set configured to include unapproved MIME types would contain MIME types that are typically assigned as a default, such as the following “text” subcategories:  
                                                      text/html   text/plain           text/richtext   text/x-sextet           text/enriched   text/sgml           text/x-speech   text/css                         text/tab-separated-values                      
 
      Each of the MIME types in the set of approved MIME types maps to a predetermined file class and associated numerical value indicator, as shown in the following Table:  
                       TABLE 3                       MIME Type   File Class   Value                  [a]-[c]   II. Image   (−2)       [d]-[g]   III. Audio/Visual   (−4)       [i]-[n]   I. Critical    (2)       [o]-[p]   VII. Other Known    (1)       [q]-[r]   VI . Compound   (−5)                  
 
      The electronic files in the first subset S 1  can be used to exemplify the application of the Electronic File Mapping Rule II. It can be seen from Table 1 that the identified MIME type for each of the files F 2  ( FIG. 4B ), F 5  ( FIG. 4E ) and F 7  ( FIG. 4F ) falls within the set of approved MIME types. Thus, the MIME type native attribute predominates over the terminal extension native attribute in determining the file class derivative attribute. Under this rule the files F 2 , F 5  and F 7  all map to File Class I-Critical.  
      However, in the case of electronic file F 9 , since the MIME type (“text/plain”) is not within the set of approved MIME types, the terminal extension “.ctl” determines the file class derivative attribute. The file is mapped by Mapping Rule II to File Class V-Dictionary.  
      The File Class derivative attribute for each of the electronic files in the collection E are summarized in Table 4.  
               TABLE 4                          File Class Derivative Attributes                                                 Derivative   File   Mapp-           Exten-       Attribute   Class   ing       File   sion(s)   MIME type   File Class   Value   Rule                                             F 1     .doc   Application/   File Class I   2   I               msword   Critical       F′ 1     .doc   Application/   File Class I   2   I               msword   Critical       F 2     .123   Application/   File Class I   2   II               x-pdf   Critical       F 3     .mp3   NOT   File Class III   −4   I               AVAILABLE   Audio/Visual       F 4     .jpg   Image/jpeg   File Class II   −2   I                   Image       F 5     .jpg   Application/   File Class I   2   II               msword   Critical       F′ 5     .jpg   Application/   File Class I   2   II               msword   Critical       F″ 5     .jpg   Application/   File Class I   2   II               msword   Critical       F 6     .exe   Application/   File Class IV   −1   I               octet-stream   System       F 7     [NULL]   Application/   File Class I   2   II               ms-excel   Critical       F′ 7     [NULL]   Application/   File Class I   2   II               ms-excel   Critical       F 8     .nsf   NOT   File Class VI   −5   I               AVAILABLE   Compound       F 9     .ctl   NOT   File Class V   −3   II               AVAILABLE   Dictionary       F 10     .dwg   Image/   File Class VII   1   I               Vnd.dwg   Other Known       F 11     .flpr.239   NOT   File Class   0   I               AVAILABLE   VIII                   Unknown       F 12     [NULL]   Text/plain   File Class IX   3   M                   E-mail Message       F 13     [NULL]   Text/plain   File Class IX   3   M                   E-mail Message       F 14     [NULL]   Text/plain   File Class IX   3   M                   E-mail Message       F 15     .zip   Application/   File Class VI   −5   I               zip   Compound                  
 
      In accordance with this invention, if the collection E of electronic files does not include a mail file, then the Mail Message Mapping Rule is not invoked but is skipped. In that instance the appropriate Electronic File Mapping Rule I or Electronic File Mapping Rule II are directly applied.  
      The creation of the derivative attributes in the blocks  132 ,  136  and  140  is implemented using the operating agent A.  
      Readability As indicated in block  132 , for each electronic file in the first and second subsets a derivative attribute having a value representative of the amount of electronically readable text in the electronic file is created.  
      If an electronic file is in the first subset, the value of the readability derivative attribute is based upon the presence of at least some predetermined threshold number of readable characters in the accessible character strings. Typically, the predetermined number is on the order of twenty characters. If a file contains more than the predetermined number of readable characters it is deemed “readable” and assigned a predetermined value indicator (e.g., “1”). Otherwise, it is deemed “not readable” and assigned a different value indicator (e.g., “−1”) is assigned. For electronic files in the second subset the value of the readability derivative attribute is based upon the presence of that file in the second subset. It is assumed that by the mere fact of inclusion in the second subset the file is “not readable” and the value indicator (e.g., “−2”) is assigned.  
      The readability derivative attribute for each of the electronic files in the collection E are summarized in Table 5.  
                           TABLE 5                                       Readability               Derivative           Electronic Files   Attribute                                                    F 1     −2           F′ 1     −2           F 2     −1           F 3     −2           F 4     −2           F 5     1           F′ 5     1           F″ 5     1           F 6     −2           F 7     1           F′ 7     1           F 8     _2           F 9     1           F 10     −2           F 11     −2           F 12     −2           F 13     1           F 14     1           F 15     −2                      
 
      Relevance In accordance with another aspect of the method of the present invention the native attribute(s) for each of the files in the second subset S 2  as identified in the log file L is(are) used to generate another derivative attribute representative of the file&#39;s relevance to a predetermined issue. This action is indicated in the block  136 .  
      The derivative attribute has a value representative of the file&#39;s relevance based upon the presence or absence of at least one of the target character strings in the identified native attribute.  
      To determine this derivative attribute the full file locator native attribute in the log file is tested against target character strings T, P and V.  
      A positive value of the relevance derivative attribute for each file in the second subset is determined by the number of character strings in the file that fall within the appropriate set of target character strings. If the file is not relevant, the value of the derivative attribute is the default value of “0”.  
      The full file locator native attribute is also tested against the privilege and confidentiality target character lists.  
      The relevance, privilege and confidential derivative attributes for each of the electronic files in the collection E is summarized in Table 6. The electronic files in the first subset S 1  are included in Table 6 for completeness and are denoted by the “*” symbol.  
                                   TABLE 6                                       Relevance   Privilege   Confidential           Electronic   Derivative   Derivative   Derivative           Files   Attribute   Attribute   Attribute                                                            F 1     1   0   0           F′ 1     1   0   0           *F 2     0   0   0           *F′ 2     0   0   0           F 3     0   0   0           F 4     0   0   0           *F 5     4   1   1           *F′ 5     4   1   1           *F″ 5     4   1   1           F 6     0   0   0           *F 7     0   0   0           *F′ 7     0   0   0           F 8     0   0   0           *F 9     17   0   0           F 10     1   0   0           F 11     0   0   0           *F 12     0   0   0           *F 13     0   0   0           *F 14     0   0   0           *F 15     0   0   0                      
 
      Context Filter The operating agent A is also used to apply the context filter to electronic files in the second subset S 2 . Each readable character string in the identified native attribute of each entry in the log file is tested by the context filter X ( FIG. 1 ). This action is indicated in functional block  140 . If the file is filtered-out a predetermined value indicator (“1”) is assigned to that electronic file; otherwise, a different value indicator (“0”) is assigned.  
      The application of the context filter to documents in the second subset is not expressly exemplified.  
      As seen from  FIG. 7  at the output of each of the blocks  120 ,  124 ,  128 ,  132 ,  136  and  140 , the value of the derivative attribute created for each file is written into a two-dimensional data structure  18 . This action is indicated by the blocks  144 . A representation of the relevant portion of the data structure  18  so populated is illustrated in  FIG. 8 .  
      Since no date range is defined herein, it is noted that the date values included in column  154  of the data structure for files in the first subset are hypothetical. However, with regard to files in the second subset since the preferred operating agent A identified earlier does not extract the date native attribute from those files, the value of the derived attribute is automatically set to the value “1” (a file cannot be excluded based on the absence of a date).  
      Each derivative attribute is assigned one respective dimension (e.g., a column) in the two-dimensional data structure. A column is also reserved for a suitable file identifier (e.g., file locator). Taken along the other dimension of the data structure (e.g., a row) the data structure groups the value of each derivative attribute created for an electronic file identified by the file identifier into a record. In  FIG. 8  the derivative attributes for the files F 1  through F 15  here under discussion, as well as an illustrative entry for the F D  ( FIG. 5 ), are shown.  
      As seen from  FIG. 8 , the column  150  contains the file identifier for each file. The columns  152 ,  154 ,  156  are respectively dedicated to the values of the derivative attributes representative of the duplicate, date and context filter. The values assigned for the file class derivative attribute are collected in the column  158 . The values assigned for the readability derivative attribute are contained in the column  168 .  
      The derivative attributes for relevance, privilege and confidentiality are contained in the columns  162 - 166 , respectively.  
      In the case of a duplicate file, the custodian of any duplicate files is recorded, as indicated at functional block  146 .  
      A detailed flow diagram of the routing logic  104  ( FIG. 6A ) is shown in  FIGS. 9A and 9B . See also, “Code Listing 9” in the Appendix. In general, once the file class derivative attribute is determined and the data structure  18  ( FIG. 8 ) populated, the derivative attributes are used to assign each electronic file in the first and second subsets to a selected state representative of the specific recommended actions shown in  FIG. 6A , viz., Archive (block  106 ); review by a human reviewer (blocks  108 A or  108 B); or identification as fully Responsive (block  110 ).  
      A value representative of the recommended action for an individual electronic file is recorded in column  169 A of the data structure  18 . If the recommended action for a file is Archive a value “1” is recorded in column  169 A. Human Review by an Subject Matter Expert is assigned the value “2”, while review by an Information Technologist is assigned the value “3”. Fully Responsive is assigned the value “4”.  
      The routing logic is sequentially applied to each file in the collection (including the copies F′ 1 , F′ 2 , F′ 5 , F″ 5 , and F′ 7 ). This classifies each electronic file in the set into one of the predetermined plurality of recommended actions. The values for the derivative attributes for each file in the collection (i.e., a row of the data structure  18 ) are used by the routing logic to make particular decisions about that file.  
      As indicated by the blocks  170 ,  174 ,  176  and  177  certain preliminary pruning operations are first performed.  
      In the block  170  the electronic file being routed is tested to determine whether it is a duplicate of another file. For example, in the case of the file F D  ( FIG. 5 ) the presence of the particular value indicating that this file is a duplicate (i.e., the value in column  152  of the data structure for the row having this file identifier) results in this file being routed to the archival repository.  
      The derivative attributes representing whether a file falls within the predetermined date range and within the context filter (i.e., the values in columns  154  and  156  of the data structure for the row having the given file identifier) are respectively tested functional blocks  174  and  176 . If a given file is outside the date range or the context filter it is routed to the archival repository.  
      As shown in functional block  177 , an E-mail message that has an asserted (“ON”) privacy flag is routed to an information technologist expert who is able to unlock the message.  
      The value of the file class derivative attribute for a given file is tested in the block  178 . Depending upon the value of the numerical indicator in column  158  of the data structure for the row having the given file identifier, the file is routed to one of nine data blocks  180 - 195 .  
      Files in System (File Class IV) or Dictionary (File Class V) are routed directly to the archive.  
      Files in Compound (File Class VI) or Unknown (File Class VIII) are routed directly for human review by an information technology expert. Files in Audio/Visual (File Class III) are sent for human review by a subject matter expert.  
      For electronic files in Image (File Class II) or Other Known (File Class VII) the value of the numerical indicator for the derivative attribute in column  162  of the data structure for the row having these file identifiers is tested for relevance in the blocks  198 A,  198 B. Depending upon the outcome of the test (in the block  198 A) an Image file is assigned for human review by a subject matter expert or directly to Responsive. For a file in the class “Other Known” the outcome of the test in the block  198 B is routed either to Responsive or subjected to a readability test in the block  202 A. In the block  202 A the value indicator in column  168  of the data structure for the row having this file identifier determines whether the file is routed to the Archive or for Human Review by a subject matter expert.  
      If an electronic file from subset S 2  is routed to Critical (File Class I) it is directed for review by an information technology expert as indicated by the block  204 . A file from subset S 1  is that is routed to Critical (File Class I) is tested for relevance and readability in the blocks  198 C and  202 B. Depending upon the results of these tests the file is directed to Responsive (from the block  198 C) or to the Archive or for Human Review by a subject matter expert (from the block  202 B).  
      As with an electronic file routed to Critical (File Class I), an electronic file routed to E-mail Message (File Class IX) has its subset checked as indicated by the block  203 . An electronic file from the subset S 2  is directed for review by an information technology expert. An electronic file from subset S 1  is tested for relevance in the block  198 D. Depending upon the results of this test the electronic file is directed to Responsive (from the block  198 D) or to the Archive.  
      Once each electronic file has been individually treated and classified into one of a predetermined plurality of destination states by the routing logic  104  ( FIG. 6A ) file groups are identified and treated (blocks  115 ,  117 ,  FIG. 6B ).  
      As alluded to earlier, in block  154  the overall collection E of electronic files is subdivided into two different subsets, viz, subset S 3  (parents) and subset S 4  (non-parents). The pointer native attribute is used to identify parents. All electronic files that have an entry in the “File Pointer” column (Table 1) are identified as parents and assigned to the subset S 3 .  
      Once an electronic file is identified as a parent, file groups (E.G., FG 1 , FG 2 , FG 3 ) are defined. This action occurs in block  117  ( FIG. 6B ). The pointer native attribute(s) contained in each parent is(are) used to identify the child(ren). A parent and the child(ren) corresponding thereto comprise a file group (either FG 1 , FG 2 , or FG 3 ;  FIG. 6B ).  
      For example, since the pointer in the electronic F 13  ( FIG. 4M ) identifies the electronic file F′ 5 , the file group FG 1  includes the parent electronic file F 13  and its child electronic file F′ 5 . Similarly, the pointer in the electronic F 14  ( FIG. 4N ) identifies the electronic file F′ 1 . Thus, the file group FG 2  includes the parent electronic file F 14  and its child electronic file F′ 1 . In the case of parent electronic file F 15 , three electronic file pointers are included therein. The file group FG 3  thus includes the parent electronic file F 15  and its three children, electronic files F′ 2 , F′ 7  and F″ 5 .  
      Once identified, each file group is classified into one of the predetermined plurality of recommended actions. To effect this classification the recommended action for each electronic file in a file group is examined. The classification of a file group into its group recommended action is based upon the highest-ordered recommended action of any of the electronic files in the group.  
      In the case of file group FG 1  the parent electronic file F 13 has a recommended action of Archive corresponding to value D in the hierarchy. The child file F′ 5  has a recommended action Responsive with a value B in the hierarchy. Since the hierarchical value of the child is greater that that of the parent, the file group is assigned a group recommended action of Responsive (hierarchical value B).  
      Similarly, for file group FG 2  the parent electronic file F 14  also has a recommended action Archive (hierarchy value D) while the child electronic file F′ 1  has a recommended action Information Technologist (hierarchy value A). Since the hierarchical value A is greater than hierarchical value D the file group is assigned a group recommended action of Information Technologist (hierarchy value A).  
      For the file group FG 3  the highest individual hierarchical value for any electronic file in the group is Responsive (electronic file F″ 5 , hierarchy value B) Thus, the overall file group is assigned a group recommended action of that recommended action.  
      In this way each file group FG 1 , FG 2  and FG 3  is assigned to only one of the four recommended actions  106 ,  108 A,  108 B,  110 .  
      The group recommended action for each file group is indicated in column  169 B of the data structure  18  ( FIG. 8 ).  
      Once electronic files are identified as Responsive, this subset of files must be delivered to a recipient. In the data structure of  FIG. 8  such electronic files are indicated by the derivative attribute having the value “4” in the Recommended Action column  169 A (for an individual file) or in the Group Recommended Action column  169 B (for a file constituent in a compound file). These individual files include electronic files F 5  and F 10 . File constituents include electronic files F′ 2 , F′ 5 , F″ 5 , F′ 7 , F 13  and F 15 .  
      Delivery of individual electronic files is straightforward. A forensic copy of the original electronic file is created on a media or in a location where the recipient can have access to the subset of electronic files. For instance, a copy may be made onto a CD, DVD, or on an FTP site.  
      Delivery of a subset of electronic files contained as file constituents in a compound file (i.e., either a mail file or a “.zip” file) is more problematic. In the present instance, the mail file “doej2.nsf” contains electronic file F 12 , which is not Responsive (and therefore not to be delivered) mixed in the same compound file with electronic files F′ 2 , F′ 5 , F″ 5 , F′ 7 , F 13  and F 15 .  
      Accordingly, in another aspect, the present invention is directed to a method and program for separating selected file constituents from a compound file.  
       FIG. 10  is a flow diagram of the exporting and processing for delivery of file constituents from a compound file in accordance with the present invention.  
      As fully described above the data structure  18  ( FIG. 8 ) contains, in columns  169 A and  169 B thereof, the recommended actions for individual electronic and file groups, respectively. The data structure is indicated diagrammatically at the head of  FIG. 10 .  
      As indicated in block  301 , in order to create a subset of file constituents from a compound file such as “doej2.nsf”, the data structure  18  is used to export, in standard text file format, the unique file identifiers [e.g., message identifiers ( FIG. 3B )] in columnar format. A code listing for the block  301  in ColdFusion MX 6.1 language is set forth in the Appendix.  
      A stylized representation of such a standard text file  303  is illustrated in  FIG. 11 . The first row  303 A of the text file  303  indicates the name of the compound file, in this example, “doej2.nsf”. The text file  303  may include one or more optional folder identifiers (e.g.,  303 B 1 ,  303 B 2 ,  303 B 3 ) identifying categories into which file constituents can be grouped.  
      The list of message identifiers contained within each folder  303 B 1 ,  303 B 2 ,  303 B 3 , as the case may be, is indicated by the reference characters  303 C 1 ,  303 C 2 ,  303 C 3 . If no optional folder identifier(s) is(are) present, a single listing of message identifiers is presented under the compound file name.  
      The folder  303 B 1  contains the message identifiers of all file constituents that have been identified as “Responsive” but neither “Privileged” nor “Confidential”. The message identifier for the message F 13  falls in this class and is indicated in bold text in  FIG. 11 . Note that, since the message identifier of child(ren) file(s) is(are) identical to the message identifier of its(their) parent, child(ren) file(s) is(are) not specifically listed. Child(ren) file(s) stays appended to its(their) parent message. Thus, the child file F′ 5  of the file F 13  is not is not specifically listed.  
      In a similar manner the folder  303 B 2  contains the message identifiers of file constituents that have been identified as “Responsive” and “Privileged” but not “Confidential”.  
      The folder  303 B 3  contains the message identifiers of file constituents that require the review by an Information Technologist. The message F 14  falls in this class and its message identifier is indicated in bold text in  FIG. 11 .  
      The text file  303  is input into a functional module  305 . The functional module  305  includes code that creates a forensic copy of the compound file “doej2.nsf”.  
      The functional module  305  next segregates the file constituents without removing them from the forensic file and without changing any native attribute of a file constituent. In the preferred instance this segregation is performed by deleting from the forensic copy all file constituents not present on the list. A code listing for the functional module  305  in Lotus® Script language is set forth in the Appendix.  
      Note that since child(ren) is(are) not listed, it(they) is(are) not explicitly deleted but is(are) either kept or deleted with the parent.  
      After processing by the functional module  305  the processed forensic compound file now contains the appropriate subset of file constituents. This processed compound file is able to be sent to the recipient, as indicated in the block  307 .  
      As may be appreciated from the foregoing the present invention provides a method, program and data structure that identifies electronic files from a set of files in a manner that is cheaper, easier, more trustworthy and more accurate.  
      In the instance where the set of electronic files includes a mail file or other type of compound file all electronic files contained in the compound file are properly processed and tracked.  
      Use of the present invention is believed cheaper and easier because it minimizes the number of electronic files that require human intervention by eliminating duplicates (while retaining significant custodial information) and eliminating system and dictionary files (e.g., file F 9 ) which may be otherwise erroneously identified as relevant.  
      The present invention is believed to provide a more trustworthy and more accurate result because it processes files which may be critical to the issues at hand but which heretofore are relegated to the log file and not considered. For instance, both password locked file F 1  and drawing file F 10  are relevant to the issues of the example developed herein, but these important files would previously be discarded. The present invention avoids the problem (exemplified by the file F 2 ) of falsely identifying a file as not relevant because no readable text is found when, in fact, the file is highly relevant for the issues of the lawsuit.  
      The present invention permits file constituents to be manipulable while continuing to reside inside the compound file. Thus, the file constituents are unmodified. Therefore a subset of these file constituents may be delivered without influencing the data of the file constituents.  
      Those skilled in the art, having the benefit of the teachings of the present invention as hereinabove set forth, may effect modifications thereto. Such modifications are to be construed as lying within the contemplation of the present invention, as defined in the appended claims.