Opinion
1:19-cv-2601-VM-SN
09-16-2022
IN RE EUROPEAN GOVERNMENT BONDS ANTITRUST LITIGATION
DICELLO LEVITT LLC GREGORY S. ASCIOLLA SCOTT+SCOTT ATTORNEYS AT LAW LLP CHRISTOPHER M. BURKE LOWEY DANNENBERG, P.C. VINCENT BRIGANTI BERMAN TABACCO TODD A. SEAVER CRAVATH, SWAINE & MOORE LLP John Buretta Helam Gebremariam Attorneys for Defendant Nomura International plc PAUL, WEISS, RIFKIND, WHARTON & GARRISON LLP Aidan Synnott Attorneys for Defendant Nomura Securities International Inc. SKADDEN, ARPS, SLATE, MEAGHER & FLOM LLP AND AFFILIATES Boris Bershteyn Susan Saltzstein Sam Auld Attorneys for Defendant UniCredit Bank AG MILBANK LLP Fiona A. Schaeffer James G. Cavoli Mark D. Villaverde Attorneys for Defendant Natixis S.A. CLEARY GOTTLIEB STEEN & HAMILTON LLP Lev L. Dassin Roger A. Cooper Andrew Weaver Attorneys for Defendants Citigroup Global Markets Inc. and Citigroup Global Markets Limited MORGAN, LEWIS & BOCKIUS LLP Jon R. Roellke Kenneth I. Schacter Brian A. Herman Jawad B. Muaddi Elizabeth Buechner Attorneys for Defendants Jefferies International Limited and Jefferies LLC
DICELLO LEVITT LLC
GREGORY S. ASCIOLLA
SCOTT+SCOTT ATTORNEYS AT LAW LLP
CHRISTOPHER M. BURKE
LOWEY DANNENBERG, P.C.
VINCENT BRIGANTI
BERMAN TABACCO
TODD A. SEAVER
CRAVATH, SWAINE & MOORE LLP
John Buretta
Helam Gebremariam
Attorneys for Defendant Nomura International plc
PAUL, WEISS, RIFKIND, WHARTON & GARRISON LLP
Aidan Synnott
Attorneys for Defendant Nomura Securities International Inc.
SKADDEN, ARPS, SLATE, MEAGHER & FLOM LLP AND AFFILIATES
Boris Bershteyn
Susan Saltzstein
Sam Auld
Attorneys for Defendant UniCredit Bank AG
MILBANK LLP
Fiona A. Schaeffer
James G. Cavoli
Mark D. Villaverde
Attorneys for Defendant Natixis S.A.
CLEARY GOTTLIEB STEEN & HAMILTON LLP
Lev L. Dassin
Roger A. Cooper
Andrew Weaver
Attorneys for Defendants Citigroup Global Markets Inc. and Citigroup Global Markets Limited
MORGAN, LEWIS & BOCKIUS LLP
Jon R. Roellke
Kenneth I. Schacter
Brian A. Herman
Jawad B. Muaddi
Elizabeth Buechner
Attorneys for Defendants Jefferies International Limited and Jefferies LLC
ORDER RE: DISCOVERY OF ELECTRONICALLY STORED INFORMATION AND HARD COPY DOCUMENTS
SARAH NETBURN, UNITED STATES MAGISTRATE JUDGE
The Parties to the above-captioned litigation, through their counsel, submit this [Proposed] Order Re: Discovery of Electronically Stored Information and Hard Copy Documents (“ESI Protocol” or “Protocol”), to facilitate discovery in this litigation.
The Parties shall make good-faith efforts to comply with and resolve any differences concerning compliance with this Protocol. If a Producing Party, notwithstanding its good-faith efforts, is unable to reasonably comply with any material aspect of this Protocol, such Party shall inform the Receiving Party in writing a reasonable time before the date of production as to why compliance with the Protocol is unreasonable. This Protocol is intended to serve as a supplement to the Local Rules, the Federal Rules of Civil Procedure, and/or other applicable statutes, laws or rules. The Parties specifically reserve all of their rights and objections to any discovery that may be served upon them in this matter.
I. DEFINITIONS
1.1. “Action” means the above-captioned matter, and any and all cases consolidated or coordinated with it.
1.2. “Custodial Data Source” means any data source that is kept or maintained by any particular agreed Custodian or potential Custodian, as defined herein, which may contain potentially relevant Documents or ESI (as defined herein), including data sources used by any department, business unit, or division of a Producing Party (as defined herein), and shared storage systems that may contain potentially relevant information.
1.3. “Custodian” means the individual or originating source from which Documents or ESI, as defined herein, will be collected and reviewed.
1.4. “Document” shall have the meaning contemplated by Rule 26.3(c)(2) of the Local Rules of Civil Procedure of the United States District Court for the Southern District of New York (“Local Rules”) and Federal Rule of Civil Procedure 34(a)(1)(A). A reference to “Document(s)” shall include both ESI and Hard Copy Document(s), as defined herein. A draft or non-identical copy is a separate Document.
1.5. “Document Family” refers to a group of related ESI, as defined herein, that includes parent and child Documents as maintained in the ordinary course of business (e.g., a parent Email and any attachments thereto).
1.6. “ESI” is an abbreviation of “electronically stored information” and shall have the same meaning it has in Federal Rule of Civil Procedure 34(a)(1)(A).
1.7. “Email” means an electronic means for sending, receiving, and managing communications via structured data applications (Email client software), including, but not limited to, Microsoft Outlook, Google, Gmail, Yahoo Mail, or Lotus Notes, and the file created or received by such means, though the inclusion of any platform, program, client, or software as an example herein will not obligate any Party to collect such ESI.
1.8. “Extracted Text” means the text extracted from a Document, and includes all header, footer and Document body information when reasonably available. A “Text File” is a file containing the full text of native files extracted directly from the native file, or, in the case of Hard Copy Documents or scanned PDF Documents, subject to OCR (as defined herein), a file containing the text resulting from the OCR.
1.9. “Hard Copy Document” means a Document maintained in physical form and collected from physical files (paper) and not from electronic sources.
1.10. “Instant Message” means a real-time communication sent via chat or SMS, including but not limited to, Bloomberg Chat, Google Talk, WhatsApp, Yahoo! Messenger, AOL Instant Messenger, Blackberry Messenger, ICQ, Pidgin, Line, Audium, Trillian, iMessage, Facebook Messenger, Slack, or any other proprietary instant messaging system.
1.11. “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 belonging together as Documents, including attachments, and where each Document begins and ends. A Load File is used to import into a Document database all image, native, and text files and their corresponding production information, including extracted and user-created Metadata (as defined herein), as well as OCR (as defined herein) or Extracted Text, should such data be available.
1.12. “Media” means an object or device, real or virtual, including but not limited to a disc, tape, computer or other device on which data is or was stored.
1.13. “Metadata” is used to describe the structural information of a file that contains data about the file, as opposed to describing the content of a file, and refers to the fields listed in Appendix A.
1.14. “Native” or “Native Format” means and refers to the format of ESI in the application in which it was originally created and/or as used by the Producing Party, as defined herein, in the usual course of its business and in its regularly conducted activities.
1.15. “Non-Custodial Data Source” means any data source that is not kept or maintained by any particular agreed Custodian or potential Custodian but which may contain potentially relevant Documents or ESI, including data sources used by any department, business unit, or division of a Producing Party, and shared storage systems that may contain potentially relevant information.
1.16. “OCR” means the optical character recognition technology used to read Hard Copy Documents or electronic images of Documents and output such Documents to a searchable text format. The latter text is also referred to as the “OCR text” or simply “OCR.”
1.17. “Party” or “Parties” means, individually or collectively, all Plaintiffs and Defendants, as well as any later added plaintiffs and defendants.
1.18. “Producing Party” means or refers to any Party in the litigation from which production of ESI or Hard Copy Documents are sought.
1.19. “Receiving Party” means or refers to any Party in the litigation seeking production of ESI or Hard Copy Documents.
1.20. “Search Term” means a combination of words (including synonyms) and phrases designed to capture potentially relevant ESI, and includes strings of words and phrases joined by proximity and Boolean connectors.
1.21. “Structured Data” means data that resides in a fixed field within a record or file, or stored in a structured format, such as databases (such as Oracle, SQL, Access) or data sets, according to specific form and content rules as defined by each field of the database.
1.22. “Tagged Image File Format” or “TIFF” refers to the CCITT Group IV graphic file format for storing bit-mapped images of ESI or Hard Copy Documents. For files produced as TIFF images, each page of a Document shall be electronically saved as an image file, as outlined in
Appendix A.
II. SCOPE
2.1. The procedures and protocols outlined in this Protocol shall govern the production format of Hard Copy Documents and ESI in this Action unless the Parties agree in writing to change them or the Court changes them at the request of a Party. All productions made pursuant to this Protocol will be subject to the protective order that will be entered into by the Court and any further protective orders or privilege orders entered in this Action. Nothing in this Protocol is intended to be an exhaustive list of discovery obligations or rights of a Party requested to produce Documents or ESI, or of a Party requesting Documents or ESI.
2.2. This Protocol does not define the scope of production, nor the relevance of any particular information. This Protocol is intended to aid the Parties by providing a more predictable, cost-effective, and efficient management structure for the maintenance and production of electronic discovery. Nothing in this Protocol establishes any agreement as to either the temporal or subject matter scope of discovery in the Action, except as expressly stated. The discovery requests, objections thereto, agreements of the Parties, applicable law and rules and any Court orders shall govern the scope of Documents to be produced.
2.3. The production specifications in this Protocol apply to Documents that are produced in this Action, except that, to the extent any Party is required or agrees to re-produce Documents in this Action that originally were produced in other cases or government or intergovernmental investigations, including to the European Commission, such Documents may be produced in the same format in which they originally were produced in connection with such other cases or investigations, and nothing herein shall require the Producing Party to re-process or re-collect data or Documents (including re-population of Metadata fields) that have been processed or collected in connection with such other cases or investigations.
2.4. The Parties do not waive any objections including to the responsiveness, production, discoverability, possession, custody, control, or confidentiality of Documents, including (without limitation) objections regarding the burden, over-breadth, or relevance of any Document requests, or any other objection under the Local Rules or Federal Rules of Civil Procedure. Nothing in this Protocol shall be interpreted to require the disclosure of information that is otherwise not discoverable under the Local Rules, Federal Rules of Civil Procedure, or other applicable statutes, laws or requirements.
2.5. The Parties shall meet and confer in good faith in an effort to resolve any disputes that may arise under this Protocol, prior to seeking assistance from the Court.
III. PRESERVATION
The Parties have taken and will continue to take reasonable steps to preserve relevant Documents and ESI in accordance with their obligations under applicable law.
To the extent that a Party wishes to exclude a category of Documents from preservation or production on the basis of proportionality or undue burden, the Producing Party will disclose the Document category and extent of the burden and Parties will meet and confer accordingly.
IV. IDENTIFICATION AND COLLECTION OF DOCUMENTS
4.1. In general:
(a) Prior to conducting a search for responsive ESI, regardless of the search methodologies to be employed, the Parties shall meet and confer regarding the search methodologies the Producing Party proposes to employ to identify responsive Documents, and make such disclosures regarding their proposed search methodology that will permit the Requesting Party to evaluate the proposed methodology and enable meaningful meet and confers, such as the type of methodology to be used (e.g., targeted collections, Search Terms, TAR or other advanced analytics, manual review, etc.) and the Custodial Data Sources and Non-Custodial Data Sources to which they will be applied, along with information sufficient for the Requesting Party to evaluate the reasonableness of the agreed Custodians whose Documents are to be searched, and the Custodial Data Sources and Non-Custodial Data Sources to be searched.
(b) Any search methodology used by a Producing Party to search for responsive Documents will search any associated attachments and embedded files.
4.2. To the extent a Producing Party elects to use Search Terms and/or Boolean search strings or other limiters, including, by way of example only, date ranges and Email domains in Metadata fields, as a means of limiting the volume of information to be analyzed for responsiveness, prior to conducting any such searches or applying other limiters, that Producing Party shall disclose the following to the Requesting Party:
(a) The agreed Custodians whose ESI will be searched using Search Terms, and a description of the Custodial Data Sources and Non-Custodial Data Sources against which the limiters and/or Search Terms shall be run; and
(b) An initial list of the limiters and/or Search Terms the Producing Party intends to use.
4.3. Upon receipt of the proposed Search Terms and disclosures set forth above, the Requesting Party and Producing Party shall meet and confer to attempt to reach agreement on the Search Terms and/or limiters to be used to identify responsive Documents. To facilitate such meet and confers, the Producing Party shall discuss, among other matters, and to the extent not protected by the attorney-client privilege or work-product doctrine, whether the terms include relevant terminology, or nicknames, code words, euphemisms, acronyms, jargon, slang, terms of art, Email addresses, and other language likely to be contained in responsive Documents; appropriate synonyms for proposed Search Terms and variations on search syntax, for example, using wildcard characters, truncation, stem words, fuzzy logic and proximity terms to address over and under inclusiveness; and whether any appropriate testing and quality control measures were conducted or will be conducted to evaluate the sufficiency of the Search Terms. The Requesting Party and Producing Party hereby agree that negotiations regarding Search Terms and other limiters are intended to be a cooperative and iterative process, involving a good faith exchange of information and proposals to facilitate the negotiations.
4.4. The Parties agree that the mere fact that a document has a hit or is captured by the application of any agreed upon search terms does not mean that such document is necessarily responsive to any propounded discovery request or is otherwise relevant to this litigation. Notwithstanding this provision, the Parties preserve all rights to challenge the sufficiency of any production based on the failure to produce responsive Documents that hit or are captured by any agree upon search terms.
4.5. If a Producing Party elects to use Technology Assisted Review (“TAR”) or similar advanced analytics as a means of including or excluding Documents to be analyzed for responsiveness or of culling or otherwise limiting the volume of information to be analyzed for responsiveness, prior to use of such tool the Requesting Party and Producing Party shall meet and confer as to (1) the Custodial Data Sources and Non-Custodial Data Sources against which TAR will be run; (2) the TAR or advanced analytics vendor and methodology being deployed; (3) the quality control measures used to validate the results of the TAR methodology or similar advanced analytics; (4) any Documents, Document types, file types or other categories that the Producing Party proposes to exclude from the TAR process and the method of identifying such Documents to be excluded; and (5) other disclosures that are reasonably necessary for the Requesting Party to evaluate the proposed TAR process. To the extent a Producing Party proposes to use Search Terms to pre-cull ESI prior to application of TAR and/or advanced analytics, prior to doing so, they shall meet-and-confer with the Requesting Party regarding whether pre-culling is appropriate and if so, how it is to be applied. If the Requesting Party and Producing Party are unable to agree on the TAR and/or advanced analytics technology and methods being proposed after meeting and conferring in good faith, the Requesting Party and Producing Party shall notify the Court of their unresolved dispute(s) and seek resolution by the Court.
V. PRODUCTION FORMAT
5.1. Format Guidelines. The Parties shall produce ESI and Hard Copy Documents according to the specifications provided in this Protocol. The Parties agree to meet and confer in good faith if any of the technological specifications set forth in this Protocol result in unforeseen technological issues. The Parties agree not to degrade the searchability of Documents as part of the Document production process.
5.2. Images. All responsive ESI and Hard Copy Documents, except ESI which is produced in Native Format pursuant to Paragraph 5.3, shall be produced as black and white, singlepage, 300 DPI, Group IV TIFF files. The Receiving Party may request color images of other Documents where color is reasonably necessary to their comprehension or use, and such request shall not unreasonably be denied. However, wholesale or categorial requests (i.e., produce all Word documents in color) are deemed invalid. Each Document's original orientation should be maintained (i.e., portrait-to-portrait and landscape-to-landscape). TIFF image files should be provided in a separate folder and the number of TIFF files per folder should be limited to 1,000 files. To the extent that a Document or ESI contains tracked changes or comments, the Document or ESI should be imaged showing tracked changes and comments.
ORDER
5.3. Documents To Be Produced Natively. A Producing Party shall produce Microsoft Excel and other spreadsheet files, including comma or tab delimited text files, and audio and video files in Native Format except where such files are redacted in accordance with this Protocol. Other Document types which may be difficult or costly to be accurately imaged, such as large Microsoft Power Point files or corrupted documents, may be selected to be produced natively at the Producing Party's discretion. The production of Structured Data, which the Parties may, from time to time, agree is also to be produced in its Native Format, is governed by Paragraph 5.9.
The production Load Files shall contain a link to the produced Native Format files. Each electronic file produced in Native Format shall be assigned a unique Bates number as set forth in Paragraph 5.7, and for each a single page placeholder TIFF image branded with this unique Bates number, the phrase “PRODUCED IN NATIVE FORMAT” (or similar language), and any corresponding confidentiality designations will be produced. No Party may attach to any pleading or any correspondence addressed to the Court, Special Master, or any adverse or third Party, or submit as an exhibit at a deposition or any other judicial proceeding, a copy of any produced Native Format Document without ensuring that either the corresponding placeholder slip sheet is attached to the Document or the corresponding Bates number and confidentiality legend, as designated by the Producing Party, appears on the Document.
Responsive ESI produced in Native Format shall be produced with all required Metadata contained in or associated with that file to the extent reasonably feasible. Extracted text taken from natively produced files will be provided at a Document level. There will be one text file per Document, using the same name as the beginning Bates number of the Document. The Extracted Text file for a Document will reside in a folder titled “TEXT.” The text file associated with any redacted Document will exclude redacted text (i.e., the Producing Party will OCR the redacted image and replace the original Extracted Text).
If production in Native Format is necessary to decipher the meaning, context, or content of a Document produced only in TIFF format, the Producing Party shall honor a reasonable and particularized written request made in good faith and shall produce the Document in Native Format within 14 days, unless such production would reveal material redacted in accordance with Paragraphs 5.11 or 5.26.
Where the Document produced only in TIFF format that is requested in Native Format contains redactions, the Producing Party will, if reasonable, produce a version of the Native Format Document containing redactions. If the Producing Party is unable to do so, the Parties will meet and confer to resolve the issue.
5.4. Extracted Text and OCR. Each Document, whether produced in TIFF or Native Format, and whether originally existing as ESI or as a Hard Copy Document, shall be produced with Extracted Text or OCR, as described herein:
(a) Extracted Text (Emails, Unredacted Native ESI, and Natively Redacted Spreadsheets) All Email, un-redacted ESI, and natively redacted spreadsheets produced as Native files, should be provided with complete Document-level Extracted Text files. Extracted text shall include all comments, track changes, user-modifiable fields, speaker's notes, author comments, contacts, calendars, and all other hidden content including, but not limited to, worksheets, columns, rows, etc.
(b) OCR (Redacted Native ESI, Hard Copy Documents) In the event a Document, other than natively redacted spreadsheets, contains text that is to be redacted, OCR text files should be provided for the entire Document after the redaction has been applied. Document level OCR text files should also be provided for Hard Copy Documents, and PDFs that do not have embedded text, and images that the Producing Party determines are likely to contain text. To the extent that a Document is redacted as allowed under Paragraphs 5.11 or 5.26, the text files shall not contain the text of the redacted portions, but shall indicate where the redactions were made, e.g., with the notation “REDACTED.”
(c) Format of Extracted Text and OCR. The extracted full text and/or OCR text for all deliverables should be in separate Document-level, UTF-8 TXT files provided in a separate folder. The number of TXT files per folder should be limited to 1,000 files.
5.5. Bloomberg Chat Data. For ESI that is Bloomberg chat data, ESI should be provided in the original Native Bloomberg TXT format typically packaged with a .tgz container file, or, if the chat data that existed at the time this Action was filed was not maintained in that format at the time of filing, or was previously produced in connection with a regulatory production and the chat data was not preserved in Native Bloomberg TXT format, the Parties shall produce chat data with the following Metadata fields to the extent they exist:
(a) RoomID/ PCHAT number/ INTMSGID;
(b) Conversation start;
(c) Conversation end time;
(d) Duration of chat;
(e) Participant count/ Number of participants.
Further, the directory structure for chat data must contain the following:
(a) + arbitraryparentname;
(b) + TXT;
(c) + mmddyy-mmddyy1;
(d) + prefix.IB.mmddyy-mmddyy.txt2;
(e) + prefix.IB. mmddyy-mmddyy.txt.att.tar.gz.
5.6. Instant Messages and Social Media. To the extent Instant Messages are produced, other than Bloomberg chats discussed in Section 5.5 above, a Party shall produce such Messages such that individual Messages are grouped into threads (i.e., continuous conversations between one or more individuals) in a manner to allow for the full context of the responsive components of the conversations to be visible. For any Instant Messages, other than Bloomberg chats discussed in Section 5.5 above, or social media postings produced, this metadata will be produced, to the extent reasonably available: BegBates, EndBates, Custodian(s), Instant Message Type, (e.g., Slack, Google Talk, etc.) or Social Media Platform (e.g., Facebook, Instagram, Twitter, etc.), Instant Message Participants (to the extent available: senders, recipients, subscribers, or other participants in a group message or channel), Subject (Subject or name of the messaging thread or topic), Channel (to the extent available: name of persistent messaging group or chat room).
5.7. Unique IDs. Each image should have a unique filename, which corresponds to the Bates number of that page. Bates numbering should contain no special characters or blank spaces, be zero-padded, and be numerically sequential within a given Document. If a Bates number or set of Bates numbers is skipped, the skipped number, or set of numbers, should be noted with a placeholder. All attachments to Documents will be assigned Bates numbers that directly follow the Bates numbers on the Documents to which they were attached. Bates numbers will be unique across the entire production and prefixes will be consistent across all Documents a Party produces in this Action.
5.8. Mobile and Handheld Device Documents and Data. The Parties shall meet and confer to address the collection and production format of any responsive, Documents and data contained on any mobile or handheld device.
5.9. Databases, Structured, Aggregated, or Application Data. To the extent a response to discovery requires production of discoverable electronic information contained in a database (including Microsoft Access files) and the responsive data cannot reasonably be produced in either Excel or .csv format, in advance of producing such information, the Parties agree to meet and confer regarding the format of the production (e.g., commercial database, or some other agreed-upon format). To the extent available, the Producing Party will produce a data dictionary for the fields provided and will answer reasonable requests to explain any codes or abbreviations contained in the Structured Data through a meet-and-confer process.
5.10. Document Families. A Document should be produced together with its entire Document Family, and the Parties agree that if any part of an Email or its attachments is responsive, the entire Email and attachments will be produced unless excepted herein. The relationship between attachments, enclosures, embedded files, and/or exhibits to any parent Document shall be preserved. The child-Document should be consecutively produced immediately after the parent-Document. Each Document shall be produced with the production number for the first and last page of that Document in the “BegBates” and “EndBates” fields of the data Load File and with the “BegAttach” and “EndAttach” fields listing the production number for the first and last page in the Document Family.
If a member of a Document Family that has otherwise been determined to be responsive cannot technically be processed (e.g., unsupported file format, file corruption, inaccessible password-protected Document), those technical problems shall be identified and disclosed to the Requesting Party by production of a Bates numbered slipsheet that states “Technical issue-file cannot be processed” (or similar language). The associated Metadata for the file with the technical problem shall be produced if technically possible and reasonable. A Requesting Party may thereafter raise with the Producing Party any questions or concerns, and the Parties shall meet and confer to attempt to resolve any issues.
If a Party claims that a member of a Document Family that contains a responsive Document is privileged, it may be redacted or produced as a Bates-labeled slip sheet in place of the attachment, along with all non-privileged Metadata for the attachment as specified in Appendix A, except that the full text Metadata field need not be populated. The TIFF slip sheet for each withheld attachment will state “Family Member Withheld as Privileged” (or similar language), along with the specific privilege asserted (e.g., “Attorney Client”). The Parties agree to meet and confer in good faith to attempt to resolve any disputes arising under this provision.
In the event that a Party initially withholds a Document that forms a part of a Document Family, and that Document is later produced either by decision of the Party or by order of the Court, the Party shall produce that Document such that the slipsheet previously replacing that Document in the production is easily identifiable. Where possible, the Producing Party shall provide updated Metadata associating the previously withheld Document with its Document Family.
5.11. Metadata. The Metadata fields detailed in Appendix A will be produced for each Document to the extent that such information is reasonably available and extractable, except that if a field contains privileged information, that information may be redacted. For redacted or privileged documents only the BegBates, EndBates, BegAttach, EndAttach, Custodian, Duplicate Custodian, Confidentiality, Page Count, Production Volume, Redaction and Full Text Metadata fields need to be produced. For the avoidance of doubt, the Full Text Metadata field will contain only non-redacted content for redacted documents and no content for fully withheld documents.
5.12. Exception Files. The parties will use reasonable efforts to ensure that Documents that present imaging or form production problems (including encrypted and/or password protected files) are successfully processed for review and production.
5.13. Embedded Files. Non-substantive automatically-generated embedded files, such as logos, embedded, non-substantive formatting files such as .ole or .dll formats, zero-byte files, widgets, or confidentiality legends need not be produced as separate attachments.
5.14. Hyperlinked Files. A Producing Party does not need to produce hyperlinks to publicly available internet sources. To the extent that hyperlinks refer to other non-publicly available sources, the Parties agree to meet and confer concerning the production of hyperlinks contained in responsive Documents.
5.15. Compressed and Container Files. Compression file types (e.g., .CAB, .GZ, .RAR. .ZIP), shall be decompressed to ensure that a compressed file within a compressed file is decompressed into the lowest possible compression resulting in individual folders and/or files. Original compression files and container files need not be produced, provided the responsive content files are produced in accordance with the specifications of this ESI Protocol.
5.16. Load File Formats. Documents should be provided with an Opticon CrossReference File and Concordance data load file using standard Concordance delimiters:
(a) Hard Copy Documents.
(i) Field Separator: ASCII character 20 (“¶”);
(ii) Quote: ASCII character 254 (“p”); and
(iii) New Line: ASCII character 174 (“®”).
Concordance-compatible image and data load files should be provided in a “Data” folder.
(b) ESI.
(i) Text Delimiter AKA “Quote” - “”, Hex (FE), Unicode (U+00FE), Decimal (254) 2;
(ii) Field Separator: AKA “Comma” - “”, Hex (14), ASCII character 20 (“¶”);
(ii) Unicode (U+0014), Decimal (20);
(iv) Quote: ASCII character 254 (“p”); and
(v) New Line: ASCII character 174 (“®”).
All rows will contain the same number of delimiters and fields. The multi-value field delimiter must be consistent across all fields. For example, if the CC field contains semi-colons between Email addresses, the tag field should also contain semi-colons. Concordance-compatible image and data load files should be provided in a “Data” folder. Parties have the option to exchange sample load files. If this exchange occurs, the Requesting Party will have fourteen (14) days to respond with Load File change requests. Nothing in this Order will limit the Parties from discussing Load File changes throughout the course of the Action.
5.17. De-Duplication. The Parties shall use reasonable, good faith efforts to avoid the production of duplicate Documents. The Parties agree that production of ESI Documents globally de-duplicated to remove exact duplicate Documents shall constitute production of Documents as maintained in the ordinary course of business provided that a single copy of the responsive Document or record is produced. Duplicates shall be defined as ESI with exact MD5 or SHA-1 hash values. Where any such Documents have attachments, hash values must be identical for both the Document-plus-attachment(s) (including associated Metadata) as well as for any attachment (including associated Metadata) standing alone. For Email the MD5 hash values should be calculated at the family level and include the full body of any and all attachments as well as the “TO,” “FROM,” “CC,” “BCC,” “Date Sent,” “Date Received,” “Date Created,” and “Date Modified” values in that calculation. When the Producing Party is globally de-duplicating across Custodians, the Producing Party shall populate a field of Metadata that identifies each Custodian who had a copy of the produced Document (the “Duplicate Custodian” field) in addition to a separate field of data identifying the Custodian whose Document is produced. A Producing Party may use other reasonable methods to remove duplicate Documents from production provided that method is disclosed to the Requesting Party.
5.18. De-NISTing. Each party will use reasonable efforts to filter out common system files and application executable files. Non-user generated files defined by the NIST library (http://www.nsrl.nist.gov/) need not be produced. Additional culling of system files based on file extension may include, but are not limited to: WINNT, LOGS, DRVS, C++ Program File (c), C++ Builder 6 (cpp), Channel Definition Format (cdf), Creatures Object Sources (cos), Dictionary file (dic), Executable (exe), Hypertext Cascading Style Sheet (css), JavaScript Source Code (js), Label Pro Data File (IPD), Office Data File (NICK), Office Profile Settings (ops), Outlook Rules Wizard File (rwz), Scrap Object, System File (dll), temporary files (tmp), Windows Error Dump (dmp), Windows Media Player Skin Package (wmz), Windows NT/2000 Event View Log file (evt), Python Script files (.py, .pyc, .pud, .pyw), and Program Installers. Parties need not produce non-human readable E-Documents, except upon a showing of good cause by the Requesting Party.
5.19. Email Threading. The Parties are permitted to use commercially reasonable Email threading tools to remove Emails and their attachments where the contents of the Email and its attachments are wholly included within another Email and its attachments that are not removed. A metadata field that indicates all participants in the Email and any suppressed Emails in the thread will be produced. Upon request a Party will disclose the tool used for Email threading and reasonable information regarding its functioning. Further, the Parties are permitted to make particularized requests for metadata in a suppressed Email.
5.20. Production of Transcripts. If deposition or other transcripts are responsive, they may be produced like any other Document, except that a Requesting Party may request production in another format and the Parties agree to meet and confer to discuss an alternative format for producing the transcripts.
5.21. Custodian or Originating Source. The Custodian or originating source shall be identified in the Custodian field of the database Load Files, as provided in Appendix A. Documents found in the possession of a natural person (or on a natural person's hardware or storage Media) shall be produced in such fashion as to identify the natural person. Documents found in the possession of a department, group, entity, or other common facility (e.g., office, file room, archive, network storage, file share, back-up, hard drive, etc.) shall be produced in such a fashion as to identify the department, group, entity, or facility. A Producing Party shall use a uniform description of a particular agreed Custodian across productions.
5.22. Non-English Documents. To the extent that Documents are produced that contain languages other than English, in whole or in part, the Producing Party shall produce each such Document, along with its Metadata, in the original language or languages in which it was written and collected. Such Documents should be delivered with the correct encoding to enable the preservation of the Document's original language.
5.23. Time and Date. The time zone in which the data was processed will be disclosed by the Producing Party. When processing unprocessed ESI, UTC should be selected as the time zone. When a Metadata field includes a date and/or time, it shall be provided in the following format: mm/dd/yyyy HH:mm:ss. ESI items shall be processed so as to maintain the date/time in the Document's Metadata as it was last saved by the Custodian or end user, not the date of collection or processing (i.e., shall force off Auto Date).
5.24. Production Method. The Producing Party shall produce Document images, Native Format files, Load Files, and Metadata by secure FTP link provided via Email at the time a production letter is Emailed, unless the Parties agree otherwise. Productions made via FTP or electronic transfer are not required to be supplemented with hard Media containing the same Documents. On the occasion in which a particular production is of a size that would make sending it via FTP link impractical, the Parties may agree to send encrypted physical Media such as a Hard Drive or USB (“Production Media”). Each piece of Production Media shall include a unique identifying label including the following information: (a) name of the Action and its case number; (b) name of the Producing Party, (c) the date of the production, (d) production volume number, and (e) the Bates number ranges of the Documents in that production. To the extent that the Production Media includes any confidential information protected under any protective order entered by the Court, the label on such Production Media shall indicate that the Production Media includes information so designated. Further, any replacement Production Media shall crossreference the original Production Media, clearly identify that it is a replacement, and crossreference the Bates number range that is being replaced. All Production Media that is capable of write protection should be write-protected before production. All Production Media may be encrypted, with the Producing Party to provide a decryption key, under separate cover, at the time of production.
5.25. Encrypted Data. To the extent a production is encrypted before it is produced, the Producing Party shall contemporaneously transmit the credentials necessary to decrypt the data.
5.26. Redacted Documents. To the extent a Responsive Document requires redaction (e.g., on the basis of privilege, work product protection, or such other categories of information that the Parties may agree can be withheld at a later date), the Parties agree that the Native version need not be produced, full text may be replaced with OCR text that excludes the redacted material, and Metadata fields may be excluded if they contain material redacted for privilege. The image file should show the word “Redacted” and the reason for the redaction, such as “Redacted -Privileged as Attorney Client Privilege” (or similar language), where applicable and a production Load File field should be populated to indicate the Document contains a redaction. Metadata fields may be withheld if they contain information that may be redacted pursuant to this Paragraph. A Party may not redact any Document on the basis of non-responsiveness.
If a Document to be produced in Native Format contains information that may be redacted pursuant to this Paragraph, the Document may be produced by producing the Document in Native Format with the redactable information withheld, as long as the Document indicates that it has been redacted. The Parties agree to meet and confer in good faith to attempt to resolve any dispute arising under this Paragraph.
VI. MISCELLANEOUS PROVISIONS
6.1 Third Party Documents. A Party that issues a non-party subpoena (“Issuing Party”) shall include a copy of this Protocol with the subpoena and state that the Parties to the Action have requested that third parties produce Documents in accordance with the specifications set forth herein. The Issuing Party shall promptly notify the other Parties when it receives non-party productions and shall provide copies of such productions to the other parties in the format in which they were received from the third-party within five (5) days. In the event that the format of a third-party production does not conform with the specifications set forth herein, the Parties shall meet and confer regarding the format of production to Requesting Parties. Nothing in this Protocol is intended to or should be interpreted as narrowing, expanding, or otherwise affecting the rights of the Parties or third Parties to object to a subpoena.
6.2 Effect of Protocol. The Parties' agreement to this Protocol is without prejudice to the right of any Party to seek an order from this Court to rescind or amend this Protocol for good cause shown. Nothing in this Protocol abridges the rights of any person to seek judicial review or to pursue other appropriate judicial action with respect to any discovery ruling made by the Court in this Action.
6.3 Effect on Discovery. Nothing herein constitutes an admission by any Party that any particular category of discovery is appropriate in this matter or that there exists producible ESI.
VII. NON-WAIVER
The Parties agree that neither the stipulation to the entry of this Order by a defendant in this Action nor the production of Documents or ESI by any Party in this Action pursuant to this Order shall be a waiver of any claim or defense in this Action.
The Parties and their attorneys do not intend by this Order to waive or forfeit their rights to any protection or privilege, including the attorney-client privilege, the work-product doctrine, United States or foreign bank disclosure or foreign bank secrecy laws or regulations, United States or foreign data privacy laws, foreign blocking statutes, or any other applicable United States or foreign statute, law, regulation, court order, restriction, privilege, or immunity from disclosure that may be applicable. All Parties preserve all of these protections and privileges, including but not limited to their attorney-client privileges, work product protection, and other privileges. The Parties and their attorneys are not waiving or forfeiting, and specifically reserve, the right to object to any discovery request on any grounds, including but not limited to relevance, undue burden, proportionality, and inaccessibility. Further, nothing in this Order shall be construed to affect the admissibility of Documents and ESI. All objections to the discoverability or admissibility of any Documents and ESI are preserved and may be asserted at any time.
SO ORDERED.
APPENDIX A
1. COVER LETTER
A cover letter shall be included with each production and shall include information sufficient to identify all accompanying Media (e.g., hard drive, thumb drive, DVD, CD, secure FTP), shall identify each production on such Media by assigning a Production Volume name or number, shall indicate confidentiality, and shall include the Bates range for the Documents produced in each volume.
2. PRODUCTION LOAD FILES
There will be two Load Files accompanying all productions of paper Documents and ESI:
• The first will be a Metadata import file with a .DAT file extension, in Concordance format delimited file, including ASCII 020 and 254 delimiters for column break and text qualifier, and new line as ASCII 174, that contains the agreed upon Metadata fields in UTF-8 encoding. The first line shall be the header with field names, and each subsequent line shall contain the fielded data for each Document.
• The second will be an image load file containing the Document break instructions for the image base. The acceptable formats for the cross-reference files are .lfp and .opt.
3. ESI (AND PAPER TO THE EXTENT APPLICABLE) PRODUCTION METADATA FIELDS
• BegBates: Beginning Bates Number.
• EndBates: Ending Bates Number.
• BegAttach: Beginning Bates number of the first Document in attachment range in a Document Family range. Documents that are part of Document families, i.e., containing parents and attachments should receive a value.
• EndAttach: Ending Bates number of the last Document in attachment range in a
Document Family range. Documents that are part of Document Families, containing parents or attachments, should receive a value.
• AttachmentCount: Populated for Email parent records and indicates the number of attachments that constitute the whole family.
• Custodian: Name of the Custodian of the Document produced, to the extent reasonable and technically available. If the Document was collected from a centralized source, the Custodian field shall reference that centralized source.
• Duplicate Custodian: Identifying any and all unique custodians in whose files an exact duplicate Document was found.
• FileName: Filename of the original source ESI.
• NativeLink: Relative path and filename to the produced Native Format file.
• Subject: Subject line extracted from an Email message or calendar entry.
• Title: Title field extracted from the Metadata of a non-Email Document.
• Importance: Email importance flag, to the extent reasonably and technically available.
• Author: Author field extracted from the Metadata of a non-Email Document.
• From: From field extracted from an Email message.
• To: To or Recipient field extracted from an Email message.
• Cc: CC or Carbon Copy field extracted from an Email message.
• BCC: BCC or Blind Carbon Copy field extracted from an Email message.
• DateSent: Sent date of an Email message (mm/dd/yyyy format).
• TimeSent: Time of an Email message (hh:mm:ss format).
• DateReceived: Received date of an Email message (mm/dd/yyyy format).
• TimeReceived: Received time of an Email message (hh:mm:ss format).
• DateCreated: Creation date of a file (mm/dd/yyyy format).
• TimeCreated: Creation time of a file (hh:mm:ss format).
• DateLastModified: Last modification date and time (mm/dd/yyyy format).
• TimeLastModified: Last modification time (hh:mm:ss format).
• File Extension: File extension of Document (.msg, .doc, .xls, etc.).
• Full Text: Relative file path to the full text/OCR File.
• Confidentiality: “Confidential” or “Highly Confidential,” if a Document has been so designated under the Protective Order; otherwise, blank.
• Message-ID: The Outlook Message ID assigned by the Outlook mail server, if applicable.
• Hash Value: MD5 or SHA-1 hash of the Document.
• Page Count: The number of pages in the file.
• Production Volume: Production volume name or number.
• Redaction: Field indicating whether a document contains redactions.
** As it relates to the Custodian and Duplicate Custodian metadata fields above, the Producing Party reserves the right to produce in single field including all custodians (e.g., Custodian) since the metadata may already be exported and logged as such.
** Same is true with all Date and Time fields. These fields can be provided in separate fields or be combined into a single field as long as the required information is produced in the load file.