When It Really Matters770-777-2090



To learn more about electronic discovery or
discuss a specific matter






Form of Production Still Tricky in Document Requests

Gregory L Fordham
March 2008

One would have thought that after the recent changes to the FRCP, substantive in 2006 and minor in 2007, that the form of production for Electronically Stored Information (ESI) would be well settled.  Not so.

Rule 34 FRCP governs the production of  ESI.  In particular Rule 34(b)(2)(E)(ii) says that if a form is not specified that the producing party must produce ESI in a form or forms in which it is ordinarily maintained or in a reasonably usable form.

Since its very name, ESI, indicates electronically stored information, one would expect “ordinarily maintained” to mean native format with at least embedded and substantive metadata.  Furthermore, one would expect the term “reasonably usable” would mean any other form having the same features and benefits of native format.

The recent decision in D’Onofrio v SFX Sports Group, Inc., 247 F.R.D. 43 (D.D.C. Jan 2008), however, illustrates that there is still plenty about which to argue as well as carefully articulate when requesting ESI.

In D’Onofrio the Plaintiff wanted the Defendant’s business plan in native format with accompanying metadata.  However, the Defendant supplied the business plan in image format.  Unsatisfied, the Plaintiff filed a motion to compel making two arguments.

First, the Plaintiff argued that translation of ESI into some other format was permitted only when necessary.  Second, the Plaintiff argued that it had requested the document in its native format with metadata.

In examining the first argument, the Court concluded that Rule 34(a), in general, is permissive in that it allows one party to request the other’s documents and ESI.  Thus, that particular provision does not prescribe the procedures for production.

Furthermore, the “if necessary” provision of Rule 34(a)(1)(A) allows the requesting party to have the data translated into a more usable form if data is not directly obtainable.

Although D’Onofrio does not explain when such situations might occur, they likely would involve data on proprietary systems or, at least, less generally available systems such as in In re Air Crash Disaster At Detroit Metropolitan Airport On August 16, 1987, 130 F.R.D. 634, (E.D.Mich 1989) and National Union Electric Corporation v. Matsushita Electric Industrial Co., Ltd. et al., 494 F.Supp. 1257, (E.D. Pa. 1980).

With respect to Plaintiff’s second argument, the Court examined the actual wording and was not convinced.  In fact, Plaintiff’s wording seemed more appropriate to paper based documents and the filing systems in which they were stored than ESI and the manner in which it is stored.

As a result, the Court concluded that, “A motion to compel is  appropriate only  where an  appropriate  request  has  been made. . .”

Interestingly, there was no discussion in the decision of Rule 34(b)(2)(E)(ii) that says when a form is not specified it should be produced in the form it is ordinarily maintained or in a reasonably usable form.

Unlike Plaintiff’s “if necessary” argument in Rule 34(a), this part of Rule 34 describes the production procedures.  Furthermore, unless the Defendant’s business plan was no longer stored in electronic form, conformance with this part of the rule would have produced the Plaintiff’s desired format and metadata content.

Also, there was no discussion about whether the Defendant’s image format satisfied the “reasonably usable form” requirement of Rule 34.  Generally, this requirement has been interpreted to mean a searchable format but even a searchable format may not be comparable to native format with related metadata.

So, if there is a lesson for litigators wanting native format documents with related metadata, it likely is that they should be explicit.  In other words, they need to ask specifically for native format files with their related metadata.

Of course, there are several different kinds of metadata.  There is metadata internal to the files themselves, commonly called embedded and substantive metadata. 

Embedded metadata are attributes such as author, organization, etc.  Substantive metadata is limited to content changes.

In addition, there is system metadata that can include file system date stamps, pointer files, registry keys, log files, etc.

Thus, when requesting native format files and related metadata, the litigator will need to expressly identify the particular metadata of interest—embedded, substantive and/or system.

In the event that a request is determined inadequate, as in D’Onofrio, the litigator may want to backstop his arguments with the requirements of Rule 34(b)(2)(E).  In addition, he may want to identify why the form produced was not reasonably usable.  For example, was it searchable?  Did it include relevant metadata?