When working on computer forensics or e-Discovery projects, especially the ones that involve electronically stored information (ESI) productions based on pick lists, we frequently encounter pick lists which consist of Bates ranges. Bates ranges may comprise document-level control numbers—as seen in native or near-native document productions, or page-level Bates numbers. We conceived Range Converter—a free Bates range to list converter—with the hope that it will make it easier for legal professionals to work with Bates ranges.
Microsoft Office documents typically contain a great amount of metadata, some of which can be instrumental in computer forensics. While e-Discovery and computer forensics software can handle extracting and displaying most of the metadata, I found that a crucial piece of information is usually not extracted: Microsoft Word last 10 authors — also known as Word save history.
Certain versions of Microsoft Word such as Word 8.0 (Word 97) through Word 10.0 (Word 2002) store the names of the last 10 people who edited the document as well as the file locations. This information is not displayed to the end user through the Microsoft Word user interface, and according to the Microsoft Support website, this is an automatic feature that cannot be disabled.
Have you ever had to calculate production attachment ranges (e.g. PRODBEGATT and PRODENDATT fields) manually? Perhaps the production software you used did not calculate these fields for you, or the production specifications changed and you had to add these fields after the fact. While the calculation is usually straightforward, things can get a bit more tricky if some of the attachment families were not produced entirely (i.e. you need to shrink the review attachment ranges to account for the documents that were not produced).
We have created a Concordance CPL called “Populate_Prod_Att” to help make things a bit easier. The CPL reads the existing review attachment ranges and production Bates numbers in your Concordance database, and calculates the production attachment ranges for you.
E-mail messages contain numerous metadata fields that are utilized by computer forensic examiners as well as legal teams. One key MAPI property that is frequently extracted by computer forensics and e-Discovery software, but yet usually overlooked or underutilized, is PR_CONVERSATION_INDEX. This property indicates the relative position of a message within a conversation thread and is typically populated by the e-mail client for each outgoing message.
Modern e-Discovery software can extract hundreds of metadata fields from documents. Extracted metadata is typically stored in a back-end database and a subset of it is exported and included in the e-Discovery production or review database. We often receive questions regarding which metadata fields should be included in an e-Discovery review database or which metadata fields should be requested during an electronic document production.
The answers to these questions depend on the requirements of each case and should ultimately be determined by the legal team. That said, we have prepared the following field list as an example, with the hope that it will serve as a good starting point.
LexisNexis Concordance® is currently one of the most popular discovery management software and many service providers and legal departments deal with Concordance Load Files on a regular basis. In some cases, the Concordance load file is received without an accompanying database structure. Unless there is an existing database that the load file will be imported into, the person performing the import has to create a Concordance Database (DCB).
The above scenario is usually not an issue as long as the load file contains only a few fields. However, manually creating an e-Discovery database to accommodate a 100+ field Concordance Load File can be a tedious task. To make things a bit easier, we have created a Concordance program called “Create Database CPL” using the Concordance Programming Language (CPL). The CPL reads the header row of a Concordance load file (DAT), extracts the field names and creates a Concordance Database (DCB) with matching fields. It requires that your load file starts with a header row which contains the field names.