PAUL L. ABRAMS, Magistrate Judge.
This Order governs how the Parties and the Court will manage electronic discovery in the above-captioned case (the "Action").
This Stipulated Protective Order Regarding the Production of Electronically Stored Information (hereinafter referred to as the "Protocol") governs the collection and production of Electronically Stored Information and Hard Copy Documents (collectively, "Data"), that are to be produced electronically in this Action.
Nothing herein shall alter the Parties' respective responsibility to comply with the Federal Rules of Civil Procedure and Local Rules regarding the collection or production of Data. To the extent additional obligations or rights not addressed in this Protocol arise under the Federal Rules of Civil Procedure or other applicable law or rules, that law or rule shall govern.
If there is a conflict between the provisions of this Protocol and any order governing discovery in this action, including but not limited to the Stipulated Protective Order in this Action, the provisions of those other orders shall control. Nothing in this Protocol is meant to supersede, replace, or substitute any of the provisions set forth in the Protective Order. If there is a conflict between the provisions of this Protocol and the Protective Order, the Protective Order shall control.
Nothing in this Protocol establishes any agreement regarding the subject matter or scope of discovery in this Action, or the relevance or admissibility of any Data.
Nothing in this Protocol shall be interpreted to require disclosure of irrelevant information or relevant Data protected by the attorney-client privilege, work-product doctrine, or any other applicable privilege or immunity. The Parties reserve all rights and do not waive any objections as to the production, discoverability, admissibility, or confidentiality of Documents. Nothing in this Protocol shall affect, in anyway, a Producing Party's right to seek or oppose reimbursement for costs associated with collection, review, and/or production of Data.
"Documents" shall have the same definition as set forth in Federal Rule of Civil Procedure 34.
"Electronically Stored Information" or "ESI" are synonymous with the usage of the term in Federal Rule of Civil Procedure 34 and means information that is stored electronically, regardless of the Media or whether it is in the original format in which it was created.
"Extracted Text" means the text extracted from a document, and includes all header, footer, and document body information when reasonably available.
"Hard Copy Documents" means computer printouts or handwritten material originating from the paper files of a Party.
"Load File" means an electronic file containing information identifying a set of paper-scanned images or processed ESI and indicating where individual pages or files belong together as Documents, including attachments, and where each document begins and ends. A load/unitization file is provided with a production set of document images that facilitates the loading of such information into a Receiving Party's document review platform, and the correlation of such data in the platform such as data relevant to the individual Documents, including extracted and user-created Metadata.
"Media" means an object or device on which data is or was stored, including but not limited to a disc, tape, computer or other device, regardless whether in the Producing Party's physical possession.
"Metadata" means: (i) information embedded in or associated with a native file that is not ordinarily viewable or printable from the application that generated, edited, or modified such native file which describes the characteristics, origin, usage, and/or validity of the electronic file; and/or (ii) information generated automatically by the operation of a computer or other information technology system when a native file is created, modified, transmitted, deleted, or otherwise manipulated by a user of such system.
"Native Format" means and refers to the format of ESI in which it was generated and/or as used by the Producing Party in the usual course of its business and in its regularly conducted activities.
"OCR" means optical character recognition.
"OCR Text" means text generated through an OCR process.
"Parties" means or refers collectively to the named plaintiffs and defendants in the above-captioned action, as well as any later added plaintiff and defendants. "Party" shall refer to a plaintiff or defendant, individually.
"Producing Party" means or refers to a Party in the above-captioned action from which production of ESI or Hard Copy Documents are sought.
"Requesting Party" means or refers to a Party in the above-captioned action seeking production of ESI or Hard Copy Documents.
Hard Copy Documents should be scanned as single-page, Group IV, 300 DPI TIFF images with an .opt image cross-reference file and a delimited database Load File (i.e., .dat).
If particular documents warrant a different format, the parties will cooperate to arrange for the mutually acceptable production of such documents. The parties agree not to degrade the searchability of documents as part of the document production process. The database Load File should contain the following fields: "BatesStart," "BatesEnd," "BatesNumPages," "VOLUME" and "CUSTODIAN." The Documents should be logically unitized (i.e., distinct Documents shall not be merged into a single record, and single Documents shall not be split into multiple records) and be produced in the order in which they are kept in the usual course of business. If a Party determines that unitizing Documents or categories of Documents stored as a unit in the ordinary course is not feasible, or is unduly burdensome or expensive, the Parties shall meet and confer in good faith to resolve the issue. If an original document contains color, and the color is necessary to understand the meaning or content of the document, the document shall be produced as single-page, 300 DPI JPG images with JPG compression and a high quality setting as to not degrade the original image. Multi-page OCR text for each document should also be provided. The OCR software shall maximize text quality. Settings such as "auto-skewing" and "auto-rotation" should be turned on during the OCR process.
The Parties will produce ESI in single-page, black and white, TIFF Group IV, 300 DPI TIFF images with the exception of Microsoft Access databases, Microsoft Excel files, .CSV files and other similar databases, spreadsheet files, source code, audio, and video files, which shall be produced in Native Format. Data containing color need not initially be produced in color unless the Producing Party has referred to the color version or if color is of assistance in understanding the meaning or content of the Data. The Producing Party will also honor reasonable requests for color images needed to understand the meaning or content of Data. Documents produced in color should be produced as single-page, 300 DPI JPG images with JPG compression and a high quality setting as to not degrade the original image. Parties are under no obligation to enhance an image beyond how it was kept in the usual course of business. TIFFs/JPGs will show any and all text and images which would be visible to the reader using the native software that created the document. For example, TIFFs/JPGs of e-mail messages should include the BCC line if a name(s) or email address(es) are present in the email or the Metadata.
If a document is produced in Native Format, a single-page Bates stamped image slip sheet stating the document has been produced in Native Format will also be provided. A Party shall produce a single TIFF placeholder image, numbered using the bates number of the produced file, for any file produced in Native Format. Each native file should be named according to the Bates number it has been assigned, and should be linked directly to its corresponding record in the Load File using the NATIVELINK field. To the extent that either Party believes that specific Documents or classes of Documents, not already identified within this protocol, should be produced in Native Format, the parties agree to meet and confer in good faith.
Text files shall be produced as one file per document, named after the starting production number assigned to the document and ending with extension ".txt", with a text directory for each production volume, and with a relative file path to the text file provided in the related database Load File. With the exception of TIFF, PDF and other image file types for which the text cannot be extracted, the text of Documents should be extracted directly from the Native File without using OCR, except in the case of redacted Documents, as specified in Section 3.9, below. If a document does not contain extractable text, but is identified as containing text, the Producing Party shall make reasonable efforts to provide OCR Text for that document. If a Party determines that providing OCR Text for specific Documents or categories of Documents not containing extractable text is not feasible, or is unduly burdensome or expensive, the Parties shall meet and confer in good faith to resolve the issue.
Electronic Documents attached to an email, or electronic Documents embedded within other electronic Documents, are to be produced contemporaneously and sequentially immediately after the parent document. Parent-child relationships within a document family (the association between an attachment and its parent document) shall be preserved. Each document shall be produced with the production number for the first and last page of that document in the "BatesStart" and "BatesEnd" fields of the data Load File and with the "AttachBatesStart" and "AttachBatesEnd" fields listing the production number for the first and last page in the document family. Nothing in the Protocol requires the production of a non-responsive child document attached to an otherwise responsive parent or child document. In these instances, a placeholder image will be produced for the non-responsive document, which will contain language indicating it has been withheld as non-responsive. Metadata for a withheld and purportedly non-responsive child document reflecting its file name and family information will be produced with the placeholder image. Nothing in this Protocol prejudices a Party from challenging another Party's withholding of a purportedly non-responsive child document.
Each Party shall remove exact duplicate Documents based on MD5 or SHA-1 hash values, at the family level. Attachments should not be eliminated as duplicates for purposes of production, unless the parent e-mail and all attachments are also duplicates. Parties agree that an e-mail that includes content in the BCC or other blind copy field shall not be treated as a duplicate of an e-mail that does not include content in those fields, even if all remaining content in the e-mail is identical. Removal of near-duplicate Documents and e-mail thread suppression is not acceptable. De-duplication will be done across the entire collection (global de-duplication) and the ALL CUSTODIAN field will list each custodian, separated by a semi-colon, who was a source of that document and the FILEPATH field, where such Metadata is retained and reasonably available, will list each file path, separated by a semi-colon, that was a source of that document. Should the ALL CUSTODIAN or FILEPATH Metadata fields produced become outdated due to rolling productions, an overlay file providing all the custodians and file paths for the affected Documents will be produced at the time of the substantial completion of the document production.
All ESI will be produced with a delimited, database Load File that contains the Metadata fields listed in the table of Section 3.1. The Metadata produced should have the correct encoding to enable preservation of the Documents' original language. Each of the Metadata fields set forth in the table of Section 3.1 that reasonably can be extracted from an electronic document without undue burden shall be produced for that document, subject to privilege or immunity from disclosure. Fields that are not populated shall be left with null values and not populated with fillers or spaces.
Non-substantive objects, such as corporate logos and contact blocks may be removed from production. Embedded objects containing substantive information, such as graphs or charts, will be produced as an attachment. The Parties agree to further meet and confer over the inclusion or exclusion of embedded files from the production as needed.
Compressed file types (e.g., .ZIP, .RAR, .CAB, .Z) should be decompressed so that the lowest level document or file is extracted.
To the extent a response to discovery requires production of electronic information stored in a database, including the production of text messages or similar communications, the Parties will meet and confer regarding methods of production. The Parties will consider whether all relevant information may be provided by querying the database for discoverable information and generating a report in a reasonably usable and exportable electronic file.
If any Documents are unprocessed or unprocessable, the Producing Party shall produce a slip sheet with the file name and file type.
To maximize the security of information in transit, any Media on which Documents are produced may be encrypted. In such cases, the Producing Party shall transmit the encryption key or password to the Receiving Party, under separate cover, contemporaneously with sending the encrypted Media.
To the extent that any image file contains information subject to a claim of privilege or other recognized legal protection that requires redactions, the portion of the redacted text shall be clearly identified on the face of the TIFF image, either by masking the redacted content with electronic highlighting in black or through the use of redaction boxes. The label "Redacted" and the basis for the redaction shall appear on the page of the document containing redactions. To the extent a document is redacted, OCR text files for such a document shall not contain text for redacted portions. The original unredacted native file shall be preserved pending conclusion of the Action.
If Documents that the Parties have agreed to produce in Native Format need to be redacted, the Parties will meet and confer regarding how to implement redactions while ensuring that proper formatting and usability are maintained.
No Party shall use predictive coding/technology-assisted-review for the purpose of culling the Documents to be reviewed or produced without notifying the opposing Party or Parties prior to use and with ample time to meet and confer in good faith regarding a mutually agreeable protocol or other agreement for the use of such technologies.
The Parties agree to meet and confer in good faith regarding matters related to the production of Data not specifically set forth in this Protocol, related to the interpretation of this Protocol, or related to the Parties' obligations hereunder. The Parties shall make their best efforts to comply with and resolve any differences concerning compliance with this Protocol. If a Producing Party cannot comply with any material aspect of this Protocol, such Party shall inform the Requesting Party in writing at or before the time of production as to why compliance with the Protocol is unduly burdensome or costly, or not reasonably possible.
I, Douglas A. Smith, attest that the signatories listed above, and on whose behalf the filing is submitted, concur in the filing's content and have authorized the filing.
Having considered the papers, and finding that good cause exists, the Parties' Stipulated Order Regarding the Production of ESI is