Bratton v. The Hershey Company, 2:16-cv-4322-C-NKL. (2017)
Court: District Court, W.D. Missouri
Number: infdco20170721677
Visitors: 3
Filed: Jun. 14, 2017
Latest Update: Jun. 14, 2017
Summary: ORDER APPROVING ELECTRONIC DISCOVERY PROTOCOL NANETTE K. LAUGHREY , District Judge . The parties move for approval of their stipulated and agreed electronic discovery protocol. Doc. 76. The motion is granted. As stipulated and agreed to by the parties, Docs. 76-1 and 76-2, the following technical specifications shall govern electronic discovery in this matter: 1. General Provisions A. The specifications set forth below will govern the collection and production of all documents and electro
Summary: ORDER APPROVING ELECTRONIC DISCOVERY PROTOCOL NANETTE K. LAUGHREY , District Judge . The parties move for approval of their stipulated and agreed electronic discovery protocol. Doc. 76. The motion is granted. As stipulated and agreed to by the parties, Docs. 76-1 and 76-2, the following technical specifications shall govern electronic discovery in this matter: 1. General Provisions A. The specifications set forth below will govern the collection and production of all documents and electron..
More
ORDER APPROVING ELECTRONIC DISCOVERY PROTOCOL
NANETTE K. LAUGHREY, District Judge.
The parties move for approval of their stipulated and agreed electronic discovery protocol. Doc. 76. The motion is granted. As stipulated and agreed to by the parties, Docs. 76-1 and 76-2, the following technical specifications shall govern electronic discovery in this matter:
1. General Provisions
A. The specifications set forth below will govern the collection and production of all documents and electronically stored information ("ESI") produced by the Parties during discovery in the above captioned action as a supplement to the Federal Rules of Civil Procedure ("FRCP") and any other applicable order and rules of the Court.
B. The parties are aware of the importance the Court places on cooperation and will continue to consult and cooperate reasonably as discovery proceeds.
C. The parties agree to identify appropriate limits to discovery, consistent with FRCP 26 and the Principles for the Discovery of Electronically Stored Information of the Western District of Missouri, including Principle 1.03, including limits on custodians, subject matter and time period to guide preservation and discovery. It shall be the obligation of producing party to propose such limitations sufficiently in advance of production dates so as to not delay any production.
2. Sources of ESI
A. Absent a showing of good cause, the following categories of ESI need not be preserved:
i. Unallocated, slack space, deleted data, file fragments, or other data accessible by use of computer forensics;
ii. Random access memory (RAM), temporary files, or other ephemeral data that is difficult to preserve;
iii. Data relating to online access, such as temporary Internet files, browser history, file or memory caches and cookies;
iv. Data in metadata fields that are frequently updated automatically as part of the usual operation of a software application, operating system or network (e.g., data last opened) provided, however, that such metadata as it exists at the time of preservation shall be retained, produced, and not altered by the production process unless it is separately preserved and produced with the relevant document;
v. Telephone or VOIP voice messages that are not regularly stored or saved, unless any such messages were otherwise stored or saved;
vi. Data stored on cell phones, mobile devices, excluding tablets that is more reasonably accessible elsewhere, provided that the alternative location is identified and the producing party shall produce such data from reasonably accessible sources along with documentation of the specific device on which it is also located, and the producing party shall do so without any additional request for production from the receiving party. Further, all such devices that were identified and that contain data that was not preserved shall be identified;
vii. Call history records maintained on mobile devices, cell phones or blackberries. The parties will continue to confer in good faith regarding the preservation and production of responsive telephone bills that contain such records. Such Files shall be preserved until there is an agreement otherwise.
viii. Operating system files, executable files, and log files (including web server, web services, system, network, application log files and associated databases, analysis output caches, and archives of such data). The parties will continue to confer in good faith regarding the preservation and production of log files, to the extent they exist, that may identify putative class members. Such Files shall be preserved until there is an agreement otherwise.
ix. Electronic data temporarily stored by laboratory equipment or attached electronic equipment, provided that such data is not ordinarily preserved as part of a report.
B. Absent a showing of good cause, no party need restore any form of media upon which backup data is maintained in a party's normal or allowed processes, including but not limited to backup tapes, disks, SAN, and other forms of media, to comply with its discovery obligations in the present case. For the avoidance of doubt, CDs, DVDs or other media that are used in the ordinary course of business to store original data shall be searched for responsive material
3. Search
A. The parties have met and conferred on several occasions regarding ESI. Within 21 days of the Stipulation the Parties will meet and confer in order to complete any open items on the recently propounded Western District of Missouri Checklist Regarding Electronically Stored Information and work in good faith to further confer on an ongoing basis regarding the production of ESI.
4. General Production Format
A. The parties will produce ESI in TIFF image format, together with extracted text, OCR data, and metadata in a format compatible with Relativity load files provided that the documents do not become illegible or unusable or in any way alter existing metadata when converted to TIFF image format. In good faith, a party may request production of the native format of a document produced in non-native format.
B. Certain documents that become illegible or unusable when converted to TIFF image format (Microsoft Excel files, other similar spreadsheet application files, Microsoft Access and Microsoft Project, and html files), shall be produced in native format, unless they contain information that requires redaction. The parties reserve their rights to request, in good faith, the production of additional electronic documents in their native format.
C. Documents with the following file extensions will be produced in color: JPEG, JPG, GIF, PDF, PPTX, PPT, and compressed files within ZIP. After reviewing the first production, the parties may add to this list with the intention of ensuring that documents to which color is intrinsic are produced in color. The other party may in good faith request additional documents in color. Documents produced in color should be in the TIF, JPG or JPEG format.
D. When processing ESI data, the parties shall conform dates of ESI document metadata to UTC date format (universal time standard/global time standard).
E. All production documents will be produced with extracted text and load files including the data fields provided in Exhibit A. In those instances where redaction is used, OCR text will be provided in lieu of the extracted text to allow for removal of the redacted text from production. For documents produced in native format, in addition to producing extracted text and the data fields in the table below, the producing party will provide slip sheets endorsed with the production number and level of confidentiality pursuant to any applicable protective orders in this case.
F. Non-electronic documents shall be scanned into a static-image format. Copies of file folders and identification of file custodians shall be produced.
5. Image Format
A. Documents that are converted to TIFF image format will be produced in accordance with the following technical specifications:
i. Images will be single-page, Group IV TIFF image files, one image per page;
ii. TIFF file names cannot contain embedded spaces;
iii. Bates numbers should be endorsed on the lower right corner of all TIFF images and will be a unique, consistently formatted identifier, i.e. alpha prefix along with a fixed length number (e.g., ABC0000001). The number of digits in the numeric portion of the Bates number format should not change in subsequent productions.
iv. Confidentiality designations, if any, will be endorsed on the lower left corner of all TIFF images;
v. All pages of presentations, e.g., PowerPoint presentations, should be provided in full slide image format, with any slide notes following the appropriate slide image.
B. Images will be delivered with an image load file in the Opticon (.OPT) file format.
C. Images, native files, and text files should be stored and delivered in separate folders named "IMAGES," "TEXT" and "NATIVE." Folders should be segmented into directories not to exceed 5,000 files.
6. Data Format
A. Extracted data and searchable text, including the data fields listed in Exhibit A, will be produced in accordance with the following technical specifications:
i. The first line of the .DAT file must be a header row identifying the field names;
ii. The .DAT file must use the following default delimiters:
a. Comma ASCII 020
b. Doublequote ASCII254
c. New line ASCII 174
iii. Date fields should be provided in the format: mm/dd/yyyy and time shall be represented as HH:MM:SS UTC/AM|PM;
iv. All attachments should sequentially follow the parent document/email.
v. Attached as Exhibit A is "Metadata Field List" reflecting the metadata that will be provided, if they exist, in the .DAT file/
7. Documents Generally
A. Except as to the formatting for production agreed to herein, all documents (electronic or otherwise) shall be produced as kept and maintained by the producing party in a reasonably useable format.
8. Searchable Text
A. Searchable text of entire documents will be produced either as extracted text for all documents that originate from hard copy, in electronic format, or, for any document from which text cannot be extracted, as text generated using Optical Character Recognition (OCR) technology. For redacted documents, the full text of the redacted version of the document will be produced.
B. Searchable text will be produced as a document-level multi-page ASCII text file with the text file named the same as the BEGDOC field, placed in a separate folder. The full path of the text file must be provided in the .DAT file for the TEXT field.
9. Native Files
A. Native file documents, emails or attachments may be included with the electronic production using the below criteria:
i. Documents produced in native format shall be re-named to reflect the production number.
ii. The full path of the native file must be provided in the .DAT file for the NATIVE FILE field;
iii. The confidentiality designation under the Protective Order to be entered in this action will be produced in the load file in the DESIGNATION field.
B. If documents produced in native format are printed for use in deposition, motion or hearing, the party printing the document must label the front page of the file that is printed with the corresponding production number and, if applicable, the confidentiality designation assigned by the producing party to that file under an applicable protective order to be entered in this action.
10. De-Duplication
A. Documents shall be de-duplicated across custodians. The parties agree to use a verifiable, de-duplication process to ensure that one copy of a document is produced and will deduplicate using the SHA1 Hash value across custodians and will provide the MD5 Hash and SHA1 Hash value.
B. For the avoidance of doubt, a document is not considered to be a duplicate in the case where email headers or attachments differ in any regard or where the same document is both attached to an email and exists in a form that is separate from such email (e.g., as an attachment to another email, as a standalone document saved to some electronic media, etc). Should a producing party de-duplicate any documents, the producing party waives any objection as to the authenticity of the version of the document produced.
C. The producing party shall produce in an "ALL CUSTODIANS" data field the name of each custodian who possessed or controlled a copy of such documents.
D. For good cause shown and in good faith, the receiving party may request all duplicates of a produced document. And to the extent necessary to understand and evaluate the deduplication process the Parties will cooperate in good faith.
11. Changes to The Stipulation and Order
A. The Parties will work together in good faith to ensure the ESI protocol remains efficient and conforms to the letter and spirit of the Western District of Missouri's Principles for the Discovery of Electronically Stored Information.
B. Either Party may seek changes to the Agreement as it in good faith believes may be required so long as efforts to reach agreement have been exhausted.
SO ORDERED.
Exhibit A: Metadata Field List
Other Calendar
Field Name Description Field Type Email ESI Items
VOLUMENAME Production volume number (e.g. ABC0001) Text X X X
BEGDOC # Start Bates number (including Prefix) of each document being produced Text X X X
ENDDOC # End Bates number (including prefix) of each document being produced Text X X X
DOCID Must equal the value appearing in the BEGDOC# field and be unique Text X X X
NUMPAGES Page Count Text X X X
PARENTID Parent record's BEGDOC# (Populated only in the child's record) Text X X X
CUSTODIAN(S) or
ALL CUSTODIANS Custodian(s) / source(s) — Format should be Last_First Multi-Entry X X X
HASHMD5 Document MD5Hash value Text X X X
SHA1 value Document SHA1 value
BEGATTACH BEGDOC# value of the parent record Text X X X
ENDATTACH ENDDOC# value of the last page of the child record Text X X X
Range of the BEGDOC# value of the parent record to the ENDDOC# Text X X X
ATTACHMENTRANGE value of the last page of the child record.
FROM Author of the Email or Calendar item Text X X
TO Recipients of the Email or Calendar item Multi-Entry X X
CC Copies of the Email or Calendar item Multi-Entry X X
BCC Blind Copies of the Email or Calendar item Multi-Entry X X
SUBJECT Email Subject or Calendar Subject Text X X
This is a multipurpose date field. Populate with Datesaved for E-Docs;
Datesent for emails; Dateapptstart for Calendar appointments. Format
DOCDATE should be MMDDYYYY Date X X X
DATECREATED Date electronic file was created. Format MMDDYYYY Date X
TIMECREATED Time electronic file was created. Format HH:MM:SS Time X
DATESAVED Date electronic file was last saved Date X
DATEPRINTED Date electronic file was last printed. Date X
AUTHOR Author of electronic file Text X
LAST AUTHOR Last saved by value of electronic file Text X
DATESENT Date the email or calendar item was sent. Format MMDDYYYY Date X X
TIMESENT Time the email or calendar item was sent. Format HH:MM:SS Time X X
DATERECEIVED Date the email or calendar item was received. Format MMDDYYYY Date X X
TIMERECEIVED Time the email or calendar item was received. Format HH:MM:SS Time X X
If available, lobally unique identifier for message which typically
includes messageid and a domain name. In some instances, only the
INTERNETMESSAGEID MessageID may be available. Text X X
If available, the unique system identification number for the email
message assigned by the email database. Typically Entryid for Outlook
and UniqueID for Lotus Notes. In some instances, only the Internet
MESSAGEID Message ID may be available. Text X
CONVERSATIONINDEX Email thread identification Text X X
File size of electronic file. should be consistent throughout the
production. If Bytes are used it should not be switched to Kilobytes in
FILESIZE later productions and vice versa Integer X X X
FILENAME File name of the native file Text X X X
APPLICATION Application used to create native file Text X X X
FILEEXTENSION File extension of native file Text X X X
File path to native file as it existed in the original environment/ Email
FILEPATH folder path. Text X X X
DOCLINK File path location of the current native file within the production set. Text X
X
X
X
X
Type of file being produced: Email; Email Attachment; Loose Edoc; Multi-Entry X X X
RecordType Paper
Additional content properties of an electronic document to include: Has
Track Changes; Has Hidden content; Has embedded object; Has Hidden
slides; Ha comments; Has speaker notes. These will be delivered as
DocProperties separate fields. Multi-Entry X
EmailProperties Additional content properties of an email to include: Importance; Multi-Entry X X
Source: Leagle
