Litigation Support System and Method

I. Field of Invention

A litigation support system and method in which information regarding documents and other items of evidence are stored in record fields of an electronic database using an optical scanning mechanism with an ability to scan bar codes or other indicia means.

II. Description of the Prior Art

Litigation support systems can generally be classified into two different categories, "full text" systems, wherein each document or other item of evidence is either optically scanned and converted into computer readable data or manually keyed into a computer memory, and "bibliographic" systems, wherein only selected information from or about each document or other item of evidence is captured for manipulation by a computer. Both types of systems store and retrieve the recorded data using various computer database systems.

In a full text system, the recorded data is usually retrieved by performing word searches through a full text database. For example, a search might comprise an inquiry to find all documents wherein the word `litigation` is used within five words of `anticipate`. A resulting search through the full text database would yield a list of documents or other items of evidence meeting the above search criteria.

The benefits of full text systems have been questioned. First, the cost involved in scanning and converting each document or other item of evidence into a computer readable format to generate a full text database can be substantial. Second, the substantial storage requirements and search times needed to properly access a full text system can render such systems ineffective for litigation purposes. Finally, to establish an accurate full text system, each scanned or manually keyed document must be checked against the original document to assure an accurate conversion has been achieved. As a result of these and other problems associated with full text systems, users frequently decide to only record bibliographic information.

Bibliographic systems offer significant advantages over full text systems. These systems allow specific bibliographic information to be recorded, for example, a document's author, addressee, date, and general subject matter. Bibliographic systems cost less on average to generate and require significantly less storage space compared to full text systems. Additionally, search times are decreased in such systems when compared to full text systems. For a complete analysis of an improved type of bibliographic system see Feiler, William S., "Computer Aided Litigation Support In Patent Litigation", The Journal Of Law And Technology, pp. 177-190 (1983).

Searches in a bibliographic system might be more restricted when compared to full text systems but are still very informative. Searches are usually of the type as follows: all documents wherein Author=`Smith J.` and Topic=`litigation`. The results of this type of search will be a list of all records that have been "coded" (i.e., recorded) as Author: "Smith J." and Topic: "litigation".

Although bibliographic systems offer advantages over full text systems they do require substantial coding time and accurately stored information. In fact, with bibliographic systems, accurately stored information is extremely important due to the nature of bibliographic search requests. Specifically, if a person who is coding information misspells an author's name, that record may be lost in all searches of the system relating to that author's name.

Using the example stated earlier, a person coding a document authored by John Smith might manually enter "Simth, J.". When a search is performed for Author="Smith J.", the record with the misspelled entry will not be retrieved. As a result, that record will not be identified in that particular search diminishing the value of the bibliographic system.

Additionally, if a person coding a document enters an improper candidate for a record field entry, that misentered record field may not be identified during searches since the improper candidate may not be known to the person who later searches the system. As a result, those misentered records may become lost to the person searching the system further diminishing the value of the bibliographic system.

Continuing with the example as stated above, if a person coding a document types Topic="lawsuit" as a candidate for "litigation," any search of the database for Topic="litigation" will not retrieve that misentered document.

Those skilled in the use of these systems normally take steps to attempt to eliminate the above-identified errors in databases by developing protocols to prevent their introduction. Such steps are far from completely effective and require rigid procedures to try to contain such errors.

Additional problems exist in current bibliographic systems. When coding a bibliographic system repetitive entries are often encountered requiring system operators to retype the same entries with each encounter. Such redundancy is inefficient and adds to the time required to code those entries and can cause potential errors.

Therefore, it is an object of this invention to improve existing litigation support systems by incorporating an optical scanning means capable of recognizing indicia placed on documents or other items of evidence.

Another object of this invention is to create a litigation support system that uses a single indicia means for relating several databases to permit separate and independent coding operations.

Another object of this invention is to use bar code technology in combination with a litigation support system to allow accurate coding and simple retrieval of information.

Another object of this invention is to use an authority list of indicia corresponding to input candidates for record field entries to allow a person to consistently and accurately input information thereby increasing the value of a litigation support system.

Objects and advantages of the invention are set forth herein and will also be readily appreciated here from, or may be learned by practice with the invention. These objects and advantages are realized and obtained by means of instrumentalities and combinations pointed out in the specification and claims.

The present invention relates to using bar code technology in a litigation support system for two purposes. First, by using a unique bar code on a document a single indicia means is created to be used through out a litigation support system. A single indicia means provides for both an easier method of coding bibliographic information as well as an easier method of recalling information. Second, by generating bar code authority lists for input candidates to be used for particular field entries, the accuracy of a bibliographic system is significantly improved while coding time is reduced thereby adding substantial value to the litigation support system.

The accompanying drawings illustrate principles and preferred embodiments of the present invention, and together with the description serve to explain the principles of the invention, in which:

FIG. 1 shows a diagram of the type of hardware used to run a litigation support system of the present invention.

FIG. 2 shows a preferred relational database structure using a single indicia means as a relation between topical databases.

FIGS. 3A and 3B show authority lists of input candidates for various record field entries.

FIG. 4 shows a schematic diagram of various sub-system input stations used to code mass volumes of production documents and the particular topical databases of FIG. 2 those stations update.

FIG. 5 shows a system display screen of the present invention. The screen is used by a system operator to view, edit, or add records and/or code deposition and trial exhibits.

The present invention relates to a system and method for improving litigation support systems. By using bar codes in combination with an optical reader to scan document numbers and to generate authority lists for coding those documents, the performance and accuracy of a litigation support system is dramatically improved.

Disclosed below are various preferred embodiments of the claimed invention. Although the systems and methods disclosed in the figures and described herein are directed to the use of bar codes the claimed invention is not limited to same and can be used with any scannable indicia.

FIG. 1 shows a preferred hardware configuration for the present invention. The litigation support system 1 includes a computer system 3, an optical scanning means 5, here a hand held light pen and interface, a keyboard 7 and a computer monitor 9. A high speed printer, not shown, such a Hewlett Packard Laser printer, is desirable for generating reports. Generally, the preferred central processing unit of computer system 3 for running a completed litigation support system should be at least a 32 bit microprocessor. The use of smaller class microprocessors, i.e. 16 bit or 8 bit microprocessors, may degrade the system's performance and negate the benefits achieved by the present invention. Additionally, the data storage capability for the computer system 3 should have the capacity to store both the system's database software as well as the coded document information. Usually this requires a storage capacity of at least 20 megabytes of disk storage and is most preferably 100 megabytes. As is readily apparent to those skilled in the art, the storage requirement for "fixed-length" field databases, i.e. databases wherein each record field has a fixed character length, is directly proportional to the number of documents or other items of evidence recorded by the litigation support system. As the number of records increase the required storage capacity increases proportionally. Additionally, the amount of bibliographic information recorded per document or other item of evidence, i.e. the number of fields per record, will also effect the storage requirements in a like manner.

The term "document" as used herein is intended to be broadly construed to cover all types of evidence encountered in litigation-type proceedings. The term document means any written, printed, typed or other graphic or photographic matter, including microfilm of any kind or nature, and any electronic storage medium such as cassettes, floppy disks and tapes. Additionally, the term document includes originals and drafts of all papers, books, letters, telegrams, cables, correspondence, contracts, agreements, notes to files, polls, surveys, reports, mechanical and electronic sound recordings or transcripts thereof, calendar or diary entries, memoranda of telephone or personal conversations or of meetings or conferences, studies, intra- and inter-office communications, notes, notations, work papers, price lists, bulletins, circulars, statements, manuals, summaries or compilations, minutes of meetings, maps, charts, graphs, photographs, order papers, articles, announcements, catalogs, records, lists, tables, affidavits, evaluations, journals, summary of accounts, balance sheets, income statements, tabulations, books of account, ledgers, vouchers, canceled checks, invoices, bills or analyses or statistical data, and computer printouts. The term document also includes physical evidence, such as models, samples and demonstrative evidence.

The litigation support system can be run on a variety of different computer and operating systems. The preferred computer system is an IBM personal computer or compatible using PC-DOS or MS-DOS as an operating system. A particularly preferred system is a Compaq Deskpro 386/20e with 110 megabyte disk storage capacity.

Additionally, as is readily apparent to those skilled in the art, the litigation support system identified above can run effectively on currently available portable computer systems. The advantages of using a portable computer systems are several. For example, a person who is responsible for coding documents or other items of evidence can easily transport a portable computer system to where the evidence is located to code same on site and thereby avoid the complexity involved with delivering evidence to a central location. Also, the use of a portable computer system allows a person to operate the litigation support system in a courtroom, at a deposition, or at any other remote cite without having to transport and install a more complicated desktop computer system.

Although any optical scanning means for scanning indicia can be used with the present invention, the use of a hand held light pen or wand is preferred. Generally, the optical scanning means 5 includes an interface between the computer system 3 and keyboard 7 to allow information to be scanned and converted as if the information were typed by hand using keyboard 7. The use of keyboard 7 is preferred when free-text entries are required, for example, attorney comments, document dates, and the like. In the preferred embodiment, bar code readers such as the "WDP Reader" LED light pen by Worthington Data Solutions of Santa Cruz, Calif. and "EZ Bar code" laser light gun by Time Keeping Systems, Inc. of Cleveland, Ohio have been used with the present invention; the former being preferred for ease of use.

Various types of database software can be used with the present invention. The software compiler used in the preferred embodiment is Clipper.TM., Summer 1987 version sold by Nantucket Corporation of Los Angeles, Calif., which uses fixed-length fields. The source code for the preferred program, as described below, is set fourth in Appendixes 1 through 28. Other software is also available which may be used to operate the litigation support system, including for example, Advanced Revelation.TM., which uses variable-length fields.

Clipper.TM., as well as other current database software, allows a system operator to set up various databases with numerous record fields within each database. The structuring freedom of Clipper.TM. allows the stored information to be sorted or searched in a variety of ways thereby increasing a system's overall value. Nevertheless, as is readily apparent to those skilled in the art, the more fields created per record the more inputting or "coding" is required to complete a record and more data storage is required for the record information. Therefore, the choice of how and what bibliographic information is to be recorded, i.e. the number and type of topical databases to use and the number of fields to use per database record, should be made wisely.

FIG. 2 shows a preferred relational database which comprises six separate topical databases. The Document database 21 of the litigation support system contains all document information including a document's bar code, production number, description and the like. The People database 23 contains the names of all the people identified in a document as well as the company they work for and whether they have been an author or addressee for a particular document or group of documents. The Comment database 25 contains all attorney comments for the documents stored on the litigation support system. The Deposition database 27 contains information relating to all of the exhibits identified during depositions. The Deposition Witness database 29 contains information relating to all of the deposition witnesses. The Trial database 31 contains information relating to all of the exhibits and witnesses used at trial.

All of the separate databases are related through a unique bar code 19. By establishing a relational database with a unique code to identify each document, the simplicity of retrieving all information related to a particular document is dramatically improved. A system user can quickly scan a bar code off of any document and interrogate the system to retrieve information stored in the relational databases relating to that document.

Tables 1 through 6 listed below indicate the preferred fields per database record for each of the related topical databases:

The abbreviated field names in the above Tables are fairly descriptive of the information contained in each record field. Additionally, the preferred field type and width are included to complete each record's structure. Field type and width are used in a database dictionary to allocate storage space for the database's fixed-length fields.

Table 1 represents the preferred fields used for each record stored in the Document database 21. The field BAR.sub.-- CODE represents the field for the scannable indicia used to identify the particular document, here a bar code. The BAR.sub.-- CODE or other scannable indicia can be limited to only numeric data or alphabetical data. Preferably, the BAR.sub.-- CODE field is an "alphanumeric" character string, i.e., capable of being able to record both alphabetical or numeric data, and of at least 8 characters in length. PROD.sub.-- NO represents the starting production number on the document and PROD.sub.-- NO END represents the ending production number of the document. If the document is more than one page, the TOTAL.sub.-- PAGE field is used to calculate the difference between PROD.sub.-- NO and PROD.sub.-- NO END. The field DUPLICATES is used to indicate whether duplicates of the document are already in the database. The field SOURCE is used for the source of the document, for example, the name of the firm producing the document. DOC.sub.-- DATE is the field used to indicate the date of the document. The field MASKED is used to indicate "yes" or "no" as to whether the document has been masked or redacted in production. The field IN.sub.-- MARGIN is used to indicate whether any handwriting is present in the margin or on the document. The field DOC.sub.-- TYPE is used to identify the type of document or other item of evidence, for example, memorandum, letter, brochure, floppy disk or cassette. The field CONFID is used to indicate whether the document has been designated as confidential. The field DESCRIPT is used to enter a description of the document. The field KEY.sub.-- WORD is used to indicate whether any key words are used in the document. The field RATING is used for the rating of the document, usually on a scale of zero to three in order of importance. The field TAG is used to tag the file. The field PRIOR.sub.-- ART is a field used in patent litigation and indicates whether the document is prior art to a patent in suit. The field IMMUNITY is used to indicate whether there is any immunity against discovery, for example, work product or attorney-client communication. The field PRODUCEDTO is used to indicate to whom the document has been produced for record keeping purposes in multi-party litigations. Finally, FLAG.sub.-- 1 through FLAG.sub.-- 5 are used to flag the document for various document groupings, for example, a foreign language document.

Table 2 represents the preferred fields used for each record stored in the People database 23. The field BAR.sub.-- CODE is the same field as used in the Document database 21. The field NAME contains the name of the person on a document and the field NAME.sub.-- FIRM is used to identify the company with which the person's named is affiliated. The field ACTION is used to describe the activity of the person with respect to the document, for example, author, addressee or copy recipient.

Table 3 represents the preferred fields used for each record stored in the Comment database 25. BAR.sub.-- CODE and PROD.sub.-- NO are the same fields as used in the Document database 21. The only additional field in Comment database 25 is the COMMENT field. The COMMENT field is used to record any comments regarding the document being coded. As discussed below, comments may be of the free-text variety or from an authority list.

Table 4 represents the preferred fields used for each record stored in the Deposition Exhibit database 27. The BAR.sub.-- CODE field is the same field as defined above. An additional field called DEPO.sub.-- EXH is used in the Deposition Exhibit database 27 to define a deposition exhibit number if assigned to the coded document.

Table 5 represents the preferred fields used for each recorded stored in the Deposition Witness database 29. The BAR.sub.-- CODE field is again the same field as defined above. Additionally, the Deposition Witness database 29 uses a WITNESS field to record the name of the deposition witness and an ACTION field to record the relationship of the witness to the deposition exhibit, for example, authenticated, marked, or examined.

Table 6 represents the preferred fields used for each record stored in the Trial database 31. The BAR.sub.-- CODE field is the same as defined above. Additionally, the Trial database 31 uses the fields TRIAL.sub.-- EXH to record the trial exhibit number assigned to the document, WITNESS to record the trial witness' name who is to be examined regarding the document, OBJECTION to record what, if any, objection is made to the use of the document as a trial exhibit, and OFFER.sub.-- ADM to indicate whether the document was offered into evidence and admitted by the fact finder.

As is readily apparent to those skilled in the art, the relational databases as well as the structures used therein for each database can be varied to suit the particular case where the litigation support system is being used. For example, the above identified Document database 21 has a PRIOR.sub.-- ART field which can be used for patent litigation. For trademark litigation, fields such as CONFUSE can be used to define documents that evidence actual confusion. For copyright litigation, a field named ACCESS can be used to identify documents which evidence an alleged infringer's access to a copyright holder's material.

Once a litigation support system is configured with the computer system hardware, software, and relational database as described above, the system is ready for coding production documents.

Before any document is entered into the litigation support system, some initial decisions should be made. Specifically, a decision must be made as to whether to place a bar code or other indicia means on every page of a produced document or to place a bar code or other indicia means on only the first page of every document. Although the litigation support system allows for either alternative, in the preferred embodiment bar codes are placed at every page. By placing a bar code on every page, the bar codes can be designed to correspond to each production number thereby significantly simplifying both the document coding as well as the overall operation of the litigation support system.

Any of the available types of bar codes may be used for the litigation support system. Generally, there are ten different commercial bar code formats: Code 39, Full ASCII, Interleaved 2 of 5, UPC-E, UPC-A (with or without supplements), EAN-8, EAN-13, Codebar, MSI/Plessey and Code 128. The code used in the preferred embodiment is Code 39 since it allows the use of up to 40 alphanumeric characters per entry. Any commercial bar coding software program can be used to generate bar code labels for placement on production documents. Code 39 is preferred for generating bar code authority lists for field inputs as described below.

After the bar code labels have been generated and placed on the documents, the next step is to generate bar code authority lists for known input candidates. Generally, each record field of a database has a finite number of choices of information ("candidates") which lends itself to the use of authority lists.

FIG. 3A is an example of an authority list for the DOC.sub.-- TYPE field and includes two columns 32 and 33. Column 32 represents a listing of various documents types that might be encountered in a particular document collection. Generally, the types of document to be coded at a particular time or for an entire litigation can be anticipated and listed as shown in FIG. 3A. Column 33 represents the corresponding bar code for each document type listed in column 32. As discussed above, any commercial bar coding software program can generate a list similar to that shown in FIG. 3A. A suitable program is "Labelright" available from Worthington Data Solitions.

When encountering a prompt from the litigation support system to code the DOC.sub.-- TYPE field, the system operator selects from list 32 the appropriate response and scans the corresponding bar code from column 33. The optical scanning means then automatically converts the signal generated by scanning the bar code into a signal equivalent to that generated by a keyboard and forwards same to the computer system. As a result, coding of the DOC.sub.-- TYPE field is consistently and accurately performed.

FIG. 3B is a multiple field authority list for NAME and NAME.sub.-- FIRM candidates that appear on a group of documents. A multiple field authority list is similar to a single field authority list in that it is comprised of two columns, a list of input candidates 35 and corresponding bar codes 37. Here though, column 35 represents two fields, specifically, a list of NAME field candidates combined with a list of associated NAME.sub.-- FIRM field candidates. Column 37 represents the corresponding bar code equivalent of the names and firms listed in column 35. A multiple field authority list, such as the NAME and NAME.sub.-- FIRM list of FIG. 3B, can be designed to input data into several fields simultaneously. For example, Code 39 can generate 40 characters, of bar code. By selecting field lengths for the NAME and NAME.sub.-- FIRM fields of 30 and 10 characters respectively, a single scan with a hand held light pen or wand inputs both NAME and NAME.sub.-- FIRM data into their related fields simultaneously from a single Code 39 bar code.

The NAME and NAME.sub.-- FIRM multiple field authority list preferably includes a person's last name, first initial, and the company with which the individual is associated. For example, if Albert Einstein worked for XYZ Associates his entry would be "EINSTEIN A-XYZ ASSOC". This particular multiple data field format for NAME and NAME.sub.-- FIRM permits unique identification of an individual for selective name or company searching.

The multiple field authority list can be used for inputting several fields of any type and is not restricted to the NAME and NAME.sub.-- FIRM fields which are associated with the People database shown in Table 2. Moreover, more than two fields can be inputted in a single scan of a bar code. Multiple field entry can be designed by field length selection as described above. Alternatively, a return character for the data input can be embedded in the bar code. For example, dBase III Plus.TM. responds to a semicolon character as a return. Thus, embedding a semicolon between fields will cause data entry to occur in the appropriate fields.

The resulting authority lists usually are printed out on paper or other substrate means to be used for scanning by a light pen or light wand. When a light pen is used a clear plastic sheet is placed on top of the paper or other substrate means to prevent the repeated use of the light pen from wearing away the authority list's bar codes.

In the preferred embodiment, once the bar coding and authority lists have been created, sub-system input "coding" stations are established to simplify the coding of mass volumes of documents. Preferably, these input stations are designed to maximize the flow rate of document coding. Although document coding can be performed at one station, it is more efficient, and therefore preferred, to use several sub-system input stations, each designed to input a particular group of fields. FIG. 4 shows a schematic diagram of the preferred embodiment of four sub-system input stations and their associated tasks.

The computer systems 59 used for the sub-system input stations do not have to be of the same class as that used to store and operate an entire litigation support system. Since the four input stations only perform the task of recording a small amount of bibliographic information per document for small groups of documents, such input stations can operate on lower cost 8-bit microprocessor computer systems. An example of such an input station computer system might be an IBM PC XT or compatible. Additionally, each input station is configured with a optical scanning means interfaced with a keyboard as discussed above and shown in FIG. 1. Using low cost computer systems for input stations significantly reduces the cost associated with setting up numerous input stations to code mass volumes of documents.

Referring to FIG. 4, Station 61 is used first to code document production numbers. The system operator at Station 61 scans the bar code number on a document with a light pen or wand, the signal generated being automatically converted and entered into the BAR.sub.-- CODE field. Next, if the document's bar code is not the same as the document's beginning production number, the document's beginning production number and ending production number are manually entered through a keyboard. The system operator then determines the source of the document and whether it was designated confidential or non-confidential. The operator then scans the appropriate source from the bar code SOURCE AUTHORITY LIST for entry into the SOURCE field while the appropriate confidentiality status for the CONFID field is entered manually or scanned.

In certain situations the coding of record input fields can be more effectively handled automatically by computer generation. For example, if an entire set of documents are from a single source, or if an entire set of documents are confidential, the coding of the SOURCE or CONFID fields at Station 61 can be automated by modifying the station's program. Generally, the program would be modified to automatically enter into the SOURCE or CONFID fields the appropriate response, e.g. "Y" for the CONFID field. Automating field entries in the appropriate circumstances eliminates manual steps and reduces the overall time and costs associated with coding documents.

The document coded at Station 61 is then passed to the system operator at the second Station 62 who codes information relating to the people identified with relation to the document. First, the bar code is scanned. Next, the name of the author, addressee or copy recipient and his associated company is determined and scanned from the bar code NAME, NAME.sub.-- FIRM authority list, see FIG. 3B. Then the Action of the person respective to the document, i.e., whether the person named is an author, addressee or copy recipient, is determined and scanned from the bar code ACTION authority list. The process is repeated for each person identified on the document. Thus, using this method a user can generate more than one record from a single document in the People database all linked by the document's bar code number.

The document coded at Station 62 is then passed to the third Station 63 where document-type information is recorded. First, the bar code is scanned into the system. Then a determination is made whether the document has been masked and whether any writing in the margin has occurred. The operator then scans the appropriate response from the bar code MASKED and IN.sub.-- MARGIN authority lists. Then the document's type, e.g., Affidavit, Article, Handwritten Note, Memo or Minutes, is scanned from the bar code DOCUMENT.sub.-- TYPE authority list, see FIG. 3A. Finally, the date of the document is manually entered via a keyboard.

The document is then passed to the fourth Station 64 where, after the bar code is scanned, the document's rating and associated attorney comments are entered. Here, the document is rated on a scale of 0 to 3, 0 being of least importance and 3 being of highest importance. Any additional comments are manually entered or scanned for future review and use.

For convenience of data manipulation and customization, temporary databases are created for each sub-system input station having only the required fields. These temporary databases may be created with commercially available database software, such as dBase III Plus.TM. or dBase IV.TM. by Ashton-Tate, Inc. of Torrance, Calif., which have data file structures compatible with Clipper.TM. compiled programs. Upon completion of document coding, these four sub-databases are then merged and updated into the Document database 21, the People database 23, and the Comment database 25, as shown in FIG. 4. Specifically, all the fields of the temporary databases of Stations 61 and 63 as well as the RATING field from Station 64 update the Document database 21. The BAR.sub.-- CODE and COMMENT fields from Station 64 update the Comment database 25 while all of the fields of Station 62 update the People database 23. Updates can be performed using the Update commands of dBase III Plus.TM. or dBase IV.TM. with linking based on the BAR.sub.-- CODE field.

The use of separate coding stations and temporary databases allows for more efficient and rapid coding of mass volumes of documents. While the above description indicates that documents with affixed bar codes flow sequentially through Stations 61 to 64, it will be appreciated that the station order is arbitrary. Thus, the order may be sequential, 61 to 64, reversed, 64 to 61, or random. It will also be appreciated that the number of computer systems used at each station may vary. For example, Stations 61, 62 and 64 may only require a single operator per station using a single computer system per station whereas Station 63 may comprise multiple operators using a like number of computer systems coding different document types.

Once the separate coding stations update the relational databases, a system operator can view, edit and append records to the database through a record display screen as shown in FIG. 5. The record display screen is divided into three general areas. The first area 71 displays the contents of each field in the Document database 21. Area 73 displays the contents of each field in the Deposition Exhibit database 27 as well as the contents of each field of the Deposition Witness database 29. Finally, the third area 75 displays the contents of each field in the Trial database 31. Above area 71, the system displays the present record number as well as the current date. Below areas 73 and 75 the system displays a command line for editing and selecting records.

Once document coding has been completed and all of the line bibliographic document information has been entered into the system's relational databases, deposition exhibits and witnesses can now be entered as they arise during the course of litigation. Here, a system operator only needs to code the deposition exhibit number, witness name and action to complete each entry.

To code a deposition exhibit, the system operator first proceeds to determine if the exhibit is coded in the document database by performing a FIND using the BAR.sub.-- CODE index. The operator scans the bar code on the exhibit and the program finds the document. If no document is found, the document information would be coded into the Document datebase 21. If the document is found, the user proceeds to enter the Deposition Exhibit information. The operators selects from a main system screen the Deposition Exhibit database 29. The system operator then selects the Append mode of the litigation support system to add an exhibit to the Deposition Exhibit database 29. The litigation support system then displays a screen similar to that shown in FIG. 5. While in the Deposition Exhibit database, the user is directed to enter information in area 73 and is "locked out" of the areas 71 and 75. The system operator then scans the bar code from the deposition exhibit into the BAR.sub.-- CODE field and then manually enters the Deposition Exhibit number in to the DEPO.sub.-- EXH field.

After adding the exhibit to the Deposition Exhibit database 27, the system operator then selects the Deposition Witness database 29 and the Append mode to add the witness information. The system operator is again prompted with a record display screen similar to that shown in FIG. 5. Here, the operator scans the bar code, the witness name and the action, i.e., whether the exhibit was marked, asked or authenticated, into their related fields. Once the system operator enters this information to the Deposition Witness database coding of the deposition exhibit is completed. The litigation support system then automatically links the deposition exhibit information to the other databases through the bar code 19 as shown in FIG. 2.

Additionally, trial exhibits can be entered in the same manner. The trial exhibit number, objection if any, proposed witness to be used, and information regarding whether the exhibit has been offered or admitted is coded for each trial exhibit in area 75 in a manner similar to the coding of deposition exhibits. Trial exhibit list information is used during discovery, pretrial, and trial phases to build the proposed trial exhibits, prepare trial exhibit lists, to generate witness exhibits and track the status of exhibits at trial and to prepare the final trial exhibit list record.

FIG. 5 shows a record display screen for a document which has been coded, used as a deposition exhibit, and used as a trial exhibit. A review of area 71 informs the operator that the specific document was a memorandum from R. Frost to L. Hand concerning lab results, was produced from ABC Company to XYZ Associates and had C. DeMile as a copy recipient. The document rating is a 3, indicating that the document is highly important, and the COMMENT field indicates that the document concerns bioassay results. Additionally, a review of area 73 indicates the document was marked as Deposition Exhibit No. 32 during Mr. DeMile's deposition. A review of area 75 indicates the document was again used as Trial Exhibit 101 during Mr. DeMile's testimony, an objection was made stating that the document was illegible and hearsay under Federal Rules of Evidence 802, and the document was offered and received into evidence on Jan. 3.

A completed database will allow a user to do numerous types of informative searches for valuable information and generate related reports. For example, in preparing for Mr. DeMile's deposition, a system operator can identify every document considered highly important, i.e. where the rating equals 3, that Mr. DeMile authored, received or was a copy recipient. The resulting search would then be generated as a report for the deposing attorney to review in preparation for Mr. DeMile's deposition. Similarly, if an attorney has a particularly valuable document that he is prepared to use at trial, he can interrogate the system to find out what witnesses have given deposition testimony concerning that very document. As can be seen, numerous types of informative searches can be structured to suit a particular inquiry of the system yielding valuable and accurate document information.

Reports may be generated using commercially available report writer programs to extract the data. Suitable programs include the report writers available in dBase III Plus.TM. or dBase IV and R&R Relational Report Writer.TM. available from Concentric Data Systems, Inc. of Westboro, Mass. Similarly, labels may be produced from the database using label generators provided in dBase III Plus.TM. or dBbase IV.TM..

As is readily apparent to those skilled in the art, the improved litigation support system can be used by anyone involved in a law suit. Specifically, courts can adopt the system for recording information filed in pending litigations. By requiring by local rule or other means that all court papers filed include a bar code or other indicia means, the court clerk can optically scan each filing for automatic updating of litigation dockets. Additionally, exhibits introduced at trial, trial transcripts, and affidavits filed can be recorded and used to maintain a trial record.

It will thus be seen that the objects set forth above, among those made apparent from the preceding description, are effectively obtained. Since certain changes may be made above system and method without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompany drawing shall be interpretive as illustrative and not limiting. It is also understood that the following claims are intended to cover all of the generic and specific features of the invention described herein, and all statements of the scope of the invention which, as a matter of a language might be said to fall between. ##SPC1##