ANDREW G. SCHOPLER, Magistrate Judge.
The Parties hereby agree to the following production of Electronically Stored Information ("ESI") and paper ("hardcopy") documents. This protocol, subject to the Protective Order in this litigation, governs all production in this litigation. Nothing in this protocol shall limit a party's right to seek or object to discovery as set out in the applicable rules or to object to the authenticity or admissibility of any ESI or hardcopy document produced in accordance with this protocol. The Parties having conferred and agreed to entry of the within Consent Order, and good cause appearing therefore, it is hereby ORDERED as follows:
This Order will govern the production of Electronically Stored Information ("ESI") and hardcopy documents.
The parties shall cooperate to identify and facilitate access to the contents of encrypted, password-protected, corrupted or difficult-to-access files produced. The parties will work cooperatively to fashion reasonable, precise and cost-effective search strategies and to agree upon and implement appropriate measures for quality assurance and quality control. Parties are obliged to be forthcoming and transparent in disclosing their use of mechanized tools to cull responsive data and encouraged to bring technically-adept personnel together to resolve e-discovery issues.
This Order may be modified for good cause. If the parties cannot resolve their disagreements regarding modifications, the parties may submit their competing proposals and a summary of their dispute. Proposed modifications or disputes regarding ESI that counsel for the parties are unable to resolve will be presented to the Court as soon as practicable.
Each party shall designate one or more individuals as Designated ESI Liason(s) for the purpose of meeting and conferring with the other Parties and of attending Court hearings on the subject of ESI. The Designated ESI Liason(s) shall be prepared to speak and explain the Party's relevant electronic systems and capabilities and the technical aspects of the manner in which the Party has responded to e-discovery, including (as appropriate) relevant ESI retrieval technology and search methodology.
Production of ESI and hardcopy documents in the reasonably usable form set out in this protocol need not include any reference to the document requests to which a document may be responsive. However, upon a reasonable request and on a case-by-case basis, a Producing Party will provide a Bates range and/or source file when a particular set of materials can be found in their production.
A Producing Party shall take reasonable steps to de-duplicate ESI vertically (i.e., within custodial or non-custodial data source). "Duplicate ESI" means files that are exact duplicates based on the files' MD5 or SHA-1 hash values. Parties will disclose the method upon which hash values are calculated on emails and email families; any such method shall include BCC values in the calculation. Entire document families may constitute Duplicate ESI. De-duplication shall not break apart families. A document within a family (such as an email attachment) shall not be considered a duplicate of a stand-alone document even if the hash values are the same. In such instance, a copy of both the document family and the stand-alone document will be produced. The Producing Party will not use e-mail threading as a method of de-duplication.
The following categories of ESI are not subject to preservation and are not discoverable:
i. Deleted, "slack," fragmented, or unallocated data on hard drives;
ii. Random access memory (RAM) or other ephemeral data;
iii. On-line access data such as (without limitation) temporary internet files, history files, cache files, and cookies;
iv. System, network, server, or software application logs; and
v. Structural files not material to individual document contents (e.g..CSS, .XSL, .XML, .DTD, etc.). Files with the same file name extensions as structural files but which contain substantive otherwise discoverable information, e.g., a .XML file used for data transfer between systems, are still subject to preservation and are discoverable.
The production media for document productions that do not exceed 5 GB shall be secure FTP link provided via email at the time a production letter is emailed, unless the parties agree otherwise. On the occasions when a particular document production exceeds 5 GB, the production media may be a CD-ROM, DVD, external hard drive (with standard PC compatible interface), or USB drive, so long as such production media is sent no slower than overnight delivery via FedEx, UPS, or USPS. Each item of production media (or in the case of FTP productions, each production transmittal letter) shall include: (1) text referencing that it was produced in Andren, et al. v. Alere, Inc., et al., (2) the type of materials on the media (e.g., "Documents," "OCR Text," "Objective Coding," etc.), (3) the production date, (4) the Bates number range of the materials contained on such production media item, and (5) a short description of the categories of information in the production (e.g., Custodian X's email, centralized purchasing files, etc.). The ESI Liaisons shall designate the appropriate physical address for productions exceeding 5 GB that are produced on physical media.
All production images will be provided as single page Group IV TIFFs of at least 300 dpi resolution. Page size shall be 8.5 x 11 inches unless in the reasonable judgment of the producing party, a particular item requires a different page size. Each image will use the Bates number of the first page of the document as its unique file name. Original document orientation should be maintained (i.e., portrait to portrait and landscape to landscape). Hidden content, tracked changes or edits, comments, notes and other similar information viewable within the native file shall also be imaged so that this information captured on the produced image file.
Each paper document or ESI item produced under this order shall be accompanied by a text file as set out below. All text files shall be provided as a single document level text file for each item, not one text file per page. Each text file shall be named to use the Bates number of the first page of the corresponding production item.
Paper documents will be accompanied by an OCR file. The parties will endeavor to generate accurate OCR and will utilize quality OCR processes and technology. The parties acknowledge, however, that due to poor quality of the originals, not all documents lend themselves to the generation of accurate OCR. OCR text files should indicate page breaks where possible.
Emails and efiles will be accompanied by extracted text taken from the ESI item itself. The extracted text will include any From, To, CC, BCC, Subject and Attachment labels and values present in the email.
All images must be assigned a Bates number that must always: (a) be unique across the entire document production; (b) maintain a constant length (0- padded) across the entire production; (c) contain no special characters or embedded spaces; and (4d) be sequential within a given document. If a Bates number or set of Bates numbers is skipped in a production, the producing party will so note in a cover letter or production log accompanying the production. The producing party will brand all TIFF images in the lower right-hand corner with its corresponding bates number, using a consistent font type and size. The Bates number must not obscure any part of the underlying image. If the placement in the lower right-hand corner will result in obscuring the underlying image, the Bates number should be placed as near to that position as possible while preserving the underlying image.
Parent-child relationships (the association between an attachment and its parent document) that have been maintained in the ordinary course of business should be preserved. For example, if a party is producing a hard copy printout of an e-mail with its attachments, the attachments should be processed in order behind the e-mail.
All production items will be provided with a delimited data file or "load file." Acceptable formats for the load file are .log, .opt, .dii .lfp, .txt, .dat, or .csv, as detailed in Appendix 1. Each party will designate its preferred load file format. The load file must reference each TIFF in the corresponding production. The total number of documents referenced in a production's data load file should match the total number of designated document breaks in the Image Load files in the production. Each deliverable volume should limit directory contents to approximately 1000 files per folder.
Documents or ESI containing color shall be produced initially in color. The production of documents and/or ESI in color shall be made in TIFF format or in an alternative format, such as single page JPEG format, that provides sufficient quality for the review of these documents and/or ESI. All requirements for productions stated in this Order regarding productions in TIFF format would apply to any productions of documents and/or ESI in color made in such an alternative format.
If a particular paper document or ESI item qualifies for confidential treatment pursuant to the terms of a Protective Order entered by the Court in this litigation, or has been redacted in accordance with applicable law or Court order, the designation shall be shown both on the face of all TIFFs pertaining to such item/document, and in the appropriate data field in the load file.
The parties agree that responsive paper documents from Document Custodians will be scanned and produced electronically rather than in paper format. Generally all centralized paper documents will be scanned and produced electronically, unless a party establishes good cause for making such documents available via paper and reasonable access is provided to the opposing party to review the documents directly.
The following information shall be produced in the load file accompanying production of paper documents: (a) BegBates, (b) EndBates, (c) BegAttach, (d) EndAttach, (e) PgCount, (f) Custodian, (g) Source Party, (h) TextPath, (i) Confidentiality, and (j) Redacted (Y/N). Additionally, all paper documents will be produced with a coding field named "Paper Document" marked with a "Y."
Paper documents should be logically unitized for production. Therefore, when scanning paper documents for production, distinct documents shall not be merged into a single record, and single documents shall not be split into multiple records.
Where the documents were organized into groups, such as folders, clipped bundles and binders, this structure shall be maintained and provided in the load file. The relationship among the documents in a folder or other grouping should be reflected in proper coding of the beginning and ending document and attachment fields. The parties will make their best efforts to unitize documents correctly.
Where a document, or a document group — such as folder, clipped bundle, or binder — has an identification spine or other label, the information on the label shall be scanned and produced as the first page of the document or grouping.
The parties will utilize best efforts to ensure that paper records for a particular custodian, which are included in a single production, are produced in consecutive Bates stamp order.
ESI productions may be de-nisted using the industry standard list of such files maintained in the National Software Reference Library by the National Institute of Standards & Technology. Other file types may be added to the list of excluded files by agreement of the parties.
The parties agree that ESI shall be produced as TIFFs with an accompanying load file, which will contain, among other data points, the ESI data points listed in Appendix 2 hereto. The exception to this rule shall be word processing documents with tracked changes or comments (e.g. MS Word), presentation-application files (e.g., MS PowerPoint), spreadsheet-application files (e.g., MS Excel), personal databases (e.g., MS Access), and multimedia audio/visual files such as voice and video recordings (e.g., .wav, .mpeg, and .avi), for which all ESI items shall be produced in native format. In the case of personal database (e.g., MS Access) files containing confidential or privileged information, the parties shall meet and confer to determine the appropriate form of production. In addition to producing the above file types in native format, the producing party shall produce a single-page TIFF slip sheet indicating that a native item was produced and providing the file name of the natively produced document (e.g., "Order.docx"). The corresponding load file shall include NativeFileLink information for each native file that is produced. Further, the parties agree to meet and confer prior to producing native file types other than MS PowerPoint, MS Excel, and multimedia audio/visual file types such as .wav, .mpeg and .avi. Prior to processing non-standard native files for production, the producing party shall disclose the file type, and meet and confer with, the receiving party on a reasonably useable production format. The parties agree to meet and confer to the extent that there is data in databases, database application files, or other applications using structured data or aggregated data, such as SQL databases, adverse event tracking applications, SAS, and SAP, to determine the best reasonable form of production of usable data. Through the pendency of this Litigation, the producing party shall exercise reasonable, good faith efforts to maintain all preserved and collected native files in a manner that does not materially alter or modify the file or the metadata.
Other than as specifically set forth above, a producing party need not produce documents in native format. A party may request that a document not produced in native format be produced in native format, and the producing party will comply with such requests to the extent that they are reasonable and proportional to the needs of the case, in accordance with the applicable rules of civil procedure. The parties will meet and confer with respect to any disagreements of the reasonableness and proportionality of a request, and may apply to the Court for determination in the event of continued disagreement. The requesting party will provide a specific Bates range for documents it wishes to be produced in native format. Any native files that are produced should be produced with a link in the NativeLink field, along with all extracted text and applicable metadata fields set forth in Appendix 2.
a. The parties agree that where ESI items need to be redacted, they shall be produced solely in TIFF with each redaction clearly indicated, except in the case of personal database files, which shall be governed by ¶ V(3), supra. Any unaffected data fields specified in Appendix 2 shall be provided. For example, if attorney-client privilege requires that the BCC field of a document needs to be redacted, all other available data fields specified in Appendix 2 shall be provided and the redacted metadata fields will be clearly indicated.
b. If the items redacted and partially withheld from production are Word-type documents, PowerPoint-type presentation decks or Excel-type spreadsheets as addressed in ¶ IV.3, supra, and the native items are also withheld, the entire ESI item must be produced in TIFF format, including all unprivileged pages, hidden fields and other information that does not print when opened as last saved by the custodian or end-user. For PowerPoint-type presentation decks, this shall include, but is not limited to, any speaker notes. For Excel-type spreadsheets, this shall include, but is not limited to, hidden rows and columns, all cell values, annotations and notes. The producing party shall also make reasonable efforts to ensure that any spreadsheets produced only as TIFF images are formatted so as to be legible. For example, column widths should be formatted so that the numbers in the column will display rather than "##########."
c. If the items redacted and partially withheld from production are audio/visual files, the producing party shall provide the unredacted portions of the content. If the content is a voice recording, the parties shall meet and confer to discuss the appropriate manner for the producing party to produce the unredacted portion of the content.
ESI that cannot be reviewed, produced and/or imaged because of technical issues should be identified as exception files and included on a log that lists the file name, custodian, and reason for exception: for example, corruption, unavailable password protection, proprietary software, or other technical issues. The producing party shall provide an updated copy of this log to the receiving party within three (3) business days of a production, and shall provide a final copy of the log upon completion of document production. If the receiving party requests production of any files listed on the exception log, the parties will meet and confer on a reasonable and cost-effective means for attempting to provide the requested files.
The Parties agree to meet and confer in good faith regarding the formulation and validation of appropriate search terms and protocols in advance of any search to cull Document Custodians' ESI.
The parties agree to meet and confer in good faith about any other technology or process that a producing party proposes to use to reduce the document population to be produced or to identify documents to be included or excluded from that population in this case (e.g., near de-duplication, any technology assisted review or advanced analytic (i.e., non-Boolean) automated "filtering" or "culling" application to identify items which are potentially responsive or which are to be excluded from its production).
With respect to any ESI items that are password-protected or encrypted, the Producing Party will take reasonable steps based on industry standards to break the protection so that the document can be reviewed and/or produced. In the event that encrypted or password-protected documents, which are reasonably likely to be responsive to Plaintiffs' document requests, remain for a particular custodian after such reasonable efforts have been made, the producing party shall let the receiving party know the total number of such documents and each individual producing party shall meet and confer with the receiving party.
ESI items processed after the execution date of this Production Order shall be processed, to the extent practicable, in a manner that preserves hidden columns or rows, hidden text or worksheets, speaker notes, tracked changes and comments.
Objects embedded in Microsoft Word and .RTF documents, which have been embedded with the "Display as Icon" feature, will be extracted as separate documents and treated like attachments to the document. Other objects embedded in documents, e.g., in PowerPoint presentations, shall be produced as native files and treated like attachments to the document. Image files in emails, e.g., as part of signature blocks, should not be separately produced.
Compression file types (i.e., .CAB, .GZ, .TAR, .Z,.ZIP) shall be decompressed in a reiterative manner to ensure that a zip within a zip is decompressed into the lowest possible compression resulting in individual folders and/or files.
For each of Defendants' current or former employees identified as a Document Custodian (through the parties' meet and confer process), Defendants will do the following:
Unless Defendants establish good cause to the contrary, the presumption is that Defendants will collect all emails sent to or received by a Document Custodian regardless of whether such emails are in the Document Custodian's actual email account.
To the extent a Document Custodian made any use of cloud-based document storage services (such as DropBox) for work-related purposes, Defendants will obtain such information and produce responsive information. If for some reason Defendants are unable to obtain cloud-based ESI for a Document Custodian, then Defendants will provide Plaintiffs with a written explanation of the circumstances of the inability, including (a) the name of the Document Custodian, (b) the name of the cloud-based system on which the data is believed to be stored, (c) a description of the type of ESI believed to be stored in the Cloud-based system, (d) the efforts Defendants undertook to obtain the information, (e) whether any data on the cloud-based email system is believed to have been deleted or lost, and if so, when, and (f) whether or not the user name and password for such information is known to the Document Custodian and/or Defendants.
For any document withheld in its entirety or produced but redacted, the producing party will produce privilege/redaction logs in Excel format or any other format that permits electronic sorting and searching, except that the Parties shall have no obligation to log information generated after the date of commencement of this lawsuit. A producing party will produce a separate privilege/redaction log for each production within 21 days of the production of documents for which a privilege is asserted. A party asserting privilege over a chain of emails must assert privilege separately on the privilege log as to each portion of the email chain.
Following the receipt of a privilege/redaction log, a receiving party may identify, in writing, the particular documents that it believes require further explanation. Within 21 days of such identification, the producing party must respond to 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 matter shall be brought to the Court.
The parties will not make any redactions based upon the purported relevancy of a document.
Nothing in this protocol shall be interpreted to require disclosure of information protected by the attorney-client privilege, work-product doctrine, or any other applicable privilege or immunity. Except as provided expressly herein, the parties do not waive any objections as to the production, discoverability, authenticity, admissibility, or confidentiality of documents and ESI.
To the extent a response to discovery requires production of discoverable electronic information contained in a database, or other structured or aggregated data source, the parties shall meet and confer to determine the format of production. In the absence of agreement, a party may apply to the Court for resolution. Prior to the meet and confer, the requesting party may make reasonable requests for additional information, e.g., to explain the database's or data source's purpose and function, reporting or exporting functionality and formats, schema, codes, abbreviations, user and administrator manuals, etc.
If a producing party asserts that certain ESI is inaccessible or otherwise unnecessary under the circumstances, or if the requesting party asserts that, following production, certain ESI is not reasonably usable, the parties shall meet and confer with their respective technology experts to discuss resolving such assertions. If the parties cannot resolve any such disputes after such a meet and confer has taken place, the issue shall be presented to the Court for resolution.
4. No party shall modify the date or time as contained in any original ESI.
5. If either party objects to producing the requested information on the grounds that such information is not reasonably accessible because of undue burden or cost, or because production in the requested format is asserted to be not reasonably accessible because of undue burden or cost, and before asserting such an objection, the responding party will inform the requesting party of the format, if any, in which it is willing to produce it, the nature and location of the information claimed to not be reasonably accessible, the reason(s) why the requested form of production would impose an undue burden or is unreasonably costly, and afford the requesting party 21 business days from receipt of such notice to propose an alternative means of compliance with the request. Such proposal may include alternative cost estimates for ESI discovery production. Prior to a party producing ESI in a format not requested and/or agreed to by the requesting party, (1) the parties will meet and confer regarding the issue, and failing resolution, the parties will (2) file a joint letter brief with the Court regarding the issue, with each party permitted 2 pages to lay out its position.
6. If a party believes that responsive ESI no longer exists in its original format, or is no longer retrievable, the responding party shall explain where and when it was last retrievable in its original format, and disclose the circumstances surrounding the change in status of that ESI, including the date of such status change, the person or persons responsible for such state change, the reason or reasons such ESI is no longer retrievable in that format, and whether any backup or copy of such original ESI exists, together with the location and the custodian thereof.
The name of the image load file should mirror the name of the delivery volume, and should have the appropriate extension (e.g., ABC001.LFP).
The volume names should be consecutive (i.e., ABC001, ABC002, et. seq.).
There should be one row in the load file per TIFF image.
Every image in the delivery volume should be contained in the image load file.
The image key should be named the same as the Bates number of the page.
Load files should not span across media (e.g., CDs, DVDs, Hard Drives, Etc.), i.e., a separate volume should be created for each piece of media delivered.
Files that are the first page of a logical document should include a "D" where appropriate. Files that are the first page of an attachment to an e-mail should include a "C" where appropriate. Subsequent pages of all documents (regular document, e-mail, or attachment) should include a blank in the appropriate position.
þBegDocþþEndDocþþBegAttachþþEndAttachþþPgCountþþCustodianþ The data load file should use standard Concordance delimiters:
The first record should contain the field names in the order of the data.
All date fields should be produced in mm/dd/yyyy format.
Use carriage-return line-feed to indicate the start of the next record.
Load files should not span across media (e.g., CDs, DVDs, Hard Drives, etc.); a separate volume should be created for each piece of media delivered.
The name of the data load file should mirror the name of the delivery volume, and should have a.DAT extension (i.e., ABC001.DAT).
The volume names should be consecutive (i.e., ABC001, ABC002, et. seq.).
If Foreign Language/Unicode text exists, DAT file shall be in appropriate UTF-8 or UTF-16 format.
OCR or Extracted Text files shall be provided in a separate \OCR\ directory containing Document level text files
If Foreign Language/Unicode text exists, TEXT files shall be in appropriate UTF-8 or UTF-16 format
