ESI: Form or Forms of Production

Form or Forms of PRODUCTION: Native file, Metadata, Agreed Upon File Format

The definition of ESI in the Request for Production of Documents discussed above strategically designates native file production. Native file is the file format in which the ESI reside on the media from which it is to be produced.  For example, if a letter to a key player resides on a comuter as a Microsoft Word document, the letter exists isn a “.doc” file format. This file format includes the file name, content and related metadata. Learn more about ESI production of native files below.

Requesting Metadata and File Formats for ESI production.

Ohio Rules of Civil Procedure, Rule 34 permit the requesting party to designate the form or forms in which ESI is to be produced, but may not require the production of the same information in more than one form.i Staff notes to the Rule make it clear that the requesting party can request native file format for each of the file types of relevant ESI:

• Amendments to the first paragraph of Civ. R. 34(B) allow the requesting party to specify the form or forms in which electronically stored information should be produced. For example, the party propounding discovery seeking electronically stored information could request that a party’s internal        memorandums on a particular subject be produced in Word™ format, while financial records be provided in an Excel™ spreadsheet format or other commonly used format for financial information. This provision also specifies that the requesting party cannot demand that the respondent provide the same information in more than one electronic format. If a party believes that the form or forms specified by an opponent is unduly burdensome or expensive, the party can object to the discovery under Rule 34(B)(1) and then negotiate a different, mutually acceptable form with the opponent or seek relief from the court under Rule 26(B)(4).

Rule 34, Ohio Rules of Civil Procedure
Strategically, there are two reasons for requesting ESI in native file format:

(1) to test the knowledge base of your party opponent regarding metadata and force discussions regarding metadata fields that are relevant and discoverable; and
(2) to control costs by obtaining the metadata fields necessary to electronically organize relevant ESI.

Understanding Metadata Fields.

In order for counsel to effectively use Rule 34 to designate the file formats (including metadata fields) in which to request relevant ESI, he must not only understand the content of the file, but also understand the metadata associated with the ESI to be produced. Metadata is merely information created by the operating system, file system, or application software that relates to, and in many cases is part of, the content of relevant ESI files. Although the metadata is related and part of the ESI data, counsel ought to anticipate that metadata information will be analyzed independently from the contents of ESI. This is evidenced by the several federal courts, including the Northern District Court of Ohio, that have adopted local discovery rules that treat metadata separately from content.ii Thus, counsel ought to be familiar with the metadata fields associated with the relevant ESI file types and ought to construct rational arguments supporting or opposing the argument that specific metadata fields ought to be included in a response to a request for production.
For example, this book was created as a Microsoft word document and saved as a “Book Draft.doc” file.

The content data of the “Book Draft.doc” file is the text of the book. Metadata about the Book Draft.doc file can be viewed as “properties” in the “file” menu available when the document is opened in Word. There are several metadata fields identified in the properties folder and organized under tabs labeled: “General”, “Summary”, “Statistics”, “Contents”, and “Custom”. Some of the data in these metadata fields is used by a computer to organize the file. For example, the “Creation” date can be used to chronologically arrange thousands of Word files with a mere click of a mouse. If the Creation date metadata field is not included in the production of ESI, however, Counsel may be faced with significant cost incurred in simply arranging documents in chronological order. It would seem, therefore, that the proper “creation date” metadata field associated with the production of word files ought to be included so that the Requesting Party can organize the files using a computer in the same manner as the Producing Party.
In order to effectively construct discovery strategies to include the proper metadata fields and the proper file formats, counsel ought to identify and understand the characteristics and use of each of the metadata fields included in each native file type of ESI. Counsel can then explain the relevance of each metadata field to the matter, or the manner in which the metadata field is necessary to make the data “reasonably useful”. Based on this understanding, counsel can either competently negotiate for the production of these fields or defend a motion to compel.

An Example of Metadata Fields Associated with Word File.

To better understand the scope of metadata that counsel ought to request in a production of documents, consider the Microsoft Word document file that comprises this book. This document file includes the following information organized under the “General” metadata tab of the “Properties” folder:
a. File Type: Microsoft Word 97-2003 Document. This metadata field identifies the software application used to create the document. It is not privileged because it is generated by the application rather than by any key player.

b. Location: C\Documents and Settings\Dwochna\My Documents\Book Draft.doc. This metadata field identifies the exact location or path at which the “Book Draft” resides. This information can be very helpful to quickly estimate the device on which the “Book Draft” was created.

c. Size: 721KB (738,304 bytes). This metadata field identifies the size of the “Book Draft” electronic file. This information is invaluable to assist Counsel to estimate the time needed to process the file, including searching, copying, and transmitting the file over the internet or as an attachment to email. Many of the frustrations of electronic discovery involve the use of electronic tools with little or no regard to the aggregate size of data being processed. Armed with an accurate calculation of the total amount of data that will need to be processed in response to a discovery request, Counsel can effectively negotiate or move the Court for schedules that accurately reflect the time needed to accomplish discovery functions.

d. Created: March 20, 2008 4:43:50 p.m. This is the time stamp that is given to the document when the document is saved for the first time to the Location identified in the Location metadata. The time stamp is retrieved from the operating system’s clock. The time stamp changes when a document is copied and then moved to a new location.

e. Special considerations of Dates and Times: In the example of the Book Draft file, this metadata field identifies the date and time on which the “Book Draft” file was written onto the “C” drive in the Location identified in the Location metadata field. This field does not identify the manner in which the “Book Draft” file was written onto the “C” drive. The file could have been originally created on the computer or it could have been created on another computer and copied to the computer which displays this metadata.
Whenever a file is copied onto new hard drive or onto a new section of a hard drive (e.g. saving a file originally stored on the “C” drive to the “G” drive of the same computer), the operating system records the date and time on which the file was created on that hard drive section (termed a “volume”). It is absolutely essential that counsel understand this metadata field may or may not be the date on which the Book Daft file was originally created. Failure to appreciate this metadata field may easily cause counsel to erroneously represent the dates when files were originally created, or inaccurately produce documents created within an agreed-upon date range.

f. Modified: November 30, 2008 1:56:15 a.m. This is the date and time when the document was last opened and then saved.

g. Accessed: December 2, 2008 2:04:45 p.m. This is the date and time when the document was last opened.

Additional Metadata Fields in the Statistics Tab and Unique Issues.

In addition to the metadata fields identified under the “General” tab, there are identically named metadata fields organized under the “Statistics” tab. These fields include:
a. Created: This is the universal date and time when the document was first created. The “first creation” starts at the moment that a document is opened. This information is actually embedded as a permanent part of the document.

b. Modified: This is the date and time when the document was last opened and then saved.

c. Accessed: This is the date and time when the document was last opened.

d. Printed: This is the date and time when the document was last printed.
These similar metadata fields can easily confuse counsel and result in the inaccurate or improper production of documents. Some common issues related to these metadata fields include:

e. The print date precedes the Create date in the Statistics Tab. A document that was printed may be copied or re-saved to another location. Additionally, a document that was printed may be overwritten in the same location as the parent (original) document. In these cases, the newly copied or overwritten document has a more current “Created” date than the “Printed” date. The original “Printed” date carries over to the newly copied or overwritten document.

f. The Create date in Statistic tab precedes the Create date in the General tab. The “Created” date and time in the Statistics tab does not change unless the document is copied or unless someone performs a “Save As” operation on the File menu.

Additional Metadata Fields.

Other metadata fields in a Microsoft word file include revision number, editing time, total number of pages, paragraphs, lines, characters and characters with spaces. The revision number field may be useful in determining whether counsel has located and/or received copies of drafts of documents.

Metadata Fields and Privilege.

It is significant to note that most metadata fields are computer generated and cannot be privileged because they contain no information from a human being. Other fields, however, invite users to add or create data. These metadata fields may require review by counsel to insure that they do not contain privileged material. The “Summary” and “Contents” tab contain metadata fields in which key players can store comments and descriptions that may need to be withheld from production.

Different Devices—Different Metadata.

Different file types and different devices (such as digital cameras) will have different metadata fields. For example, a typical picture file in the jpeg file contains the following metadata fields created by the device that took the picture:

• Width and height of the image measured in pixels
• Horizontal and Vertical resolution
• Bit Depth
• Frame Count
• Equipment Make and Model of the camera that took the picture
• Creation Software
• Color representation
• Flash mode
• Focal length
• F-number
• Focal length
• Exposure time
• ISO speed
• Metering mode
• Light Source
• Exposure Program
• Exposure Compensation
• Date Picture Taken

Depending on the issues involved in a matter, counsel may find these metadata fields useful. Counsel ought to be aware, however, that some metadata fields may present additional challenges to authentication because key players and others can use specialized software to manipulate these metadata fields.iii Nevertheless, counsel must identify the devices used by key players that may contain relevant ESI (and therefore be considered “witnesses”) and she must learn the types of metadata and content available on those devices, and be prepared to explain the manner in which specific types of data and metadata are related to the subject matter of a case.
By understanding the metadata fields associated with the file types and devices related to a matter, counsel ought to be in a position early in a case to request content and metadata along with artifacts. Early request for metadata might be necessary, as developing case law suggests ordinarily, courts will not compel the production of metadata when a party did not make that part of its request.iv Counsel should request metadata early in the case and be prepared to explain the manner in which requested metadata fields relate to claims/defenses and/or enable counsel to search and sort electronic evidence more efficiently. Waiting until document collection efforts by a party opponent are almost complete to request such metadata may cause such a request to be denied on the ground of burden and expense.v Finally, failing to request necessary metadata could easily cause counsel to be unable to electronically search and sort evidence, increasing the cost of litigation, and potentially placing counsel’s competence in question. ◊

REFERENCES
i Rule 34, Ohio rules of Civil Procedure
ii See Appendix K, Local Rules, Northern District of Ohio
iii See Jpeg Header Manipulation Tool at http://www.sentex.net/~mwandel/jhead/
iv Autotech Techs. Ltd. P’ship v. AutomationDirect.com, Inc., 248 F.R.D. 556 (N.D. Ill, 2008)
v See Auguilar v. Immigration & Customs Enforcement Div., 2008 U.S. Dist. LEXIS 97018 (S.D.N.Y. Nov 20, 2008)