Filed: Jan. 14, 2013
Latest Update: Jan. 14, 2013
Summary: STIPULATED ORDER REGARDING THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION JOHN A. MENDEZ, District Judge. I. USE OF SEARCH TERMS TO IDENTIFY POTENTIALLY RESPONSIVE ELECTRONICALLY STORED INFORMATION To reduce the likelihood of the parties litigating the adequacy of the search terms used to identify potentially responsive documents during the course of this action, the producing party will follow the search term protocol set forth herein: 1. A producing party choosing to use search te
Summary: STIPULATED ORDER REGARDING THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION JOHN A. MENDEZ, District Judge. I. USE OF SEARCH TERMS TO IDENTIFY POTENTIALLY RESPONSIVE ELECTRONICALLY STORED INFORMATION To reduce the likelihood of the parties litigating the adequacy of the search terms used to identify potentially responsive documents during the course of this action, the producing party will follow the search term protocol set forth herein: 1. A producing party choosing to use search ter..
More
STIPULATED ORDER REGARDING THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION
JOHN A. MENDEZ, District Judge.
I. USE OF SEARCH TERMS TO IDENTIFY POTENTIALLY RESPONSIVE ELECTRONICALLY STORED INFORMATION
To reduce the likelihood of the parties litigating the adequacy of the search terms used to identify potentially responsive documents during the course of this action, the producing party will follow the search term protocol set forth herein:
1. A producing party choosing to use search terms to identify potentially responsive documents shall exercise reasonable due diligence in investigating and analyzing its data in providing its proposed list of search terms to the requesting party prior to applying the search terms. Such due diligence shall include, but is not limited to: identification of commonly misspelled words appearing on responsive documents or electronically stored information; identifying idiosyncratic language and terms of art utilized by a party in order to identify responsive documents and by interviewing key custodians about the same.
2. In addition to disclosing its proposed search terms, the producing party shall also provide information to the requesting party sufficient to explain the measures taken to assess the adequacy and reliability of the search terms it has proposed.
3. The parties will then meet and confer to discuss the search terms and the process used to evaluate their adequacy and reliability, at which time the requesting party has the right to suggest additional terms, due diligence or testing procedures, or request additional information to enable such suggestions to be made.
4. Within 180 days after the first material production of information by a producing party, the requesting party may suggest additional or edited search terms based on the contents of the documents initially produced. Upon receiving additional or edited terms suggested by the requesting party, the producing party shall within twenty-one days either: (a) agree to apply the additional terms and produce responsive documents identified as a result therefrom; or (b) refuse to apply the additional terms and describe with particularity (including testing procedures) why the additional terms will not yield additional responsive information sufficient to warrant the application of the additional terms.
The protocol described above does not preclude any party from asserting either the adequacy or inadequacy of the search terms selected and applied. The parties, however, will act in good faith and use these procedures to identify and reduce the potential for disputes that may arise in connection with the use of search terms.
II. PRODUCTION OF ELECTRONICALLY STORED INFORMATION
A. Definitions
a) "Document(s)" means electronically stored information (ESI) existing in any medium from which information can be obtained or translated into reasonably usable form, including SMSs and text messages and similar information which may be located on mobile phones or personal digital assistants.
b) "Native File(s)" means ESI in the file type for (or of) the application in which such ESI is normally created, viewed and/or modified.
c) "Metadata" means: (i) information embedded in a Native File that is not ordinarily viewable or printable from the application that generated, edited, or modified such Native File; and (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.
d) "Static Image(s)" means a representation of ESI produced by converting a Native File into a standard image format capable of being viewed and printed on standard computer systems. A Tagged Image File Format (TIFF) image is an example of a Static Image.
e) "Load/Unitization file" means an electronic file containing information identifying a set of paper-scanned images or processed ESI and indicating where individual pages or files belong together as documents, including attachments, and where each document begins and ends. A Load/Unitization file will also contain data relevant to the individual Documents, including extracted and user created Metadata, coded data, as well as OCR or Extracted Text.
f) "OCR" means the optical character recognition file which is created by software used in conjunction with a scanner that is capable of reading text-based documents and making such documents searchable using appropriate software.
g) "Extracted Text" means the text extracted from a Native File and includes all header, footer and document body information.
B. Form and Format for the Production of ESI and Paper Documents Converted to Electronic Form
1. Electronic Production of Paper Documents
The parties will produce any paper Documents, including spreadsheets maintained in paper form that have been scanned or otherwise converted into electronic form as of the time the documents are first produced in this litigation. The form of production shall be:
a) TIFF images, consistent with the specifications in Section II.B.2.b.;
b) The appropriate Load/Unitization files in accordance with Exhibit "A" and consistent with the specifications in Section II.B.5.; and
c) Searchable OCR text of scanned paper Documents created by the producing party, if any, consistent with the specifications in Section II.B.4.
d) This Stipulation creates no obligation upon the producing party to convert paper documents into electronic form.
e) If, however, the producing party has converted paper documents into electronic form as of the time the documents are first produced in this litigation, the producing party shall produce those documents in accordance with this Stipulation.
2. Native Files to be Produced as Static Images
a) Except as otherwise stated below, or by court order, Native Files will be produced to the requesting party as Static Images together with Load/Unitization files specified below.
b) All Static Images will be produced as single page Black & White, Group 4 TIFF (.TIF or .TIFF) files at 300 × 300 dpi resolution and 8.5 × 11 inch page size, except for documents that in the producing party's reasonable judgment require a different resolution or page size; provided, however, if a color image is produced in black and white, the receiving party may request the producing party to produce the original, color image, as single page, color Joint Photographic Experts Group (.JPEG or .JPG) files.
c) All Static Image file names shall match the Bates number assigned to the image.
3. Production of Native Files
a) In addition to other production requirements set forth in this document, the parties agree to produce Native Files of spreadsheet application files (e.g., MS Excel), presentation application files (e.g. MS PowerPoint), and multimedia audio/video files (e.g., .wav, .mpeg, .avi), subject to the right of the producing party to object to the native production of files where such production would result in the disclosure of information that is protected from disclosure by the attorney-client privilege or the work product doctrine and it is impracticable or unduly burdensome to redact or otherwise produce the native production while maintaining such privilege or protection. Audio files in non-standard formats should be produced in MP3 format. Video files in nonstandard formats should be produced in .mpeg or .avi format. In addition to the objections listed in the preceding sentence to the production of Native Files, the Producing Party may also object to the production of any of the file types described in this paragraph in native format due to the impracticability or burden of redaction issues, in which case, the Producing Party shall initially produce the file as a Static Image in TIFF format, and the parties shall meet and confer regarding whether production in native format is practicable, appropriate, or unnecessarily burdensome
b) The parties agree to meet and confer informally regarding the production of database application files (e.g., MS Access, SQL, SAP) to determine the most reasonable form of production based on the specific circumstances at hand. Notwithstanding the foregoing, a party may elect to produce Native Files of portable database application files (e.g., MS-Access) without the need to meet and confer regarding the form of production. However, responsive data contained in such database application files should be produced in a report or export of such data to MS-Excel spreadsheets. Prior to generating such reports the producing party will explain the categories of data maintained in each database the categories that it intends and does not intend to produce, and the format in which the reports will be generated. The producing party will provide a sample page of each report to be produced in advance of its actual production.
c) A receiving party may request that the producing party produce the Native File corresponding to a produced Static Image, subject to reasonable objection by the producing party. The request for production of any specific Native Files(s) shall include the Bates numbers of the TIFF documents to identify the corresponding Native File.
d) Any produced Native File will include the Bates number of the first page of the Bates range that corresponds to the TIFF image, followed by a carat delimiter, which shall be appended as a prefix to the file name.
e) Through the pendency of the action, the producing party should exercise reasonable, good faith, efforts to maintain all preserved and collected Native Files in a manner that does not materially alter or modify the file or the Metadata.
f) No party may attach to any pleading or any correspondence addressed to any court, or any adverse or third party, or submit as an exhibit at a deposition or any other judicial proceeding, a copy of any native format document produced by any party without ensuring that the corresponding Bates number and confidentiality legend, as designated by the producing party, appears on the document.
4. Production of Searchable Text
a) ESI shall be produced with separate multi-page searchable Extracted Text. For ESI from which text cannot be extracted, OCR will be produced instead, but only to the extent the producing party has created OCR as of the time the documents are first produced in this litigation, consistent with Section B (1) of this agreement.
b) Any such Extracted Text or OCR will be produced on a document level as .TXT files, with the Text filename matching the Bates number applied to the first page of the corresponding image file followed by .TXT. Text files will be located in a directory named "TEXT" that is separate from the TIFF image. Text files should indicate page breaks. Text files shall include and be searchable for all text, including text in all foreign languages present in the subject ESI. Foreign characters shall be accurately represented and included. Text files containing foreign, non-English, language text must be produced in Unicode Transformation Format (UTF)-16 format. Documents which in their original form include multiple languages shall be produced in such form. Foreign language documents shall be segregated by language and by custodian.
5. Production of Load/Unitization Files
a) There will be two Load/Unitization files accompanying all productions of ESI. One will be a Metadata import file, in.DAT format, that contains the agreed-upon Metadata fields in an ASCII text file using either Concordance default delimiters or ^ carat and pipe delimiters to separate the fields and records. The second data file will be a cross-reference file that contains the corresponding image information [IDX]. The acceptable formats for the cross-reference files are .LOG, [.DII], .OPT, .LFP. Image load files should indicate page breaks. A path to the corresponding .TXT file shall be included as a field in the Metadata import file.
b) The appropriate Metadata import file will contain the Metadata fields detailed and described in Exhibit A to this stipulation and incorporated herein by reference, associated with each electronic document (or their equivalents), including the body of the document, to the extent the fields exist as electronic Metadata associated with the original electronic documents or are created as part of the electronic data discovery process. The parties agree that party-specific exceptions to the required fields in Exhibit A will be memorialized in separate side letter agreements. The attached list of fields does not create any obligation to create or manually code fields that are not automatically generated by the processing of the ESI, or that do not exist as part of the original Metadata of the document; provided however, the producing party must populate the SOURCE and CUSTODIAN fields for all produced ESI, as well as paper Documents converted to electronic form as of the time the documents are first produced in this litigation, regardless of whether these fields would be generated during typical processing of such documents. A producing party shall have no obligation to provide FILEPATH information for documents that a receiving party specifically requested and the producing party collected by document type.
c) Any Native Files produced will be accompanied with a Metadata import file that shall contain (i) the full directory path and file names of the Native File(s) as contained in the produced media and (ii) a uniform hash calculation field.
6. Processing Specifications
a) When processing ESI, GMT should be selected as the time zone. To the extent that a party has already processed ESI using a different time zone, the producing party will note the time zone used in its processing. Parties shall consistently produce all ESI processed using the same time zone.
b) When processing ESI for review and for production in TIFF format, the producing party will instruct its vendor to force off Auto Date and force on hidden columns or rows, hidden worksheets, speaker notes, track changes, and comments.
7. General
a) The producing party shall use reasonable efforts to avoid producing system and application files.
b) If the producing party redacts all or any portion of a Static Image, redactions not clearly indicated on the Static Image shall be noted in a user-generated field specified in Exhibit "A", which the producing party shall provide in the appropriate Load/Unitization file.
c) The parties may de-duplicate identical ESI vertically, by custodian, or horizontally (i.e., globally). All custodians who were in possession of a de-duplicated Document must be identified in the CUSTODIAN OTHER Metadata field specified in Exhibit "A", and all BCC recipients whose names would have been included in the BCC Metadata field but are excluded as the result of horizontal/global de-duplication, must be identified in the BCC OTHER Metadata field specified in Exhibit "A".
d) Bates number and any confidentiality designation should be electronically branded on each produced TIFF image.
III. TERM OF AGREEMENT
This Agreement shall continue in full force and effect until further order or until this litigation is terminated by a final judgment.
SO STIPULATED AND AGREED TO:
DATED: November 6, 2012 COTCHETT, PITRE & McCARTHY, LLP
By: /s/ Eric Buescher
ERIC J. BUESCHER
JUSTIN T. BERGER
Attorneys for Plaintiff
DATED: November 6, 2012 SEVERSON & WERSON
A Professional Corporation
By: /s/ Philip Barilovits
PHILIP BARILOVITS
Attorneys for Defendant
IT IS SO ORDERED
Exhibit A
Metadata Fields for Production
Note: Metadata Field names may vary depending on the application that generates them. For example, Microsoft Outlook creates different Metadata Field names than does Lotus Notes. Accordingly, the chart below describes the Metadata Fields to be produced in generic, commonly used terms which the Producing Party is to adapt to the specific types of ESI it is producing. Any ambiguity about a Metadata Field is to be discussed with the Receiving Party prior to processing the subject ESI for production.
Field Definition Doc
Type
1 SOURCE Name of party producing the document All
2 CUSTODIAN Name of person from whose files the document All
is produced
3 CUSTODIAN Name of person(s), in addition to the Custodian, All
OTHER from whose files the document would have been
produced if it had not been de-duplicated.
4 BEGBATES Beginning Bates Number (production number) All
5 ENDBATES End Bates Number (production number) All
6 PGCOUNT Number of pages in the document All
7 FILESIZE File Size All
8 APPLICAT Application used to create document All
9 FILEPATH File source path for all electronically collected All
documents, which includes location, folder
name, file name, and file source extension
10 NATIVEFILELINK For documents provided in native format only All
11 TEXTPATH File path for OCR or Extracted Text files per All
paragraph (d) above
12 REDACTED User-generated field that will indicated All
redactions made to Static Images, if such
redactions are not clearly indicated on the Static
Image
13 FOREIGNLANG The existence of any foreign (non-English) All
language text in a document, as identified during
processing or review by the producing party
14 HANDWRITING The existence of any handwritten text in a All
document, as identified during processing or
review by the producing party
15 MSGID Hash or SHA Value for Emails Email
16 FROM Sender Email
17 TO Recipient Email
18 CC Additional Recipients Email
19 BCC Blind Additional Recipients Email
20 BCC_OTHER Blind Additional Recipients who would have Email
shown in the "BCC" field had the originally sent
Native email not been de-duplicated.
21 SUBJECT Subject line of email Email
22 PARENTBATES Begin bates number for the parent email of a Email
family (will not be populated for documents that
are not part of a family)
23 ATTACHBATES Bates number from the first page of each Email
attachment
24 BEGATTACH First Bates number of family range (i.e. Bates Email
number of the first page of the parent email)
25 ENDATTACH Last Bates number of family range(i.e. Bates Email
number of the last page of the last attachment)
26 ATTACHCOUNT Number of attachments to an email Email
27 ATTACHNAME Name of each individual attachment Email
28 DATESENT Date Sent Email
(mm/dd/yyyy)
29 TIMESENT Time Sent Email
30 DATERCVD Date Received Email
31 TIMERCVD Time Received Email
32 CAL_START Calendar/Appointment start date and time Email,
Various
33 MSGCLASS Type of item, e.g. email, calendar item, contact, Email,
note, task Various
34 Attendees/ Calendar/Appointment Email,
Participants Attendees/Participants/Recipients Various
35 HASHVALUE MD5 Hash or SHA Value for Edocs Edocs
36 RECORDTYPE Descriptive field created by the vendor All
processing software (e.g. email, edoc, image,
attachment)
37 TITLE Title field value extracted from the metadata of Edocs
the native file.
38 AUTHOR Creator of a document Edocs
39 DATECRTD Creation Date Edocs
(mm/dd/yyyy)
40 TIMCRTD Creation Time Edocs
41 LASTAUTHOR Last Saved field contained in the metadata of the Edocs
native file
42 LASTMODD Last Modified Date Edocs
(mm/dd/yyyy)
43 LASTMODT Last Modified Time Edocs
44 FILEEXT File extension of the native file (e.g., XLS, DOC, All
PDF)
45 MAILSTORE Original path of mail store Email,
various
46 SENSITIVITY Sensitivity field extracted from native email Email,
message or other Outlook item. various
47 CONVERSATION I Email thread identifier. Email
NDEX
