[PROPOSED] STIPULATED ORDER RE: DISCOVERY OF ELECTRONICALLY STORED INFORMATION FOR STANDARD LITIGATION
EDWARD M. CHEN, District Judge.
1. PURPOSE
This Order will govern discovery of electronically stored information ("ESI") in this case as a supplement to the Federal Rules of Civil Procedure, this Court's Guidelines for the Discovery of Electronically Stored Information, and any other applicable orders and rules.
2. COOPERATION
The parties are aware of the importance the Court places on cooperation and commit to cooperate in good faith throughout the matter consistent with this Court's Guidelines for the Discovery of ESI.
3. LIAISON
Plaintiffs' and Defendants' e-discovery liaisons, Paolo C. Meireles of Shavitz Law Group, P.A. and Roberta Vespremi of Morgan Lewis, are and will be knowledgeable about and responsible for discussing their respective ESI. Each e-discovery liaison will be, or have access to those who are, knowledgeable about the technical aspects of e-discovery, including the location, nature, accessibility, format, collection, search methodologies, and production of ESI in this matter. The parties will rely on the liaisons, as needed, to confer about ESI and to help resolve disputes without court intervention.
4. PRESERVATION
The parties have discussed their preservation obligations and needs and agree that preservation of potentially relevant ESI will be reasonable and proportionate. To reduce the costs and burdens of preservation and to ensure proper ESI is preserved, the parties agree that:
a) Only ESI created or received between December 1, 2010 and the present will be preserved;
b) The parties have exchanged a list of the types of ESI they believe should be preserved and discussed, in general, and the descriptions of custodians, for whom they believe ESI should be preserved.
c) The parties will agree on the number of custodians per party for whom ESI will be preserved.
d) Defendants are in the process of assessing the accessibility of certain types of data. Defendants reserve their right to later designate certain types and/or sources of data as not reasonably accessible because of undue burden or cost pursuant to Fed. R. Civ. P. 26(b)(2)(B), or to assert any other objections to production they deem fit pursuant to the Fed. R. Civ. P.
e) In addition to the agreements above, the parties agree that data from video surveillance tapes (to the extent any exist) could contain relevant information, but under the proportionality factors need not be preserved, searched, reviewed, or produced.
5. PRIVILEGE LOG AND REDACTION
a) The Parties agree that they need not initially exchange the text of litigation hold/retention instructions issued in this litigation. The Parties reserve the right to request such information as allowed by law.
b) In an effort to avoid unnecessary expense and burden, the Parties agree that, for documents redacted or withheld from production on the basis of attorney-client privilege, work product doctrine and/or any other applicable privilege, the Producing Party will prepare a summary log containing, for each document claimed as privileged, an export of all or a subset of the metadata fields listed in Table 1 (as agreed upon by the Parties) to the extent such information exists and has not been redacted for privilege. The export should include the following information:
• BEGNO
• ENDNO
• BEGATTACH
• ENDATTACH
• CUSTODIAN
• FROM
• TO
• CC
• BCC
• SUBJECT
• SENTDATE
• RECEIVEDDATE
• FILENAME
• AUTHOR
• CREATEDDATE
• FILEPATH — ALL
• PRIV_CLAIM
If the requesting party requires further information, it shall explain in writing the need for such information and identify, by Bates number or other unique identifier, each document for which it seeks this information. Within fifteen (15) days of such a request, the Producing Party must either (i) provide the requested information or (ii) challenge the request. If a Party challenges a request for further information, the Parties shall meet and confer to try to reach a mutually agreeable solution. If they cannot agree, the Parties must request a conference with the Court before any motions may be filed.
6. SEARCH, IDENTIFICATION AND COLLECTION OF DOCUMENTS
a) Except as otherwise agreed upon in this Stipulation, the Parties will continue to meet and confer in an effort to agree upon the following:
1. List of custodians;
2. Search methodology to be applied, including, but not limited to, search terms and date restrictions; and
3. Location of relevant data sources including custodial, non-custodial and third-Party.
7. PRODUCTION FORMATS
a) General Provisions.
The parties agree to produce documents in TIFF format, with metadata and extracted text/OCR, and Concordance-formatted load files, Excel-manipulable where appropriate. Each *.tiff file should be assigned a unique name matching the Bates number of the corresponding image. The Bates number should be consistent across the production, contain no special characters, and be numerically sequential within a given document.
Responsive attachments to documents should, when possible and when applicable, be assigned Bates numbers that directly follow in sequential order the Bates numbers on the documents to which they were attached. If a Bates number or set of Bates numbers is skipped, the skipped number or set of numbers should be noted, for example with a placeholder.
All images should be provided in single-page, Group IV TIFF with a resolution of 300 DPI. Bates numbers and confidentiality designations should be electronically branded on each produced *.tiff image. These .TIFF images should be provided in a separate folder and the number of TIFF files per folder should be limited to 1,000 files.
If particular documents warrant a different format, the parties will cooperate to arrange for the mutually acceptable production of such documents.
b) Deduplication.
The Parties shall make reasonable efforts to deduplicate ESI. ESI will be deduplicated vertically within each custodian and horizontally across custodians ("Global Deduplication"). ESI will be considered duplicative if it has the same content including metadata. For example, duplicates would include copies of the same electronic file saved on the local hard drives and/or network shared drives of multiple custodians, even if different instances of the file reflect different dates created. Electronic files will be identified by Plaintiffs based upon calculated MD5 Hash values and by Defendants based upon SHA-1 values for binary file content. Duplicate email files will be identified by Plaintiffs based upon MD5 Hash values and by Defendants based upon SHA-1 values for the message family, including parent object attachments. Duplicate emails will be identified at a family level, including message and attachment(s).
c) Email Thread Suppression.
Each Party also may deduplicate emails in such a way as to eliminate earlier or incomplete chains of emails, and produce only the most complete iteration of an email chain. Any deduplication tool used by a Party must ensure that an email will be suppressed only if its recipients (including cc and bcc recipients), subject, body text (excluding specified automatic footers, and normalized to consolidate white space), and attachments are wholly included in another more complete email.
d) Searchable Format.
Unless otherwise agreed by the Parties, all documents shall be produced in an electronically searchable format. The parties agree not to degrade the searchability of documents as part of the document production process. Searchable text of the entire document should be produced for every record, at the document level, except in the case of documents produced in redacted form. OCR text must be provided for all documents that originated in hard copy format to the extent feasible.
e) Document Text.
All unredacted documents should be provided with complete document-level extracted text files. In the event a document contains text which is to be redacted, OCR text files should be provided for any un-redacted portions of the documents. Document-level OCR text files should be provided for any unredacted portions of redacted documents and for all hard copy scanned documents. The extracted full text and/or OCR text for all deliverables should be in separate document-level TXT files. These TXT files may either be provided in a separate folder or included in the same folder as their corresponding images. The number of TXT files per folder should be limited to 1,000 files.
f) Parent-Child Relationships.
For email collections, the parent-child relationships (the association between emails and attachments) should be preserved. Email attachments should be consecutively produced with the parent email record to the extent the attachment is non-privileged and responsive to a request for production.
g) Dynamic Fields.
Documents with dynamic fields for file names, dates, and times will be processed to show the field code (e.g., "[FILENAME]" or "[AUTODATE]"), rather than the values for such fields existing at the time the file is processed.
h) Word Processing Files.
All word processing files, including without limitation Microsoft Word files, will be produced as *.tiff images. Word Processing files saved in Microsoft Office (and other similar documents created in programs for which there is an option to show tracked changes and/or comments as last saved by the custodian) will be processed to *.tiff format showing tracked changes or comments.
i) Non-redacted Spreadsheet Files.
Spreadsheet files, including without limitation Microsoft Excel files, that do not require redactions will be produced as native files showing comments and similar data. A UNC file path must be included in the ESI load file. Additionally a bates-stamped *.tiff placeholder matching the bates number of the native file, must be included in the production and reflected in the image load file. To the extent Parties prefer native file redaction of Spreadsheet Files, the Parties will meet and confer to discuss the form of production.
j) Presentation Files.
Presentation files, including without limitation Microsoft PowerPoint files, will be processed to *.tiff format images showing comments, hidden slides, speakers' notes, and similar data. The Parties will meet and confer regarding production of presentation files with alternate default settings.
k) Database Records.
To the extent that any Party requests information that is stored in a database or database management system, including but not limited to records of Plaintiffs' and Class Members' contact information, work telephone records, and/or log-in/log-out records, such information will be produced by querying the database for discoverable information and generating a database export, including record histories, in a reasonably usable and exportable electronic file (for example, *.mdb format) for review by the requesting Party to the extent possible, and when applicable and sufficient. To the extent this production format is not feasible, applicable, or sufficient, or causes the producing Party undue burden, the Parties agree to meet and confer to discuss the different form of production.
l) Embedded Files.
Embedded files are produced as independent document records. Embedded files should be assigned Bates numbers that directly follow the Bates numbers on the documents within which they are embedded.
m) Time Zone.
Unless otherwise agreed, all dynamic date and time fields, where such fields are processed to contain a value, and all metadata pertaining to dates and times will be standardized to one time zone. To the extent that is not possible, such as in the case of phone logs, the producing party will provide further information to the requesting party, such as routing location for phone calls. The Parties understand and acknowledge that such standardization affects only dynamic fields and metadata values and does not affect, among other things, dates and times that are hardcoded text within a file. Dates and times that are hard-coded text within a file (for example, in an email thread, dates and times of earlier messages that were converted to body text when subsequently replied to or forwarded; and in any file type, dates and times that are typed as such by users) will be produced as part of the document text in accordance with Concordance format.
n) Bates Numbering.
Files will be named according to the Bates number of the corresponding *.tiff image. The Bates number will:
i. be consistent across the production;
ii. contain no special characters; and
iii. be numerically sequential within a given document.
Attachments to documents will be assigned, whenever possible, Bates numbers that directly follow the Bates numbers on the documents to which they were attached. If a Bates number or set of Bates numbers is skipped, the skipped number or set of numbers will be noted. In addition, wherever possible, each *.tiff image will have its assigned Bates number electronically "burned" onto the image.
o) Load File Format.
ESI will be produced in standard Concordance load file format with an image file that is in .OPT format.
p) Media.
The producing Party shall produce documents on readily accessible, computer or electronic media as the Parties may hereafter agree upon, including CD-ROM, DVD, external hard drive (with standard PC compatible interface or access to a secure On-Line Repository agreed upon by the Parties), or via secure FTP site. Each piece of production media shall be assigned a production number or other unique identifying label corresponding to the date of the production of documents on the production media as well as the sequence of the material in that production. The producing Party shall accompany all document productions with a transmittal cover letter identifying by Bates number the documents produced.
q) Encryption.
To maximize the security of information in transit, any media on which documents are produced may be encrypted by the Producing Party using mutually agreeable encryption software. In such cases, the Producing Party shall transmit the encryption key or password to the Requesting Party, under separate cover, contemporaneously with sending the encrypted media.
r) Metadata to be Produced.
Metadata to be produced: The following metadata fields should be produced for each document to the extent that such information is available at the time of collection and processing, except that if a field contains privileged information, that privileged information may be redacted and noted in a corresponding privilege log. All requests should be read to include a request for all metadata associated with all documents responsive to the request. The text and metadata of emails, attachments, and native file document collections should be extracted and provided in a .DAT file using the field definition and formatting described below.
FIELD NAME SAMPLE DATA DESCRIPTION
FIRSTBATES EDC0000001 First Bates number of native
file document/email
LASTBATES EDC0000001 Last Bates number of native
file document/email
**The LASTBATES field
should be populated for single
page documents/emails.
BEGATTACH EDC0000001 First Bates number of
ENDATTACH EDC0000015 Last Bates number of
PARENT_BATES EDC0000001 First Bates number of parent
document/Email
**This PARENT_BATES
field should be populated in
each record representing an
attachment "child" document
CHILD_BATES EDC0000002; EDC00000014 First Bates number of "child"
attachment(s); can be more
than one Bates number listed
depending on the number of
attachments
**The CHILD_BATES field
should be populated in each
CUSTODIAN Smith, John "Email: mailbox where the
email resided
Native: Individual from whom
ALL CUSTODIANS Smith, John Custodial source(s) from
Cain, John which document was collected
Thompson, Frank but subsequently suppressed as
a duplicate during processing.
FROM John Smith Email: Sender
Native: Author(s) of document
**semi-colon should be used
to separate multiple entries
TO Coffman, Janice; LeeW Recipient(s)
[mailto:LeeW@MSN.com] **semi-colon should be used
to separate multiple entries
CC Frank Thompson [mailto: Carbon copy recipient(s)
frank_Thompson@cdt.com] **semi-colon should be used
to separate multiple entries
BCC John Cain Blind carbon copy recipient(s)
**semi-colon should be used
to separate multiple entries
SUBJECT Board Meeting Minutes Email: Subject line of the
email
Native: Title of document (if
available)
DATE_SENT 10/12/2010 Email: Date the email was sent
Native: (empty)
TIME_SENT 07:05 PM Email: Time the email was
sent
Native: (empty)
**This data must be a separate
field and cannot be combined
with the DATE SENT field
LINK D:\001\EDC0000001.msg Hyperlink to the email or
native file document
** The linked file must be
named per the FIRSTBATES
number
MIME_TYPE MSG The content type of an Email
or native file document as
identified/extracted from the
header
FILE_EXTEN MSG The file type extension
representing the Email or
native file document; will vary
depending on the email format
AUTHOR John Smith Email: (empty)
Native: Author of the
document
*Parties acknowledge that the
Author field may not actually
reflect the author of the
document.
DATE_CREATED 10/10/2010 Email: (empty)
Native: Date the document was
created
*Parties acknowledge that the
CREATEDATE field may not
actually reflect the date the file
was created, due to the ease of
change to that field and the
technical definition of the field
(e.g., the created date and time
reflects the date when the file
was created in that particular
location on the computer or on
the other storage device
location).
TIME_CREATED 10:25 AM Email: (empty)
Native: Time the document
was created
*This data must be a separate
field and cannot be combined
with the DATE_CREATED
field
*Parties acknowledge that the
CREATETIME field may not
actually reflect the time the file
was created, due to the ease of
change to that field and the
technical definition of the field
(e.g., the created date and time
reflects the time when the file
was created in that particular
location on the computer or on
the other storage device
location).
DATE_MOD 10/12/2010 Email: (empty)
Native: Date the document was
last modified
TIME_MOD 07:00 PM Email: (empty)
Native: Time the document
was last modified
**This data must be a separate
field and cannot be combined
with the DATE_MOD field
DATE_ACCESSD 10/12/2010 Email: (empty)
Native: Date the document was
last accessed
TIME_ACCESSD 07:00 PM Email: (empty)
Native: Time the document
was last accessed
**This data must be a separate
field and cannot be combined
with the DATE_ACCESSD
field
FILE_SIZE 5,952 Size of native file
document/email in KB
PGCOUNT 1 Number of pages in native file
document/email
PATH J:\Shared\SmithJ\October Agenda.doc File path/folder structure of
original native file as it existed
at the time of collection.
i.e. path of email in mailbox
(populate for email
attachments also); filepath of
edocs or scanned documents
ALL PATHS J:\Shared\SmithJ\October Agenda.doc File path/folder structure of
original native file as it existed
O:\JohnSmith\October Agenda.doc at the time of collection but
subsequently removed as a
C:\JS\MyDocuments\OctoberAgenda.doc duplicate.
i.e. path of email in mailbox
(populate for email
attachments also); filepath of
edocs or scanned documents
INTMSGID <000805c2c7lb$75977050$cb Email: Unique Message ID (if requested) when duplicate
8306d1@MSN> Native: (empty)
copies were suppressed during
processing.
MD5 Hash (as to d l3ldd02c5e6eec4693d9a069 8aff95c MD5 Hash (as to Plaintiffs) or
Plaintiffs) or SHA-1 (as 2fcab58712467eab4004583eb SHA-1 (as to Defendants)
to Defendants) 8fb7f89 value of the document.
TEXT From: Smith, John Extracted text of the native file
Sent: Tuesday, October 12, 2010 07:05 document/email
PM
To: Coffman, Janice
Subject: Board Meeting Minutes
Janice;
Attached is a copy of the September
Board Meeting Minutes and the draft
agenda for October. Please let me know
if you have any questions.
John Smith
Assistant Director
Information Technology
Phone: (202) 555-1111
Fax: (202) 555-1112
Email: jsmith@xyz.com
9. DOCUMENTS PROTECTED FROM DISCOVERY
a) Pursuant to Fed. R. Evid. 502(d), the production of a privileged or work-product-protected document or ESI, whether inadvertent or otherwise, is not a waiver of privilege or protection from discovery in this case or in any other federal or state proceeding. For example, the mere production of privileged or work-product-protected documents in this case as part of a mass production is not itself a waiver in this case or in any other federal or state proceeding. This Stipulation shall be interpreted to provide the maximum protection allowed by Federal Rule of Evidence 502(d). Additionally, nothing contained in this Stipulation is intended to or shall serve to limit a Party's right to conduct a review of documents, ESI, or information (including metadata) for relevance, responsiveness, and/or segregation of privileged and/or protected information before production.
b) If any privileged or work product protected document or ESI is produced, inadvertently or otherwise, the party receiving produced documents ("Receiving Party") shall, at the request of the party producing those documents ("Producing Party"), promptly destroy such documents, including all later created excerpts, summaries, compilations, and other documents or records that include, communicate, or reveal the information claimed to be privileged or protected. A Receiving Party who receives a document or ESI that it knows or reasonably should know is privileged shall notify the Producing Party within 3 business days of discovery of the document.
10. MODIFICATION
This Stipulated Order may be modified by a Stipulated Order of the parties or by the Court for good cause shown.
IT IS SO STIPULATED, through Counsel of Record.
PURSUANT TO STIPULATION, IT IS SO ORDERED.
