Opinion
MDL 3084 CRB
05-03-2024
IN RE UBER TECHNOLOGIES, INC. PASSENGER SEXUAL ASSAULT LITIGATION This Document Relates to ALL ACTIONS
ORDER GOVERNING THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION AND HARD COPY DOCUMENTS
Hon. Lisa J. Cisneros
1. PURPOSE
This Order Governing the Production of Electronically Stored Information and Hard Copy Documents (“ESI Order”) will govern discovery of electronically stored information and any hard copy documents in this Litigation as a supplement to the Federal Rules of Civil Procedure and this District's Guidelines for the Discovery of Electronically Stored Information (“ESI Guidelines)and Checklist for Rule 26(f) Meet and Confer Regarding Electronically Stored Information (“ESI Checklist”), and any other applicable orders and rules. Nothing in this Order is intended to expand or limit the obligations of a party or non-party as otherwise required by law. “This Litigation” includes all actions currently in IN RE: UBER TECHNOLOGIES, INC. PASSENGER SEXUAL ASSAULT LITIGATION, or hereafter added or transferred to MDL No. 3084, and all actions later remanded to their respective transferor courts.
https://www.cand.uscourts.gov/filelibrary/1117/ESI_Guidelines-12-1-2015.pdf.
https://www.casd.uscourts.gov/judges/leshner/docs/Electronically%20Stored%20Information %20Checklist.pdf.
2. DEFINITIONS
a) “And” and “or” shall be construed conjunctively or disjunctively as necessary to make their use inclusive rather than exclusive, e.g., “and” shall be construed to mean “and/or.”
b) “Defendant” or “Defendants” means the named defendants in the above-captioned matter, as well as any later added defendants. “Uber Defendants” means Uber Technologies, Inc., Rasier, LLC, and Rasier-CA, LLC.
c) “Document” is defined to be synonymous in meaning and equal in scope to the usage of this term in Rules 26 and 34 of the Federal Rules of Civil Procedure and shall include Hard-Copy Documents and ESI.
d) “Electronically stored information” or “ESI,” as used herein has the same meaning as in Federal Rules of Civil Procedure 26 and 34. For avoidance of doubt, ESI includes Documents existing in electronic form at the time of collection, including but not limited to: email messages (including all active messages and archived or otherwise stored messages), other electronic messaging platforms (such as instant messaging, chat messaging, app-based messaging, Slack messaging, and collaboration tool messaging), calendar items, address book entries, voicemails, recorded phone calls, memoranda, letters, reports, presentations, spreadsheets, databases, charts, handwritten notes, and any storage media.
e) “Hard-Copy Document” means Documents existing in paper form at the time of collection.
f) “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.
g) “Metadata” means: (i) structured, i.e., fielded, information embedded in a native file which describes, inter alia, the characteristics, origins, usage, and/or validity of the electronic file; (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, (iii) information, such as Bates numbers, created during the course of processing documents or ESI for production, and (iv) information collected during the course of collecting documents or ESI, such as the name of the media device, or the custodian or non-custodial data source from which it was collected.
h) “Attachment(s)” shall be interpreted broadly and includes, e.g., traditional email attachments and documents embedded in other documents (e.g., Excel files embedded in PowerPoint files) as well as modern attachments, pointers, internal or non-public documents linked, hyperlinked, stubbed or otherwise pointed to within or as part of other ESI (including but not limited to email, messages, comments or posts, or other documents). This definition does not obligate Uber to produce the contemporaneous version of Google Drive documents referenced by URL or hyperlinks if no existing technology makes it feasible to do so.
i) “Party” or “Parties” means any person, business organization, or legal entity that is a named plaintiff or defendant in any filed case consolidated under this MDL.
j) “Non-Party” or “Non-Parties” means any person, business, organization, or legal entity that is not a named plaintiff or defendant in any filed case consolidated under this MDL.
k) “Requesting Party” means the Party requesting the production of Documents.
l) “Producing Party” means the Party that may be producing Documents in response to a request by the Requesting Party.
m) “Protective Order” means the Protective Order issued by the Court in MDL No. 3084, and filed on the docket 3:23-md-03084-CRB at ECF No. 176.
n) “Searchable Text” means the native text extracted from an Electronic Document and any Optical Character Recognition text (“OCR text”) generated from a Hard-Copy Document or electronic image.
o) “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.
p) “Optical Character Recognition” or “OCR” means the process of recognizing, and creating a file containing, visible text within an image.
q) “Load File(s)” means electronic files provided with a production set of documents and images used to load that production set into a receiving party's document review platform and correlate its data within that platform.
r) “Include” and “Including” shall be construed to mean “include but not be limited to” and “including, but not limited to.”
s) “Plaintiff” refers to the named plaintiffs in the above-captioned matter, as well as any later added plaintiffs.
t) “Parent-child” shall be construed to mean the association between an attachment and its parent Document in a Document family.
u) Any reference to the singular shall also be deemed to refer to the plural, and vice-versa.
3. COOPERATION
The Parties are aware of the importance the Court places on cooperation and commit to cooperate in good faith throughout this Litigation consistent with this Court's Guidelines for the Discovery of ESI and this Court's Rules of Professional Conduct.
Nothing in this Protocol shall be deemed to constitute a waiver of any objections a Producing Party may have with respect to any discovery demand.
Nothing in this Protocol shall be deemed to prevent a Party from seeking the Court's intervention, pursuant to the Court's Standing Order for discovery disputes, with respect to any issues that may arise regarding the application of this ESI Order to a Document request issued to a Producing Party and/or any responses or objections a Producing Party may have with respect to any such request, if the Parties are unable to resolve any such issues, responses, or objections without the Court's assistance. Likewise, nothing in this ESI Order shall be deemed to prevent any other Party from opposing relief sought from the Court.
4. LIAISON
The Parties will identify Discovery Liaisons to each other for purposes of meeting and conferring on ESI topics. Counsel for Plaintiffs and Uber shall designate their respective ESI liaisons within 30 days of entry of this order, and thereafter the designation may be updated by counsel via email with 10 days' notice.
5. PRESERVATION
The Parties' preservation obligations are currently set forth in PTO No. 2. Nothing contained herein shall be construed to abrogate, minimize, or expand the preservation requirements described in PTO No. 2 or a later entered order of the Court.
6. INADVERTENT PRODUCTION OF PRIVILEGED MATERIAL
The inadvertent production of information subject to protection by the attorney-client privilege, the work-product, joint defense, or other similar doctrine, or by another legal privilege protecting information from discovery, shall be addressed pursuant to Section 11 of the Protective Order and the Privileged Materials Order issued by the Court and filed on the docket 3:23-md-03084 at ECF No. 366.
7. IDENTIFICATION OF CUSTODIAL AND NON-CUSTODIAL DOCUMENTS AND ESI
The Parties will disclose a preliminary list of (a) custodians likely to possess potentially relevant information, (b) custodial and non-custodial data sources likely to contain potentially relevant Documents and ESI, and (c) third parties likely to possess potentially relevant information in accordance with Fed.R.Civ.P. 26(f), this District's ESI Guidelines, any applicable Orders entered including PTO No. 5 and participate in Rule 26(f) discussions guided by this District's ESI Checklist.
Once discovery requests have been propounded under Fed.R.Civ.P. 34, the parties will further meet and confer regarding those custodians and custodial and non-custodial data sources from which Documents and ESI will be collected for review for potential production in this litigation.
The custodian and data source exchanges will include brief explanations of the rationale for their selections; for example, for custodians, their current job titles, dates of employment, and descriptions of their work, and for data sources, location information and description.
As stated in PTO No. 2, sources of ESI may include, without limitation, for both corporate and personal accounts: (1) email systems; (2) mobile device data; (3) text and messaging applications (e.g., iMessage, WhatsApp, Facebook Messenger, SnapChat, WeChat, Signal, Wickr, Telegram, uChat, and HipChat); (4) Workplace collaboration tools and chat applications (i.e., Slack and Microsoft Teams); (5) social media accounts; (6) unstructured data (e.g., documents created by commonly used Microsoft Office programs and Google programs); (7) structured data (e.g., information stored in structured databases like Salesforce and Basecamp); (8) wearable devices (e.g., data from watches or tags); (9) backup media (e.g., data from tapes, discs, or cloud accounts); (10) external storage media (e.g., portable hard drives or flash drives); (11) voicemail systems; and (12) video surveillance systems.
The Parties agree that if the Producing Party determines a source is not “reasonably accessible” pursuant to Fed.R.Civ.P. 26(b) during the search and collection process it will provide sufficient information regarding the accessibility of the source to enable the Parties to confer in good faith within seven (7) days of this determination about whether such source or Document will be produced or methods by which the information can be produced. If the Parties disagree as to the accessibility of the source after a good faith meet and confer, the Party seeking discovery from the source may submit the issue to the Court or its designee in accordance with the Court's procedures. The Parties agree to take any unresolved disputes on same promptly to the Court or its designee.
8. SEARCH QUERIES AND METHODOLOGIES
Pursuant to Fed.R.Civ.P. 26(f), and the ESI Guidelines, the Parties will meet and confer, as appropriate, to discuss certain aspects of the discovery process, for example, the number of custodians, the identity of those custodians, keywords to be used as part of culling files, collection from non-custodial files, file types, date ranges, validation procedures and random sampling, technology assisted review (“TAR”) or other appropriate advanced technology. This process will be iterative. For the avoidance of doubt, Plaintiffs will disclose to Defendants their processes for preservation and collection of documents, including the sources from which such documents will be collected, and the parameters for search and review of documents. Plaintiffs will meet and confer with Defendants about these issues.
a) Use of TAR by the Uber Defendants.
1. Overview.
As part of document review, the Uber Defendants intend to use TAR methodology known as TAR 2.0, which utilizes continuous active learning to classify and prioritize documents for attorneys to review. Specifically, the Uber Defendants intend to use Relativity Active Learning (“RAL”) on a Relativity Server 12.1.537.3 platform provided by their vendor Lighthouse. Commonly, a TAR 2.0 methodology begins with ingesting document population into the TAR 2.0 software where the algorithm learns to distinguish relevant from non-relevant documents through attorney review of documents. The TAR 2.0 algorithm prioritizes the documents in the review queue from most to least likely to be responsive. Attorney reviewers then review documents the TAR 2.0 model has prioritized as most likely to be responsive in descending order from most to least likely to be responsive. As the review continues and reviewers code documents, the TAR 2.0 model continues to learn and prioritize likely responsive documents until a stopping point is reached and a validation is conducted.
2. TAR and Search Terms
TAR processing may be ‘stacked' with the application of search terms. If search terms are to be applied, the parties shall meet and confer regarding the proposed search terms. The search terms may be agreed by the parties, or certain search terms may be ordered by the Court if the parties are unable to reach an agreement.
3. Stopping Criteria
i. Once two or more consecutive review batches sequentially populated by the highest-ranking uncoded documents remaining in the project in order from highest to lowest scores and containing a total of at least 1,000 documents are found to contain 10% or fewer documents marked responsive, Defendants will pause the review and turn to validation. Defendants may extend the review past this point if they believe sufficient thoroughness has not been achieved. Defendants do not intend for the relevant batches to include index health documents.
ii. The responsiveness rate will be calculated only over documents drawn directly into the prioritized review queue due to their own predicted relevance score (“primary documents”). It will not include family members of these primary documents, even if said family members are reviewed at the same time as said primary documents.
4. Validation
i. A Validation Sample consisting of three strata will be drawn from the entire TAR population. 500 documents will be drawn, at random, from documents coded responsive prior to validation; 500 documents will be drawn, at random, from documents coded nonresponsive prior to validation; and 2,000 documents will be drawn, at random, from documents not coded prior to validation (i.e., the null set). This will ensure an estimate of Prevalence with a margin of error no larger than 2.1% at 95% confidence. As for all statistical estimates, the precise margin of error can only be known after the sample is reviewed.
ii. For the purpose of determining which sampling stratum a document falls in, only the direct coding status of that document will be considered, not any coding it may inherit due membership in a family. For instance, a document coded non-responsive will fall in the non-responsive stratum, even if it is a family member of a document coded as responsive.
iii. The 3,000 documents will be reviewed de novo for responsiveness by Defendants, interleaved in random order, with no indication to the reviewer of their prior coding status.
iv. Recall and Prevalence will be calculated using the following quantities:
1. the number of documents in the TAR population that were coded
responsive prior to validation;
2. the number of documents sampled from (1) that are coded responsive in the de novo review;
3. the number of documents in the TAR population that were coded nonresponsive prior to validation;
4. the number of documents sampled from (3) that are coded responsive in the de novo review;
5. the number of responsive documents in the TAR population that were not coded prior to validation; and,
6. the number of documents from (5) that are coded responsive in the de novo review.
v. Recall = [(1)÷500*(2)] ÷ [(1)÷500*(2) + (3)÷500x(4) + (5) ÷2000 (6)|
vi. Prevalence = [(1)÷500x(2) + (3)÷500x(4) + (5)÷2000x(6)] ÷ [(1) + (3) + (5)|
vii. The Uber Defendants will disclose the calculated Recall and Prevalence and the input quantities used to calculate Recall and Prevalence.
viii. Plaintiffs' Designated Reviewers shall have the opportunity to review all non-privileged documents in the Validation Sample, without any knowledge of how any individual documents were coded by the Uber Defendants, in order to perform a blind comparison of the provided Recall and Prevalence estimates.
ix. This review may take place (a) at such location or locations mutually agreed by the Parties, on a date and time to be agreed to by the Parties, or (b) via a secure web-based viewer on a date and time to be agreed to by the Parties. Any documents coded Not Responsive by the Uber Defendants to which Plaintiffs' Designated Reviewers are provided access as part of this review are provided for the limited and sole purpose of raising and resolving disagreements, if any, regarding the coding calls made by the Uber Defendants. Any such disagreements shall be recorded on a TAR Protocol Classification Dispute Log (the “Log”), which shall be in a form agreed upon by the Parties. Once Plaintiffs' Designated Reviewers complete their review of the Validation Sample, the Parties shall meet and confer to resolve any differences in coding designation. If resolution cannot be reached, the issue shall be submitted to the Court for resolution.
x. If the recall estimate derived from the validation sample is below 80%, or if the documents designated responsive in the part of the sample drawn from the null set indicate that the TAR tool's model of Responsiveness was too limited, e.g., if the responsive documents in the Validation Sample included novel or significant documents, then Plaintiffs and Defendants will discuss remedial action to locate an adequate proportion of the remaining relevant documents in the null set, including but not limited to: continuing reviewing from the prioritized queue; and training alternative predictive models focused on the relevant documents found in the elusion test. After Defendants disclose these metrics, the parties may meet and confer to discuss questions and issues relating to the TAR process. If the validation protocol leads to an estimate lower than 80%, or even lower than 70%, this lower recall estimate does not necessarily indicate that a review is inadequate. Nor does a recall in the range of 70% to 80% necessarily indicate that a review is adequate; the final determination of the quality of the review will depend on the quantity and nature of the documents that were missed by the review process.
b) Disclosures
1. Once the TAR process is complete in addition to above, Defendants intend to disclose various metrics regarding the TAR 2.0 methodology utilized, including the following: (i) the total TAR population, (ii) the total population produced, (iii) the total population not produced, (iv) the total population not reviewed, (v) the size of the validation set used to verify the TAR 2.0 results, and (vi) a summary of the validation process. The summary of the validation process will include the following figures from the Validation Sample: (a) the number of documents within the sample that were previously coded relevant; (b) the number of documents within the sample that were previously coded not relevant; (c) the number of unreviewed documents within the sample. The summary of the validation process will also include the number of actual responsive documents identified in (a), (b), and (c) during the validation process. Defendants will also produce all non-privileged responsive documents in the Validation Sample. After Defendants disclose these metrics, the parties may meet and confer to discuss questions and issues relating to the TAR process.
c) Key Word Search.
1. If the Producing Party is identifying responsive ESI, which is not already known to be responsive, using search terms, the Parties will meet and confer about search terms in English and any other languages used in the Producing Party's documents. Before implementing search terms, the Producing Party will disclose information and meet and confer within seven days of the ESI Protocol being entered, or on a date agreed upon by the parties, regarding the search platform to be used, a list of search terms in the exact form that they will be applied (i.e., as adapted to the operators and syntax of the search platform), significant or common misspellings of the listed search terms in the collection to be searched, including any search term variants identifiable through a Relativity dictionary search with the fuzziness level set to 3, any date filters, or other culling methods. At the same time the Producing Party discloses the search terms, unless the Receiving Party agrees to waive or delay disclosure, the Producing Party shall disclose the unique hits, hits with families, and the total number of documents hit. Within seven days after the Producing Party discloses its list of search terms and related information, the Receiving Party may propose additional or different search terms or culling parameters and may propose a limited number of custodians for whom, across their email and other messages, the Receiving Party requests that no search term pre-culling be used prior to TAR 2.0. At the same time the Receiving Party discloses its proposals, it may request that the Producing Party provide hit reports, and the Producing Party must promptly respond with that information but may also provide other information. The parties must confer within 14 days after the Receiving Party's proposal to resolve any disputes about the search terms. The parties may agree to extend this deadline, but no extension may be more than 14 days without leave of the Court. Use of search terms shall be validated post-review using comparable methodology and metrics to those set out in Disclosures (a) and (c) above.
2. Nothing in this ESI Order may be construed or interpreted as precluding a Producing Party from performing a review to determine if documents captured by search terms are in fact responsive to the Requesting Party's discovery requests. Similarly, nothing in this ESI Order may be construed or interpreted as precluding a Producing Party from performing, by any means, a privilege review of documents determined to be responsive. Further, nothing in this ESI Order requires the production of documents captured by any search term that are not relevant and responsive to the Requesting Party's request, that are privileged, or that are otherwise protected from disclosure.
9. END-TO-END VALIDATION OF DEFENDANTS' SEARCH METHODOLOGY AND RESULTS
The Parties shall participate in an iterative and cooperative approach in which the Parties will meet and confer regarding reasonable and appropriate validation procedures and random sampling of Defendants' Documents (both of relevant and non-relevant sets and of the entire collection against which search terms were run or TAR or other identification or classification methodology was used), in order to establish that an appropriate level of end-to-end recall (the percentage of responsive Documents in the initial collection before any search terms or TAR or manual review was applied which were classified as responsive after Defendants search, TAR and review processes) has been achieved and ensure that the Defendants' search, classification and review methodology was effective and that a reasonable percentage of responsive ESI was identified as responsively being omitted.
10. UNSEARCHABLE DOCUMENTS
Documents which are reasonably believed to be responsive and for which text-based search technologies are fundamentally ineffective, such as images, video, certain spreadsheets, certain hard copy documents, certain documents from noncustodial sources, or certain foreign language documents where the Parties do not have suitable search terms in such language, must be reviewed without culling by search terms, predictive coding, or other technologies that rely primarily on text within the document. Prior to the production of such unsearchable items, the Producing Party may conduct a page-by-page review for responsiveness, confidentiality, privilege, and other protections.
11. SYSTEM FILES
Each Party will use its best efforts to filter out common system files and application executable files using the national software reference library (“NSRL”) NIST hash set list. The Parties shall meet and confer on methods for excluding any other non-substantive files and folders that are reasonably identified as system files and not likely to contain user-created files or content.
12. DEDUPLICATION
Each Party shall make reasonable efforts to globally de-duplicate exact duplicate Documents within the Party's ESI data set across all custodians at the family level. Documents should be de-duplicated at the family level using MD5 hash values, or SHA-1 hash values, or the SourceHash value generated by Google for Google Drive documents, or comparable industry standard hash algorithm disclosed by such Party. “Exact duplicate” shall mean bit-for-bit identity of the Document content with exact Hash Value matches. Parties shall disclose the methodology, e.g., industry standard program (including any variable parameters), being used to calculate the hash values for individual emails and email families. Any such methodology must ensure that an email that includes content in the “BCC” or other blind copy field shall not be treated as a duplicate of any otherwise identical email that does not include content in the “BCC” or other blind copy field. Emails shall be deduplicated at the family level and standalone documents shall not be deduplicated against attachments. The names of all custodians and non-custodial sources who were in possession of a document prior to deduplication will be populated in the “ALL CUSTODIAN” metadata field, separated by semi-colons, in addition to a separate field of data identifying the custodian whose Document is produced; such de-duplicated Documents shall be deemed produced from the custodial files of each such identified custodian for all purposes in this litigation, including for use at deposition and trial. The original file paths of a Document prior to deduplication will be populated in the “ALL FILE PATHS” metadata field, separated by semicolons, in the order corresponding to the order of names in ALL CUSTODIANS. Hard-Copy Documents shall not be eliminated as duplicates of ESI.
13. NO EMAIL THREADING
No email may be withheld from production because it is included in whole or in part in a more inclusive email, although Parties may use email threading for their own internal review and other internal processes.
14. SOURCE CODE
The Parties will meet and confer to address the production and/or inspection of source code and enter into a separate order governing the same.
15. PRODUCTION FORMATS
The Parties agree to produce documents and data in the formats described in Appendix 1 to this ESI Order. If particular Documents or categories of Documents identified in response to document requests warrant a different format, the Parties will cooperate to arrange for the mutually acceptable production of such documents. The Parties further agree not to degrade the searchability of Documents as part of the Document production process. Google file types, e.g., Google docs, sheets and slides, shall be produced as their Microsoft equivalents, i.e., Google docs files shall be produced as Microsoft Word files, and Google sheets shall be produced as Microsoft Excel Files, etc.
16. PHASING
Once the Parties begin propounding discovery requests pursuant to Fed.R.Civ.P. 34, the Parties agree to meet and confer regarding appropriate phasing for the production of ESI to the degree efficient and feasible.
17. CLOUD STORED DOCUMENTS
a. Metadata Preserved.
Uber shall preserve the metadata relationship between email messages with links to files on Google Drive to the extent feasible with existing technology. Uber shall preserve and produce (including, if necessary, as custom fields) all metadata collected with respect to all cloud-stored documents. That includes, but is not limited to, all metadata output by Google Vault when exporting a matter. Thus, the metadata exported from Google Vault pertaining to each document shall be preserved and produced as metadata for the same document within the load file of any production containing any such document.
b. Hyperlinked/URL-Referenced Documents.
Producing party shall make all reasonable efforts to maintain and preserve the relationship between any message or email and any cloud-hosted document hyperlinked or referenced within the message or email. Thus, for instance, where a collected email links to or references by URL a document on Google Drive (or housed within Google vault,) the metadata for that message or email shall include the URLs and Google Document ID of all hyperlinked documents.
c. Contemporaneous Versions of Hyperlinked/URL-Referenced Documents.
Uber shall produce, to the extent feasible on an automated, scalable basis with existing technology, the contemporaneous document version, i.e., the document version likely present at the time an email or message was sent, of Google Drive documents referenced by URL or hyperlinks therein. For hyperlinked Google Workspace data archived using Google Vault, Uber is not required to produce the contemporaneous document version at the time the email or message was sent, as this is not possible through an automated process with existing technology. However, Plaintiffs may identify up to 200 hyperlinks for which they seek the contemporaneous referenced document even though the email or message has been archived with Google Vault. Uber shall identify and produce the likely contemporaneous versions that Plaintiffs have requested. The scope of this production does not exempt Uber from any obligation that it preserve historic versions or revision history of any document referenced by URL or hyperlink.
18. PLAINTIFFS' PRODUCTION OF ESI AND CASE SPECIFIC DOCUMENTS
This provision does not apply to Plaintiff's Fact Sheet (PFS) and/or documents produced with the PFS as they are the subject of a separate Order. The parties shall further agree to confer concerning the production format (e.g., pdfs) and associated matters (e.g., hosting platform to the extent not already negotiated) for Plaintiff specific documents. Any Plaintiffs who are selected to proceed forward towards a trial date will meet and confer with Defendants about the technical aspects of these Plaintiffs' production of non-privileged documents as appropriate during the course of those Plaintiffs' specific Rule 26 formal discovery. This provision shall not limit any Plaintiff's obligation to produce discovery that the Court or Federal Rules of Civil Procedure may require before being selected for trial. Plaintiffs will meet and confer with Defendants about these issues after such formal discovery is propounded. No other provision of the ESI Order will apply to Plaintiffs but for the terms set forth herein. Nothing herein shall limit Defendants' rights to seek discovery from Plaintiffs.
19. MISCELLANEOUS PROVISIONS
a) Translations Of Produced Materials. The Producing Party has no obligation to create a translation of the Documents or any portion thereof. For any foreign-language documents responsive to document requests that a Party reasonably knows as the result of a reasonable investigation have been translated into the English language using human translators or through machine translation in the ordinary course of business or for its own purposes, except to the extent such translation is protected by attorney-client or work-product privileges, the Producing Party shall produce the translation of the original document with the original. The Parties will meet and confer as necessary concerning procedures for using translations at depositions and at trial. In the event the Parties cannot reach agreement, the matter may be submitted to the Court for determination.
b) Non-Party Documents. A Party that issues a Non-Party subpoena (“Issuing Party”)
shall include a copy of this Order with the subpoena and state that (1) the subpoenaed Non-Party should produce Documents in response to the subpoena to all Parties; and (2) the Parties to this Litigation have requested that Non-Parties produce Documents in accordance with the specifications set forth herein. If a subpoenaed Non-Party produces Documents to the Issuing Party but does not produce those Documents to other Parties, the Issuing Party shall produce such Documents to those other Parties within 14 days of receiving the Documents, except where the Documents are to be used in a deposition, in which case the Issuing Party shall produce such Documents to all other Parties no later than three (3) days prior to the deposition, or as soon as reasonably practicable if such production occurs thereafter. Nothing in this Order is intended or may be interpreted to narrow, expand, or otherwise affect the rights of the Parties or Third Parties to object to a subpoena. If a Non-Party production is not Bates-stamped, the Parties will meet and confer to agree upon a format for designating the documents with a unique Bates Number prefix.
c) Lost, Destroyed, or Irretrievable ESI. If a Producing Party learns that responsive ESI that once existed was lost, destroyed, or is no longer retrievable as a result of acts or circumstances not occurring in the ordinary course of business, the Producing Party shall explain where and when the responsive ESI was last retrievable in its original format and to disclose the circumstances surrounding the change in status of that responsive ESI, whether that information is available from other sources, whether any backup or copy of such original responsive ESI exists.
d) Re-productions. Notwithstanding any provisions to the contrary, re-production of discrete sets of documents from another litigation, arbitration, government inquiry, or other matter may be re-produced in the same manner and form as originally produced in the other matter, provided however that a party may, upon reasonable request and for good cause shown, reproduce documents in a different format. This provision does not waive the right of a party to object to any requests for reproduction of production files from another litigation, arbitration, government inquiry, or other matter.
e) Protective Order. Documents produced by the Parties are subject to the terms of the Protective Order [Dkt. 176] entered in this Litigation.
f) Production Log. With each production of documents, the producing party shall produce a log that contains the following information: (i) Production volume number; (ii) Date of the production; (iii) Bates range for the production; (iv) Sources of information from which the documents are being produced (e.g., names of custodians or noncustodial sources); (v) Other relevant information about the production (i.e., whether the production is an overlay file for a previous production). The log should be supplemented with each production such that each version contains all previous productions on the log along with the new production information.
g) Modification. This ESI Order may be modified by a Stipulated Order of the Parties or by the Court for good cause shown.
h) Good Faith. The Parties will act in good faith as required by law and use these procedures to identify and reduce the potential for disputes.
i) Continuing Obligations. The parties will continue to meet and confer regarding discovery issues as reasonably necessary and appropriate. This Order does not address or resolve any objections to the Parties' respective discovery requests.
j) Reservation of Rights. Nothing in this ESI Order may be construed or interpreted to waive any objections to the production, discoverability, admissibility, or confidentiality of documents and ESI, or independently move for an appropriate protective order pursuant to the Federal Rules of Civil Procedure. Nothing in this Order shall be deemed to be a waiver of any Party's right to reasonably seek agreement from the other Parties, or a Court ruling, to modify proposed or previously agreed to search terms, techniques, tools, or any other provision set forth in this Order for good cause.
IT IS ORDERED that the forgoing Order is approved.
APPENDIX 1: PRODUCTION FORMAT
1. Production Components. Except as otherwise provided below, ESI must be produced in accordance with the following specifications:
a) an ASCII delimited data file (.DAT) using standard delimiters;
b) an image load file (.OPT) that can be loaded into commercially acceptable production software (e.g. Concordance);
c) single page black-and-white TIFF or color JPEG images, or native files with single page placeholder TIFF images, depending on the applicable production format for each type of file;
d) and document level .TXT files for all documents containing extracted full text or OCR text.
e) Family relationships (be that email, messaging applications, or otherwise) will be maintained in production. Attachments (as previously defined herein) should be consecutively produced with their parent (in the case of hyperlinked attachments, only one copy of the attachment will be produced with all agreed-upon metadata referencing the attachment to any linked emails). Objects, documents or files embedded in documents, such as OLE embedded objects (embedded MS Office files, etc.), or images, etc., embedded in RTF files, shall be extracted as separate files and treated as attachments to the parent document. Chats from programs like Slack and HipChat should be produced in families by channel or private message.
f) If a particular document warrants a different production format, the Parties will cooperate in good faith to arrange for a mutually acceptable production format.
2. Production Media and Access Controls. Productions must be encrypted and produced through secure electronic means, such as secure file sharing methods (e.g. FTP), or on CD, DVD, flash drive or external hard drive (“Production Media”). Nothing in this ESI Order will preclude or impair any and all protections provided the Parties by any Protective Order(s) agreed and entered into by the Parties. Parties will use best efforts to avoid the unnecessary copying or transmittal of produced documents. If questions arise, the Parties will meet and confer to ensure security concerns are addressed prior to the exchange of any documents.
3. Data Load Files/Image Load Files. Each TIFF in a production must be referenced in the corresponding image load file. 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 file(s) in the production. The total number of pages referenced in a production's image load file should match the total number of TIFF files in the production. The total number of documents in a production should match the total number of records in the data load file. Load files must not vary in format or structure within a production, or from one production to another except by agreement of the Parties.
4. Metadata Fields. Defendants shall use methods of collection and processing that preserve the integrity of document metadata, and of parent-child and family group relationships such as the association between attachments and parent documents, or between embedded documents and their parents, or between documents, including, but not limited to, emails (e.g., Outlook, Gmail) or messaging or communication posts (e.g., Slack, Teams, Google Hangouts, Google Chat), with document stubs or links or pointers to internal or non-public (e.g., Google Workspace, Zendesk) documents and those stubbed or internal or non-public documents so linked Documents containing hidden URLs, e.g., an email containing a link where the text of the link is not the URL (for example, a link with the displayed text “Please review this article” where the URL of the link, e.g., https://somesite.com/somearticle.html/” is not itself the display text of the link) should be processed such that all hidden URLs are included in the extracted text.
The metadata fields detailed in Appendix 2 should be produced for each Document to the extent that such information is available or, in the case of metadata created during processing such as Bates numbers created 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.
5. TIFFs. Unless excepted below, single page, black and white, Group IV TIFFs should be provided, at least 300 dots per inch (dpi) for all documents. If the receiving party is not satisfied with the quality of TIFFs for particular images, it may request the producing party to produce those images in native format. In addition, the Parties shall take reasonable efforts to process word processing documents (e.g., MS Word) with track changes and/or comments unhidden on the TIFF image.
6. Bates Numbering. All produced ESI must be assigned a unique Bates number that is sequential within a given document and across the production sets, along with a confidentiality designation. 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. Original document orientation should be maintained (i.e., portrait to portrait and landscape to landscape). Bates numbering should be a consistent length across the production, contain no special characters, and be numerically sequential within a given document. The Bates Numbers in the load file must match the corresponding documents' beginning Bates numbers in the data load file. If a Bates number or set of Bates numbers is skipped, the skipped number or set of numbers should be noted with a placeholder. Attachments to documents will be assigned Bates numbers that directly follow the Bates numbers on the documents to which they were attached. In addition, wherever possible, each image will have its assigned Bates number electronically “burned” onto the image.
7. Color. Any ESI that is not an email communication and contains color will be processed as a JPEG file at 300 DPI. Where the receiving party reasonably suspects that particular email communications contain color that is necessary to determine the meaning of the communication, the receiving party may make reasonable and proportionate requests for particular email communications to be produced in color. The Parties agree to meet and confer regarding such requests as appropriate. A Party making such a request shall make the request by individual Bates number(s) and shall limit requests made pursuant to this paragraph to a reasonable number of documents.
8. Text Files. A single text file shall be provided for each document. The text file name shall be the same as the Bates number of the first page of the document with the document extension “.txt” suffixed. Files names shall not have any special characters or embedded spaces. Electronic text must be extracted directly from the native electronic file unless the document requires redaction and is not a spreadsheet, is an image file, or is any other native electronic file that does not contain text to extract (e.g., non-searchable PDFs). In these instances, and in the case of imaged hard-copy documents, a text file shall be created using OCR and shall be produced in lieu of extracted text. Text shall be provided in UTF-8 format. Extracted text shall be generated with commercially acceptable technology set to include all comments, revisions, tracked changes, speaker's notes and text from documents with comments or tracked changes, and hidden and very hidden worksheets, slides, columns and rows as well as all URLs. When possible, the text of native files should be extracted directly from the native file. Parties will use their best efforts to OCR foreign language documents using the appropriate setting for those languages, although that may require additional process. Text files will not contain the redacted portions of the documents. A commercially acceptable technology for optical character recognition (“OCR”) should be used with the highest quality setting during processing for all scanned, hard copy documents, and for documents with redactions other than Excel files and other spreadsheets which shall be redacted in native format. Text extracted from emails should include the following header information where available: (1) the individuals to whom the communication was directed (“To”), (2) the author of the email communication (“From”), (3) who was copied and blind copied on such email (“CC” and “BCC”), (4) the subject line of the email (“RE” or “Subject”), and (5) the date and time of the email. Text extracted from emails and other documents should also be generated with commercially acceptable technology set to include the text of any URLs or links, e.g., if an email contains a link like “Please review these rules” where “these rules” is a URL to a destination such as “https://www.cand.uscourts.gov/notices/newnotice- proposed-modifications-to-civil-local-rules/”, then the extracted text must include the URL as well as the linked text “these rules.”
9. Native files. All spreadsheet files (e.g., Microsoft Excel or Google Sheets), as well audio and video files, shall be produced as native files with TIFF placeholder images. Spreadsheet files requiring redaction, including Microsoft Excel files, will be redacted within the native file, and the redacted native file will be produced as provided herein. Moreover, to the extent a spreadsheet file is a Google Sheet, this will be provided in a Microsoft Excel format. To the extent that they are produced in this Litigation, audio, video, and multi-media files will be produced in native format. The Parties will meet and confer on the production of other file types, such as proprietary files, etc. Native files will be produced with a link in the NATIVEFILEPATH field, along with extracted text (where extracted text is available) and applicable metadata fields set forth in Appendix 2. A Bates numbered TIFF placeholder indicating that the document was provided in native format must accompany every native file. Where redaction makes production of nativeformat files other than spreadsheets or presentations infeasible, the Parties will confer to determine a reasonably usable form for the production, but spreadsheets shall presumptively be redacted in native, and presentations presumptively redacted in image form, in these cases without the need for further conferring.
10. Production Format for Hard Copy Documents. In scanning paper documents, documents are to be produced as they are kept. For documents found in folders or other containers with labels, tabs, or other identifying information, such labels and tabs shall be scanned where practicable. Pages with Post-It notes shall be scanned both with and without the Post-it, with the image of the page with the Post-it preceding the image of the page without the Post-It. Hard copy documents will be made text searchable. The producing party will use best efforts to unitize documents (i.e., distinct documents should not be merged into a single record, and a single document should not be split into multiple records), and maintain document relationships, i.e., attachment status. Original document orientation (i.e., portrait v. landscape) should be maintained.
11. Confidentiality Designation. All images will be stamped with the appropriate confidentiality designations in accordance with the Protective Order entered in this Litigation. Each document produced in native format will have its confidentiality designation identified in the filename of the native file and indicated on its corresponding TIFF placeholder.
12. Databases and Other Data Sources. The Parties shall meet and confer regarding the production and format and scope of relevant structured data or aggregated or threaded data source or otherwise maintained by an application (e.g., Microsoft Teams, Slack, Microsoft Access, SharePoint, Oracle, Salesforce, ACT!, or any other messaging or proprietary databases or services) in order to ensure that any information produced is reasonably usable by the Receiving Party and that its production does not impose an undue burden on the Producing Party. The Parties will cooperate in the exchange of sufficient information concerning such databases to facilitate discussions on the production of responsive information, including available data fields/objects and schema. To the extent a Party is constrained from producing responsive ESI because of a third-party license or because software necessary to view the ESI is hardware dependent, the Parties shall meet and confer to minimize any expense or burden associated with the production of such documents in an acceptable format, including issues as may arise with respect to obtaining access to any such software and operating manuals.
13. Embedded Objects. OLE embedded objects (embedded MS Office files, etc.) shall be extracted as separate files and treated as attachments to the parent document. Images embedded in emails shall not be produced separately. Parties agree non-substantive embedded objects, including, but not limited to, logos, icons, emoticons, and footers need not be produced as separate documents by a Producing Party (i.e., such embedded objects will be produced within the document itself, rather than as separate documents). Embedded files, except for images and nonsubstantive embedded objects (including but not limited to, logos, icons, emoticons), are to be produced as family groups. Embedded files should be assigned Bates numbers that directly follow the Bates numbers on the documents within which they are embedded.
14. Production of Family Groups and Relationships. If any member of a family group is produced, all members of that group must also be produced or else logged as privileged, and no such member shall be withheld from production as a duplicate.
15. Dynamic Fields. Documents with dynamic fields for file names, dates, and times will be imaged to show the field code (e.g., “[FILENAME]”) where possible, rather than the values for such fields existing at the time the file is processed.
16. Time Zone. All provided metadata pertaining to dates and times will be standardized to UTC.
17. Redactions. Other than as permitted by this Order or the Protective Order entered in this Action, no redactions for relevance may be made within a produced document or ESI item. The Parties agree to meet and confer on a case-by-case basis if a Party believes there is a good faith basis to permit limited redaction by agreement of the Parties of highly sensitive, non-relevant information within a Document that contains other relevant information. Any redactions shall be clearly indicated on the face of the document, with each redacted portion of the document stating that it has been redacted and the type of the redaction, and a metadata field shall indicate that the document contains redactions and the type of the redaction (e.g., “Privacy” or “Privilege”). Where a responsive document contains both redacted and non-redacted content, the Parties shall produce the non-redacted portions of the document and the OCR text corresponding to the non-redacted portions.
18. Spreadsheets. Spreadsheet files requiring redaction, including without limitation Microsoft Excel files, will be redacted and produced natively.
19. Other Documents. All images of redacted native files shall be processed to show and reveal all comments, revision marks, speaker notes, or other user-entered data which are visible in any view of the exported document. Where possible, any occurrences of date/time auto-field items, including in headers and footers, will be removed and replaced with the term AUTODATE to prevent the current date from being printed. Email header information (e.g. date, subject line, etc.) should not be redacted unless it is independently privileged. The production of a document in a redacted form does not affect the Parties' obligation to timely assert and substantiate the assertion of privilege over the content in a privilege log. The Parties shall honor reasonable requests for the production of particular redacted documents in other formats where the image is not reasonably usable.
20. Color. Redacted versions of Documents that would have been produced in color in their un-redacted form shall be produced in color as detailed herein.
21. Exception Files. The Parties will use reasonable efforts and standard industry practices to address Documents that present imaging or form production problems (including encrypted and/or protected files identified during the processing of ESI) (“Exception Files”). The Parties will meet and confer regarding procedures that will be used to identify, access, and process Exception Files. In the event that the Parties cannot reach agreement on the handling of Exception Files through the meet and confer process, the matter may be submitted to the Court for determination.
22. Mobile and Handheld Device Documents and Data. If responsive and unique data that can reasonably be extracted and produced in the formats described herein is identified on a mobile or handheld device, that data shall be produced in accordance with the generic provisions of this protocol. To the extent that responsive data identified on a mobile or handheld device is not susceptible to normal production protocols, the Parties will meet and confer to address the identification, production, and production format of any responsive documents and data contained on any mobile or handheld device.
23. Parent-child relationships. If responsive, Parent-child relationships that have been maintained in the ordinary course of business shall be preserved for both ESI and hard copy Documents. For example, for electronic production of a hard copy folder with Documents contained in the folder, the cover/title of the folder shall be produced first, with all contents of the folder in sequential Document order behind the containing folder. For email families, the parentchild relationships (the association between emails and attachments) should be preserved, i.e., email attachments should be consecutively produced with the parent email record (in the case of hyperlinked attachments, only one copy of the attachment will be produced with all agreed-upon metadata referencing the attachment to any linked emails).
24. Encrypted or Password-Protected ESI. For any ESI that is produced in encrypted format or is password-protected, the producing party will provide the propounding party a means to gain access to those native files (for example, by supplying passwords).
APPENDIX 2 - METADATA FIELDS
Field
Definition
Doc Type
ALLCUSTODIAN
Name(s) of person(s) or other data source (nonhuman) from where documents/files are produced. Where redundant names occur, individuals should be distinguished by an initial which is kept constant throughout productions (e.g., Smith, John A. and Smith, John B.)
All
BEGBATES
Beginning Bates Number (production number)
All
ENDBATES
Ending Bates Number (production number)
All
PGCOUNT
Number of pages in the document
All
FILESIZE
File Size
All
APPLICAT
Commonly associated application for the specified file type.
All
FILEPATH
Original file/path of the location where the item was located at the time of collection, where applicable. This should include location, and, for edocuments and eattachments, file name, and file extension. Folder names and path should be included, and, for emails and attachments collected from a container such as a .pst, the full folder path within the container. Any container names should be included in the path.
E-document, Email, excluding cloud-based documents. Equivalent fields are included in the Google Drive & Linked Documents & Google Mail section below.
FILENAME
Original file name at the point of collection
E-Document.
Field
Definition
Doc Type
NATIVEFILELINK
For documents provided in native format only
All
TEXTPATH
File path for OCR or Extracted Text files
All
LINKBEGBATES
One-to-many field used to identify the beginning Bates value for any Google Drive linked documents referenced within a given Gmail document
Gmail documents containing linked Google Drive documents
LINKSOURCEBEGBATES
One-to-many field used to identify the beginning Bates value for any source Gmail documents linking to a given Google Drive document
Google Drive documents linked to Gmail documents
MSGID
Email system identifier assigned by the host email system. This value is extracted from parent message during processing
FROM
Sender
TO
Recipient
CC
Additional Recipients
BCC
Blind Additional Recipients
SUBJECT
Subject line of e-mail
PARENTMSGID
Where the item is an email which is a REPLY or FORWARD, the ConversationID of the original email which was REPLIED to or FORWARDED
CONVERSATIONID
Email thread identifier
ATTACHBATES
Bates number from the first page of each attachment
BEGATTACH
First Bates number of family range (i.e. Bates number of the first page of the parent e-mail or document)
E-mail, E-Documents
Field
Definition
Doc Type
ENDATTACH
Last Bates number of family range (i.e. Bates number of the last page of the last attachment or, if no attachments, the document itself)
E-mail, E-documents
ATTACHCOUNT
Number of attachments to an e-mail
ATTACHNAMES
Names of each individual Attachment, separated by semi-colons
E-mail, E-documents
DATESENT (mm/dd/yyyy hh:mm:ss AM)
Date Sent
DATERCVD (mm/dd/yyyy hh:mm:ss AM)
Date Received
SORTDATE (mm/dd/yyyy hh:mm:ss AM)
Date of the parent e-mail or document
E-mail and documents
HASHVALUE
MD5 hash value
All
TITLE
Internal document property
E-document
AUTHOR
Internal document property
E-document
DATECRTD (mm/dd/yyyy hh:mm:ss AM)
Creation Date
E-document
LAST MODIFIED BY
Last person who modified (saved) a document
E-document
LASTMODD (mm/dd/yyyy hh:mm:ss AM)
Last Modified Date
E-document
HiddenContent
Denotes if file contains hidden content. Format: Yes/No value.
Loose files and attachments.
Field
Definition
Doc Type
DocumentType
Descriptor for the type of document: “Edocument” for electronic documents not attached to e-mails; “E-mail” for all e-mails; “E-attachment” for files that were attachments to e-mails; “Physical” for hard copy physical documents that have been scanned and converted to an electronic image; and “Messaging Application” for all Messages related to Messaging Applications e.g., Slack, HipChat, uChat, WhatsApp, Google Chat, and GroupMe.
All
Importance
High Importance - indicates Priority E-mail message.
Redacted
Descriptor for documents that have been redacted. “Yes” for redacted documents; “No” for unredacted documents.
All
ProdVol
Name of media that data was produced on.
All
Confidentiality
Confidentiality level if assigned pursuant to any applicable Protective Order or stipulation.
All
Other Custodians
Custodians of all duplicate documents. Multiple values separated by semi-colons.
Field
Definition
Doc Type
Duplicate Filepaths
Original file/path of the locations where the unproduced duplicate items were located at the time of collection. This should include location, and, for edocuments and eattachments, file name, and file extension. Folder names and path should be included, and, for emails and attachments collected from a container such as a .pst, the full folder path within the container. Any container names should be included in the path. Multiple values should be separated by semi-colons.
E-Document
LINKGOOGLEDRIVEDO CUMENTIDS
One-to-many field containing the Google DocumentIDs for any Google Drive linked documents referenced within a given Gmail document.
Gmail documents containing linked Google Drive documents
Field
Definition
Doc Type
THREADID
ThreadID for non-email threaded communications
Non-email threaded communications
Google Drive & Linked Documents & Google Mail
Field Definition Doc Type DocID Document ID obtained from Google Vault metadata at time of document collection. Google Drive & Linked Documents #Author The email address of the person who owns the file in Drive. For a shared drive file, it shows the shared drive name. Google Drive & Linked Documents Collaborators The accounts and groups that have direct permission to edit the file or add comments and users with indirect access to the file. Google Drive & Linked Documents 37 Viewers The accounts and groups that have direct permission to view the file and users with indirect access to the file. Google Drive & Linked Documents #DateCreated The date a Google file was created in Drive. For nonGoogle files, usually the date the file was uploaded to Drive. Google Drive & Linked Documents #Date Modified The date the file was last modified. Google Drive & Linked Documents #Title The filename as maintained in the Google Drive and which was originally assigned. Google Drive & Linked Documents Filename The file name that correlates to the metadata with the file in the export ZIP file. Google Drive & Linked Documents FileSize The size of the file in bytes. Google Drive & Linked Documents Hash The MD5 hash of the file. Google Drive & Linked Documents SlideRecording Metadata about recordings. Google Drive & Linked Documents 38 ClientSideEncrypted Indicates whether the file was encrypted in the Google Workspace using client-side encryption. Google Drive & Linked Documents DocumentType The file type for Google files. Google Drive & Linked Documents SharedDriveID The identifier of the shared drive that contains the file Google Drive & Linked Documents DocParentID Unique identifier for page the site is a part of. Google Drive & Linked Documents SiteTitle The name of the Sites page. Google Drive & Linked Documents Other Includes users for whom Vault could not determine permission levels at the time of export. Google Drive & Linked Documents SourceHash A unique hash value for each version of a file. Google Drive & Linked Documents DocumentType The file type for Google files. Google Drive & Linked Documents 39 PublishedURL Metadata included with Google Drive exports for sites, including the address of the published page. Google Drive & Linked Documents SiteTitle Metadata included with Google Drive exports for sites, including the name of the page. Google Drive & Linked Documents LabelName Google Drive labels and fields. Google Drive & Linked Documents Account The email address of the collected email account associated with the single custodian whose data survives the de-duplication process. Google Emails & Chat (Messages) GmailMessageld A unique message ID used to manage specific messages with the Gmail API. Google Emails & Chat (Messages) Labels Labels applied to the message by Gmail or the user. Google Emails & Chat (Messages) DriveUrl Published URL corresponding to the Google Drive document. Google Emails & Chat (Messages) #DateFirstMessageSent The timestamp for when the first message in a conversation was sent Google Emails & Chat (Messages) 40 #DateLastMessageReceived The timestamp for when the last message in a conversation was received. Google Emails & Chat (Messages) #DateFirstMessageReceived The timestamp for when the first message in a conversation was received. Google Emails & Chat (Messages) #DateLastMessageReceived The timestamp for when the last message in a conversation was received. Google Emails & Chat (Messages) RoomID The space, group chat, or DM identifier that the message belongs to. Google Emails & Chat (Messages) Participants The email addresses of all users who participated in the conversation. Google Emails & Chat (Messages) RoomName The value of the space, Group Chat, list of accounts that participated. Google Emails & Chat (Messages) ConversationType The message type. Google Emails & Chat (Messages) ParticipantPhoneNumbers The phone numbers of the participants. Google Voice 41 OwnerPhoneNumbers The value includes multiple phone numbers when the user's number changed. Google Voice MissingGoogleDriveAttach ments This field will include the URL for each Google Drive document(s) referenced by link(s) within the Google Email, which linked document(s) was/were not produced with metadata link(s) to the Google Email document. Google Emails, which contain links to Google Drive documents. Non-Contemporaneous In the event a Google Email has any link(s) to Google Drive documents that are dated later than the sent date of the Google Email document, a “Y” will be provided; “N” otherwise. Google Emails