Elawyers Elawyers
Ohio| Change

IN RE SYNGENTA MASS TORT ACTIONS, 3:16-cv-0255-DRH. (2016)

Court: District Court, S.D. Illinois Number: infdco20160819899 Visitors: 15
Filed: Aug. 18, 2016
Latest Update: Aug. 18, 2016
Summary: ORDER APPROVING ESI PROTOCOL DAVID R. HERNDON , District Judge . Pursuant to the provisions of Rule 34 of the Federal Rules of Civil Procedure permitting the parties to specify the form or forms in which documents are to be produced, the Protocol sets forth the specifications that shall govern document production during discovery in the above-captioned proceedings (the "Action"). A. SCOPE 1. This Protocol governs the collection and production of electronically-stored information ("ES
More

ORDER APPROVING ESI PROTOCOL

Pursuant to the provisions of Rule 34 of the Federal Rules of Civil Procedure permitting the parties to specify the form or forms in which documents are to be produced, the Protocol sets forth the specifications that shall govern document production during discovery in the above-captioned proceedings (the "Action").

A. SCOPE

1. This Protocol governs the collection and production of electronically-stored information ("ESI") and hard copy documents (collectively "Data"), which are to be produced electronically in the Action.

2. Nothing herein shall alter the parties' respective responsibility to comply with the applicable Federal Rules of Civil Procedure and any applicable Local Rules regarding the collection or production of Data. To the extent additional obligations, restrictions, or rights not addressed in this Protocol arise under the Federal Rules of Civil Procedure or other applicable law or rules, that law or rule shall govern.

3. The parties incorporate the provisions of the Protective Order entered in this Action. For the avoidance of doubt, nothing herein shall contradict the parties' rights and obligations with respect to any information designated as Confidential or Highly Confidential pursuant to the Protective Order.

4. Nothing in this Protocol establishes any agreement regarding the subject matter or scope of discovery in this Action, or the relevance, authenticity or admissibility of any Data.

5. Nothing in this Protocol shall be interpreted to require production of Data protected from disclosure by the attorney-client privilege, work-product doctrine, or any other applicable protection or privilege.

6. To promote communication and cooperation between the parties, the parties will designate e-discovery liaisons for purposes of meeting and conferring on ESI topics. The ESI Liaison for Plaintiffs shall be Jason M. Milne of Phipps Anderson Deacon LLP. The ESI Liaison for Syngenta shall be Jordan M. Heinz of Kirkland & Ellis LLP. The ESI Liaison for ADM shall be Colleen Kenney of Sidley Austin LLP. The ESI Liaison for Cargill shall be Erin Sindberg Porter of Greene Espel PLLP. The ESI Liaison for Bunge shall be Ann Songer of Shook, Hardy & Bacon. The ESI Liaison for Louis Dreyfus shall be David Myre of Quinn Emanuel Urquhart & Sullivan LLP. The ESI Liaison for Gavilon shall be Patrick Pepper of McGrath North Mullin & Kratz PC LLO. The Parties agree to work in good faith to schedule e-discovery conferences when the ESI Liaisons or their designee(s) are available.

B. DELIVERY OF DOCUMENT PRODUCTIONS

1. Each Party shall transmit its document productions to the other Party's ESI Liaison or such vendor as designated by a Party's ESI Liaison.

2. Document productions shall be made via DVD-ROMs, CD-ROMs, portable hard drives or through secure file transfer protocol ("FTP") or similar secure or encrypted electronic transmission.

3. If either Party chooses to employ a document depository vendor to receive documents for its convenience, that side shall bear the costs of such a vendor and take reasonable steps to ensure that only persons authorized under the Protective Order have access to the depository.

4. Each Party shall bear its own costs of production.

C. ESI PRODUCTION FORMAT

1. Image File Format

Except for the types of documents identified in Paragraphs (C)(2)-(3) below, a Producing Party will convert ESI from its native file format ("Native File") to an image file for production, subject to the following specifications:

a. Single-page, black and white, 300 DPI, 1 bit Group IV TIFF images shall be provided for each page of each document, with each image file named after the production number of that page, with extension ".tif."

b. To the extent reasonably possible, the imaged Data shall retain all attributes of the native or hard-copy file, such as document breaks and original document orientation (i.e. portrait to portrait and landscape to landscape). The following formatting will be applied:

i. Word processing documents will be processed to TIFF format and imaged showing track changes or edits, comments, notes and other similar information; ii. Spreadsheet files with redactions will be imaged un-hiding any hidden rows and/or columns and/or sheets; and iii. Presentation files will be processed to TIFF format showing comments, hidden slides, speakers' notes and similar data, where present in the original file. In addition to TIFF images, native presentation files will be provided upon request from a receiving party. The native file will be named as the first Bates number of the respective document. The corresponding load file shall include native file link information for each native file that is produced.

Embedded ESI documents (e.g., a spreadsheet embedded within a word processing document) will be extracted, produced as independent document records and related back to the respective top level parent document (e.g., standalone file, email message, etc.) via the BegAttach field referenced in Appendix 2. Related documents will be produced within a continuous Bates range. However, a Producing Party may suppress its logo or v-card embedded in email files.

c. To the extent a document is not already unitized, the parties shall undertake reasonable efforts, if a document consists of more than one page, to unitize the document and any attachment(s) as in their original form when creating the image files. The parties shall also undertake reasonable efforts to ensure that distinct documents are not merged into a single record and that single documents are not split into multiple records.

d. Text files shall be produced as one file per document, named after the starting production number assigned to the document and ending with extension ".txt", with a text directory for each production volume, and with a relative file path to the text file provided in the related database load file. With the exception of TIFF, PDF and other image file types for which the text cannot be extracted, the text of documents should be extracted directly from the Native File without using Optical Character Recognition ("OCR"), except in the case of redacted documents, as specified in Paragraph 3(c) and 3(d), below. Documents produced in redacted form should not have text files populated with extracted text but should instead have text files populated with OCR data which will not contain the redacted data. If a document does not contain extractable text, the Producing Party shall provide OCR files for that document to the extent possible.

e. Data containing color need not initially be produced in color. The Producing Party will honor reasonable requests for a color image, if the original Data contains color necessary to understand the meaning or content of the Data.

f. Electronic documents attached to an email or electronic document and hard-copy documents attached or appended to a hard-copy document, are to be produced contemporaneously and sequentially immediately after the parent document. Parent-child relationships within a document family (the association between an attachment and its parent document) shall be preserved. Each document shall be produced with the production number for the first and last page of that document in the "BegDoc" and "EndDoc" 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.

g. Except as specified in Paragraph 3(c) below, each of the metadata and coding fields set forth in Appendix 2 that reasonably can be extracted from an electronic document shall be produced for that document. Fields that are not populated shall be left with null values and not populated with fillers or spaces. All metadata pertaining to dates and times will be standardized to Greenwich Mean Time (GMT).

h. Production numbers shall be branded to the lower right hand corner of TIFF images and confidentiality designations (if applicable) shall be electronically branded or burned to the lower left hand corner of TIFF images so that they legibly print with the images. If one or more production numbers is skipped in a production, the Producing Party will so note in a cover letter accompanying the production or in a privilege log. The parties shall use reasonable efforts to ensure that production numbers: (1) are unique and consistent across the entire production, provided, however, that parties may use multiple prefixes to reflect productions from separate entities or related to specific experts; (2) maintain a constant prefix and page length (0-padded) across the production, consistent with the requirements of sub-paragraph (1); (3) contain a prefix that clearly identifies the Producing Party; (4) contain no special characters or embedded spaces; and (5) are sequential within a given document. Attachments will immediately follow the production number(s) for the parent document. Production number prefixes shall be consistent across all documents a party produces in the litigation. However, to the extent a Producing Party produces documents as they were produced in prior proceedings, the documents shall retain their numbering from the prior proceedings.

i. Upon entry of this Protocol, each party shall also produce accompanying image load/unitization files and delimited text files as described below in Appendix 1. Parties are encouraged to work in cooperation with one another and each other's respective vendors in exchanging sample load files. If this exchange occurs, the Receiving Party will have 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 litigation.

j. Where TIFF images of certain electronic documents are not readable, the parties may produce such documents in native format. Where TIFF images of certain hard copy documents are not readable, the parties will meet and confer regarding the volume and best method of production prior to producing paper documents in hard copy format. To the extent the Receiving Party obtains through discovery a file or document that the party believes is not adequately represented in TIFF image format, the Receiving Party may request that the file or document be produced in native format by identifying the document by production number, the production of which shall not unreasonably be withheld.

2. Non-Convertible Files

Certain types of files such as system, program, proprietary files, audio files, and video files may not be amenable to conversion into TIFF format. Such files will not be converted into TIFF format. To the extent that the parties have not excluded these files from production elsewhere in this Protocol, these files will be produced in their native format in accordance with Paragraph 3 below. Examples of file types that are or may not be conducive to conversion into TIFF format include, but are not limited to:

* .exp *.ilk *.res *.trg *.tlh *.idb *.pdb *.pch *.opt *.lib *.cab *.mov *.mp3 *.swf *.psp *.cdi *.chi *.chm *.com *.dll *.exe *.hlp *.ivi *.ivt *.ix *.msi *.nls *.obj *.ocx *.rmi *.sys *.tmp *.ttf *.vbx *.wav *.wpg *.iso *.pdb *.eps *.mpeg *.mpg *.ram *.rm *.psd *.ai *.aif *.bin *.hqx *.snd *.mpe *.wmv *.wma *.xfd *.db *.bat * .xnk *.qtl *.kob *.mso *.dat *.m4a *.bak *.xll *.blank *.wdf *.cdo *.snp *.rename *.mdi *.sda *.ren *.001 *.crf *.dtf *.eds *.ex1 *.dwg *.fdf *.pcl *.wmf *.wps *.fpage *.odttf *.cas *.ldl *.wm *.m4p *.dcx *.3g2 *.sss *.xyz

3. Native Files

In addition to the types of Data listed in Paragraphs C(1) and (2), a Producing Party will produce certain additional types of ESI in their native format, subject to the following specifications:

a. Notwithstanding any provision contained herein, the parties agree that they shall produce Microsoft Excel files, .CSV files and other similar spreadsheet files as Native Files. The Native File shall be renamed in the following format: Bates Prefix-Bates Number-Confidentiality Designation. Except as specified in Paragraph 3(d) below, each of the metadata and coding fields set forth in Appendix 2 that reasonably can be extracted from an electronic document shall be produced for that document. Fields that are not populated shall be left with null values and not populated with fillers or spaces.

b. Where native files are produced in lieu of TIFF images, each native file will be assigned a unique production number within the litigation database. The Producing Party will produce a placeholder (a single-page TIFF slip sheet indicating that the native item was produced) along with the file itself in native format. The placeholder will be branded with the production number in the lower right hand corner, the original filename of the native file, and the phrase "PRODUCED IN NATIVE ONLY" branded in the center of the page. The Producing Party will also brand any confidentiality or similar endorsements in the lower left hand corner of the placeholder.

c. To the extent that any file identified for production in native format contains information subject to a claim of privilege or any other applicable protection that requires redaction, the Producing Party shall convert that file to TIFF format and produce it with the necessary redactions, along with OCR text that reflects such redactions, unless such conversion and redaction is unduly burdensome to the Producing Party. All such OCR text will be Unicode-compliance (UTF-8) to the extent practical. If such conversion is unduly burdensome or renders the document unusable, the Producing Party may produce the document in any reasonably usable form as may be agreed upon by the respective parties.

d. The portion of the redacted text shall be clearly identified on the face of the TIFF image, either by masking the redacted content with electronic highlighting in black or through the use of redaction boxes. The label "Redacted" shall appear on the face of the redacted portion of the TIFF image. If Personally Identifiable Information ("PII"), such as social security numbers are redacted, the label "Redacted — PII" shall appear on the face of the redacted portion. If information is redacted on the basis of the attorney-client privilege or the work product doctrine, the basis for the redaction shall appear on the face of the redacted document. Redactions for privilege and work product, including whether such redactions must be included on a privilege log, are discussed in more detail in Section F below. The redacted TIFF image shall be produced in accordance with the image load file specifications in Appendix 1, and any other provisions for the production of TIFF images contained herein. Redacted text shall not be included in the text file for that redacted TIFF image. The original unredacted Native File shall be preserved pending conclusion of the Action.

e. The parties will make reasonable efforts to remove passwords or other security protection from any Native File prior to production. If the security protection cannot be removed from a Native File after reasonable efforts by the Producing Party, a placeholder TIFF image may be produced in place of the Native File indicating that security protection could not be removed from the Data. Upon request from the Requesting Party, the parties shall meet and confer in good faith regarding the reasonable efforts or mechanisms made to remove the security protection from the Native File and/or the production of the available metadata listed in Appendix 2 from the file.

f. If a Native File is used at a deposition or hearing in this Action, or attached to a motion or other filing, it shall be accompanied by its production number-stamped placeholder TIFF image in order to facilitate tracking and authentication thereof. The parties may, but are not required to, further mark fixed images of Native Files with additional numbering for ease of identification at a deposition or hearing.

4. Duplicates

To reduce the unnecessary costs of reviewing and producing duplicate documents, each party will make reasonable efforts to remove duplicate Data prior to producing documents. Data will be deduplicated vertically within each custodian and horizontally across custodians (e.g., globally) following industry standard de-duplication algorithms. The ALL_CUSTODIANS field will be populated with all of the custodians who had a copy of the document in their files. In order to reduce the volume of entirely duplicative content within email threads, the parties may but are not required to use email thread suppression but shall disclose that they have used email thread suppression.

5. Search Methodology

The Parties acknowledge that certain Parties to this litigation have already collected, searched, reviewed and produced documents in other filed actions that may be responsive to requests for production in this Action ("Previously Produced ESI"). To the extent that those previously produced documents are deemed by the Producing Party to be responsive to requests in this Action, those documents may be reproduced here with the same Bates number and Confidentiality designations. To the extent the Parties wish to use search terms or alternative search methodologies with respect to the review and production of ESI, other than Previously Produced ESI, they shall meet and confer and attempt in good faith to reach agreement regarding the search methodology, including the proposed search terms and the identities of custodians from whom ESI will be collected and searched. To the extent a party has already employed a search methodology or knows it intends to use a search methodology for ESI other than Previously Produced ESI, each Party shall discuss its proposed methodology within a reasonable time of employing it. Nothing in this Protocol shall prevent any Party from conducting a manual review of documents after application of ESI search methodologies for responsiveness, privilege, and confidentiality.

6. Production of Data from Databases and Other Formats

a. If a Producing Party identifies a particular source or type of responsive Data for which it reasonably believes that application of this Protocol would be unduly burdensome or impractical, the party identifying the source or type of responsive Data shall promptly notify the Requesting Party, explaining in detail the type and source of the Data at issue, and the reason(s) why the party believes that application of this Protocol would be unduly burdensome or impractical, and proposing reasonable modifications of this Protocol with respect to that source or type of responsive Data. Thereafter, the parties shall meet and confer within 14 calendar days to determine if modification of the Protocol with respect to the Data at issue is appropriate, and if an agreement is not reached, the Producing Party bears the burden of seeking relief from the Court from the requirements of this Protocol.

b. If a response to discovery requires production of ESI contained in a database or comprehensive electronic accounting system, the Producing Party shall meet and confer with the Requesting Party concerning a reasonable method of production. To the extent reasonably available, the Producing Party shall also provide any data dictionary, key, or other information sufficient to provide a reasonable understanding of the contents of the database or accounting system.

c. Nothing in this Protocol requires a party to use unreasonably burdensome or expensive data recovery processes, or to search for information, documents, or other materials in locations where responsive information is not likely to be found, absent a showing of good cause. To the extent a party believes that responsive data is likely to be found on data sources that are not reasonably accessible, the party shall disclose that fact to the other part(ies).

7. Time Zone

Unless otherwise agreed, all dynamic date and time fields, where such fields are processed to contain a value and do not automatically populate, and all metadata pertaining to dates and times will be standardized to Greenwich Mean Time (GMT). The Parties understand and acknowledge that such standardization affects only dynamic fields and metadata values.

D. HARD COPY DOCUMENT PRODUCTION FORMAT

1. The parties agree that, with respect to documents that exist in hard-copy format ("Hard-Copy Materials"), a Producing Party will image and produce such documents as TIFF images and OCR text in accordance with the specifications delineated in Section C, above. Where paper scanned images have identification spines, file folder labels, "post-it notes," or any other labels, the information on the label shall be scanned and produced to the extent practicable. In addition, folder labels, box labels, or binder labels (including spines), or other similar top level identifiers, to the extent practicable, shall be manually recorded at the time of scanning and coded in the Binder and/or Folder field. Load files for such productions shall include data relevant to the individual documents, including Bates numbering, custodian, OCR and folder labels and box labels that have been manually recorded.

2. To the extent responsive Hard-Copy Materials are included in a large compilation of documents that is compiled solely for the purposes of storage convenience and not for any purposes related to the litigation and contains irrelevant, non-responsive Hard-Copy Materials, the Producing Party may produce responsive, non-privileged Hard-Copy Materials without also producing non-responsive Hard-Copy Materials.

3. If a Producing Party reasonably believes that production of Hard-Copy Materials as imaged files pursuant to this Section D is unduly burdensome, the Producing Party shall seek to meet and confer in good faith with the Requesting Party regarding content, volume, and related issues before any production of Hard-Copy Materials. If the parties are unable to reach agreement, any party may seek relief from the Court.

E. PREVIOUSLY PRODUCED ESI

For every production of ESI in the Action that was made prior to the adoption of this Protocol that the Producing Party determines is responsive to requests for production in this Action, the Producing Party shall disclose prior to production how such materials were produced in the previous action. The Producing Party shall produce materials as they were produced in the prior action or proceeding, and no additional metadata overlay need be produced absent a further order from the Court.

F. PRIVILEGE LOGS

1. To the extent that a document is withheld from production on the basis of the attorney client privilege or the work product doctrine, the producing Party shall produce a rolling privilege log of withheld documents within a reasonable period after the document was withheld from the rolling production.

2. Prior to generation of a privilege log, the parties shall meet and confer in a good faith effort to reach agreement on the manner in which a privilege log will be generated and the contents of such a log. The parties shall consider whether the nature and volume of the privileged documents and ESI warrants category-by-category privilege logs, document-by-document privilege logs, or some combination of these approaches, consistent with Federal Rule of Civil Procedure 26. If the parties are unable to agree on the requirements of a privilege log for documents and ESI, the parties shall present such a dispute to the Court. Neither party shall contend that the meet and confer process set forth in this paragraph constitutes a waiver of attorney-client privilege or attorney work product for any document claimed to be protected from disclosure.

3. The following documents presumptively need not be included on a privilege log:

a. Privileged communications exclusively between a party and its outside litigation counsel after September 12, 2014, and work product performed by a party at the direction of outside litigation counsel after September 12, 2014. b. Privileged communications exclusively involving outside litigation counsel after September 12, 2014. c. Work product created by in-house or outside litigation counsel, or by an agent of in-house or outside litigation counsel, other than a party, after September 12, 2014.

The parties agree that certain privileged communications between a party and its in-house counsel need not be logged, but will continue to confer on that subject in order to reach agreement or present their disagreements in accordance with Section F(2) above. The parties further agree to meet and confer regarding any proposed additional categories of documents that presumptively need not be logged.

G. OBJECTIONS PRESERVED

Nothing in this Protocol shall be interpreted to require disclosure of relevant information or Data that is protected by the attorney-client privilege, common interest privilege, work-product doctrine, or is prohibited from disclosure under any similar law, regulation, rule, court order, or any other applicable privilege or protection. The parties do not waive any objections to the production, discoverability, or confidentiality of ESI, Hard-Copy Materials or any other discovery materials, including, without limitation, objections regarding the burden, overbreadth or relevance of document requests related to ESI, Hard-Copy Materials or any other discovery materials, or relating to the production of ESI or Hard-Copy Materials in a form specified in this Protocol.

H. RESOLUTION OF DISPUTES

1. The parties agree to meet and confer in good faith regarding matters related to the production of Data not specifically set forth in this Protocol, related to the interpretation of this Protocol, or related to the parties' obligations thereunder. The parties shall make their best efforts to comply with and resolve any differences concerning compliance with this Protocol. If a Producing Party cannot comply with any material aspect of this Protocol, such party shall inform the Requesting Party in writing at or before the time of production as to why compliance with the Protocol is unreasonable or not possible.

2. If the parties are unable to reach resolution regarding any dispute concerning the interpretation of this Protocol or compliance with same, such disputes may be presented for judicial resolution. No party may seek judicial relief concerning this Protocol unless it first has conferred with the applicable Producing or Requesting Party.

IT IS SO ORDERED.

APPENDIX 1: Load File Formats

Image Load Files

• ESI will be produced in Concordance load file format. Upon request and demonstration of need, the Parties will meet and confer to discuss production in an alternative load file format or to produce without load files. • Every document referenced in a production image load file shall have all corresponding images, text, and data. Redacted text shall not be included in a redacted document's text file. • The name of the image load files shall mirror the name of the delivery volume, and should have an .opt or .log file extension (e.g., ABC001.OPT or ABC001.LOG). • The volume names shall be consecutive (i.e., ABC001, ABC002, et. seq.). • Every image in the delivery volume shall be contained in the image load file. • The image key shall be named the same as the production number of the page. • Load files shall not span across media (e.g., CDs, DVDs, Hard Drives, etc.); instead, a separate volume shall be created for each piece of media delivered. • Each image load file shall be produced in a standard litigation support image load format (e.g., .opt or .log) providing: a. The document number for each image; b. The relative path name(s) of each TIFF image file; and c. The document boundaries for each document. • The load file shall be in the order that appropriately corresponds with each image file. The following represents an example of the format of a standard.opt or .log image load/unitization file: Bates,Volume,PATH_to_image,Document Break,Folder Break,Box Break,Total_Pages. M_0100000,06150101,\06150101\0000\0001.TIF,Y,,,1 M_0100001,06150101,\06150101\0000\0002.TIF,Y,,,1 M_0100002,06150101,\06150101\0000\0003.TIF,Y,,,1 M_0100003,06150101,\06150l01\0000\0004.TIF,Y,,,2 M_0100004,0615010l,\06150101\0000\0005.TIF,,,, M_0100005,06150101,\06150101\0000\0006.TIF,Y,,1 M_0100006,06150101,\06150101\0000\0007.TIF,Y,,,4 M_0100007,06150101,\06150101\0000\0008.TIF,,,,, M_0100008,06150101,\0615010l\0000\0009.TIF,,,,, M_0100009,06150101,\06150101\0000\0010.TIF,,,,,

Metadata Load Files

• The metadata load file shall use the following delimiters: • Field Delimiter: ¶ (ASCII 020) • Text Qualifier: þ (ASCII 254) • Multi-value Delimiter; (ASCII 059) • New line: ® (ASCII 174) • Metadata fields that are not applicable to a document or are NULL shall be left with null values and not populated with fillers or spaces. • All date fields shall be produced in "mm/dd/yyyy" format. • All time fields shall be produced in "hh:mm:ss" format. • Load files shall not span across media (e.g., CDs, DVDs, Hard Drives, etc.); instead, a separate volume shall be created for each piece of media delivered. • The name of the metadata load file shall mirror the name of the delivery volume, and shall have a .dat or .txt extension (i.e., ABC001.DAT or ABC001.TXT). • The volume names shall be consecutive (i.e., ABC001, ABC002, et. seq.). • Furthermore, .dat or .txt files must be encoded in ASCII or ANSI:UTF codings. • The metadata fields listed in Appendix 2 (as pertain to particular categories of documents pursuant to this Protocol) shall be included in the delimited database load files, to the extent such metadata is already in existence and reasonably accessible. To the extent that metadata does not exist, is not reasonably accessible or available, or would be unduly burdensome to collect, nothing in this Protocol shall require any party to extract, capture, collect or produce such metadata. Any party that intends to withhold existing metadata listed in Appendix 2 on the basis that it is not reasonably accessible or available or would be unduly burdensome to collect shall promptly inform the requesting party and meet and confer. The parties will reasonably endeavor to confirm the accuracy of the metadata extraction process and expressly reserve their rights to object to the use of metadata for any reason or purpose. To the extent that the metadata listed in Appendix 2 relating to any ESI contains information subject to a claim of privilege or any other applicable protection, that metadata may be redacted or withheld, as appropriate, and the Producing Party shall include information regarding the basis and justification for withholding or redacting such information in its privilege log in accordance with Rule 26 of the Federal Rules of Civil Procedure.

APPENDIX 2: ESI Metadata and Coding Fields

Field Name Field Description Populated For Example Values BegDoc Production number of the first E-mail, E-doc, or Prefix-0000000001 page of the document. Paper as appropriate EndDoc Production number of the last All Prefix-0000000002 page of the document. BegAttach Production number of the first All Prefix-0000000001 page of the first document of the document family. EndAttach Production number of the last All Prefix-0000000004 page of the last document of the document family. AttachCount The number of attachments to All 3 a document. FileType The record type of a document. All Paper, Email, E-Attachment, Standalone Electronic Document All_Custodians Additional custodians who had All a copy of the document prior to de-duplication, including duplicate custodians. To All recipients that were E-mails larry.murphy@email.com included on the "To" line of the e-mail. From The name and e-mail address E-mails Bart.Cole@email com sender of the e-mail. CC All recipients that were E-mails sstephens44@email .com included on the "CC" line of the e-mail. BCC All recipients that were E-mails ceo-gs@email.com included on the "BCC" line of the e-mail. Date an e-mail was received DateRcvd (GMT). E-mails mm/dd/yyyy TimeRcvd The time an e-mail was E-mails hh:mm:ss: received (GMT). DateCreated The date an e-mail or e-file E-mails, E-attachments mm/dd/yyyy was created (GMT). and electronic documents TimeCreated The time an email or e-file was E-mails, E-attachments hh:mm:ss: created (GMT) and electronic documents DateLastModified Date the document E-attachments; mm/dd/yyyy was last modified. Electronic documents TimeLastModified The time an e-file was last E-attachments; hh:mm:ss: modified (GMT). Electronic documents LastSavedBy Value shows within the "last E-mails, E-attachments saved" metadata field. and electronic documents Cal_Start Start date and time of E-mails, E-attachments calendar or appointment and (GMT). electronic documents Hash MD5 hash value of document All Hash Value or "de-duplication key" FileName The file name of the E-attachments; document, including file Electronic extension documents Author Author of document E-attachments and electronic documents Subject Document subject line of an e-mail E-mails Orig_File_Name The original file E-attachments name of an electronic and electronic document or an documents attachment to an Email. File_Ext The file extension of a All Doc, nsf, rtf, pdf, msg, document. xls, etc. File_Size The file size of a document All (including embedded attachments). FilePath The full path to the file at its All original location. NativeFilePath The path to the E-attachments corresponding native and Electronic file included with a documents production volume. produced in native format TEXTPATH The relative path to the All corresponding OCR or extracted text file included with a production volume. Confidentiality The designated level of All CONFIDENTIAL Designation confidentiality pursuant to the Protective Order. Container Top level source and folder-level All level source for any scanned document, if available.
Source:  Leagle

Can't find what you're looking for?

Post a free question on our public forum.
Ask a Question
Search for lawyers by practice areas.
Find a Lawyer