Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1166 Page 1 of 15
`
`
`UNITED STATES DISTRICT COURT FOR THE DISTRICT OF UTAH
`CENTRAL DIVISION
`
`
`
`EAGLE VIEW TECHNOLOGIES, INC., and
`PICTOMETRY INTERNATIONAL CORP.,
`
`
`Plaintiffs,
`
`
`v.
`
`NEARMAP US, INC.,
`
`
`Defendant.
`
`
`DOCUMENT PRODUCTION
`PROTOCOL ORDER
`
`
`Case No.: 2:21-cv-00283
`
`District Judge Ted Stewart
`
`Magistrate Judge Daphne A. Oberg
`
`
`
`
`
`
`Before the court is the parties’ Joint Motion for Entry of Document Production Protocol
`
`Order, (Doc. No. 57). The motion states the parties have agreed to the terms of this order for the
`
`collecting, searching, and producing of the parties’ documents in this case, and intend for this
`
`order to supplement the District of Utah’s Standard Protective Order. Based on the parties’
`
`stipulation, the court GRANTS the motion and ORDERS as follows:
`
`Scope. The following protocol and definitions shall supplement the parties’
`1.
`responsibilities under the Federal Rules of Civil Procedure, and shall control the production of
`Documents, including electronically stored information (“ESI”) in the matter of Eagle View
`Technologies, Inc. et al. v. Nearmap US, Inc., pending in the District of Utah, Docket No. 2:21-
`cv-00283 (“Litigation”). Nothing herein shall enlarge or affect the proper scope of discovery in
`the Litigation, nor shall anything herein imply that any Documents or ESI produced under the
`terms of this protocol are properly discoverable, relevant, or admissible in this action or in any
`other litigation. Further, nothing in this agreement, including any provisions related to search
`methodology in section 16, shall excuse a party from searching for and producing Documents from
`locations (including both paper and electronic files) it knows or reasonably believes to have
`responsive information.
`
`2.
`
`Definitions. The following terms shall be defined:
`
`
`
`1
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1167 Page 2 of 15
`
`“Document(s)” means all data compilations, correspondence, e-mails (hard
`(a)
`copy or in digital form), memoranda, notes, desk calendars, diaries, statistics, letters, minutes,
`contracts, reports, studies, checks, invoices, statements, receipts, returns, warranties, guarantees,
`summaries, pamphlets, books, prospectuses, offers, notations of any sort of (i) conversations, (ii)
`telephone calls, or (iii) meetings or other communications, bulletins, magazines, publications,
`printed matter, photographs, computer printouts, worksheets and all drafts, alterations,
`modifications, changes and amendments of any of the foregoing, tapes, tape recordings,
`transcripts, graphic or aural records, and electronic, mechanical, electric, magnetic, or digital
`records or other tangible materials of whatever kind known to, and in the possession, custody, or
`control of the Producing Party.
`
`“Native File(s)” or “Native Format” means the format ESI was created or
`(b)
`maintained by its associated software program. For example, Microsoft Excel produces its output
`as “.xls” or “.xlsx” files by default, which is the Native Format of Excel. Microsoft Word produces
`native files with a “.doc” or “.docx” extension, which is the Native Format of Word. Parties shall
`make a reasonable effort to collect, process and produce Native Files (if the Native Files are
`otherwise required to be produced) in a manner such that all files reflect accurate metadata
`associated with the creation and maintenance of the files and are not corrupted by the methods of
`the collection of the data.
`
`“Source Code” means information, document, or thing, or portion of any
`(c)
`document or thing that includes human-readable programming language text that defines software,
`firmware, or electronic hardware descriptions of the Producing Party. Source Code includes text
`files containing Source Code, which shall hereinafter be referred to as “Source Code Files.”
`Source Code Files include, but are not limited to files containing Source Code written in C, C++,
`Java, assembler, VHDL, Verilog, SQL, and similar programming languages. Source Code Files
`further include “make” files, “include” files, script files, “link” files, and other human-readable
`text files used in the generation and/or building of software directly executed on a
`microcompressor, microcontroller, or digital signal processor (DSP). Source Code does not
`include operational versions of software, executable files, including binary executable files, and
`object code files, nor does it include tools such as compilers or linkers. To the extent that the
`parties agree that selected pages of the Source Code may be printed in hard copy, such Source
`Code shall be marked as “CONFIDENTIAL INFORMATION – SOURCE CODE including any
`information, document, or thing, or portion of any document or thing that includes Source Code.
`
`(d)
`
`“Metadata” means broadly any data about data.
`
`“Static Image(s)” means a representation of ESI produced by converting a
`(e)
`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.
`
`“Load/Unitization file” means an electronic file containing information
`(f)
`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
`
`
`
`2
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1168 Page 3 of 15
`
`and ends. A Load/Unitization file will also contain data relevant to the individual Documents, for
`example, fielded data and information necessary for the loading of OCR or Extracted Text.
`
`“OCR” means the optical character recognition file which is created by
`(g)
`software used in conjunction with a scanner that is capable of reading text-based documents and
`making such documents searchable using appropriate software.
`
`“Extracted Text” means the text extracted from a Native File and includes
`(h)
`all header, footer, and document body information.
`
`“Receiving Party” shall mean the party receiving production of Documents
`(i)
`in response to any request for production of document(s) pursuant to Fed. R. Civ. P. 34(a) or
`pursuant to initial production of documents identified in the party’s Rule 26(a) disclosures.
`
`“Producing Party” shall mean the party producing Documents in response
`(j)
`to any request for production of documents pursuant to Fed. R. Civ. P. 34(a) or pursuant to initial
`production of documents identified in the party’s Rule 26(a) disclosures.
`
`General Format of Production. Subject to the provisions of paragraph 4,
`3.
`Documents that are produced in these proceedings, whether or not such Documents are ESI, shall
`be produced in TIFF form, or native form where necessary, in the manner as described below. The
`parties may also produce color image Documents as Joint Photographic Experts Group (JPEG)
`files provided that the files comply with the specifications of this protocol applicable to TIFF files.
`Notwithstanding the foregoing provisions of this paragraph, the Parties reserve the right to request
`that an alternative format or method of production be used for certain Documents, if such
`Document is not susceptible to production in the format or methods of production addressed
`herein. In that event, the Receiving Party and the Producing Party will meet and confer to discuss
`alternative production requirements, concerns, formats, or methods.
`
`4.
`formats:
`
`Production Format. Documents shall be produced according to the following
`
`Electronic Production of Paper Documents. Documents that are maintained
`(a)
`in paper format shall be scanned as black and white images at 300 x 300 d.p.i., in a Group 4
`compression single-page Tagged Image File Format (“TIFFs,” “.tiff format,” or “.tif format”) and
`reflect the full and complete information contained in the original Document. Documents shall
`also be produced with the associated OCR in accordance with 4(c). No Producing Party shall be
`required to ensure that the OCR is an exact duplicate of the contents of the TIFF image; and the
`Receiving Party shall accept the OCR in its “as is” condition.
`
`Electronically Stored Information. Except as provided in Paragraph 4(e)
`(b)
`below, Document images shall be generated from electronic Documents in a Group 4 compression
`single-page “TIFF” image that reflects the full and complete information contained on the original
`document, together with a load file or functional equivalent specified in Paragraph 4(c) that
`contains the metadata as set forth in Paragraph 13, to the extent such metadata exists. In the event
`
`
`
`3
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1169 Page 4 of 15
`
`a Document is redacted, the Producing Party shall withhold the redacted text for that Document
`and any metadata that is the subject of the redaction. The failure to withhold such text for a
`redacted document by a Producing Party shall not be deemed a waiver of the privilege associated
`with that Document. Extracted text will be provided for the non-redacted text.
`
`Load/Unitization File Structure. The Producing Party shall produce a
`(c)
`unitization file (“load file”) compatible with Concordance or a comparable document management
`and review system, with delimited data files (commonly .DAT files), for all produced Documents
`in accordance with the following formatting:
`
`Document Unitization Load File:
`
`• Document productions should include a Concordance document load files.
`• Metadata provided in a delimited file as described below under the subheading of
`“Metadata Load File.”
`
`OCR and Extracted Text Files (.TXT Files):
`
`• Single text file per document containing all the document’s pages
`• Pages separated by form feed character
`• Filenames should be of the form:
`<Bates num>.txt, where <Bates num> is the BATES number of the first page in the
`document.
`
`Image Files:
`
`• Single page per image
`• Single image per file
`• TIFF is default FORMAT. In the event the Receiving Party requests specific
`documents in a format other than TIFF, the Receiving Party and the Producing Party
`will meet and confer with respect to such production as set forth in Paragraph 3.
`should
`be
`of
`the
`form:
`<Bates
`num>.<ext>
`• Filenames
`Where <Bates num> is the BATES number of the page, and <ext> is the appropriate
`extension for the image format (.jpg, .tif, .png, etc.)
`
`
`
`
`
`
`
`Resolution of Production Issues. Documents that cannot be read because of
`(d)
`imaging or formatting problems shall be promptly identified by the Receiving Party. The
`Producing Party and the Receiving Party shall meet and confer to attempt to resolve problem(s),
`to the extent the problem(s) are within the Parties’ control.
`
`Native Format Documents. The Producing Party shall produce Microsoft
`(e)
`Excel, Microsoft Access, video, and audio files in native format, unless there is an agreement to
`the contrary. Prior to producing any confidential information as defined in any applicable
`Protective Order entered herein in Native Format, the Producing Party and the Receiving Party
`
`
`
`4
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1170 Page 5 of 15
`
`shall meet and confer to establish additional procedures, to the extent necessary, for the protection
`of the native information.
`
`Nothing in this Document Production Protocol shall eliminate or
`(i)
`
`alter any Party’s obligation to retain native format copies, including associated metadata, of all
`ESI produced in this litigation and original hard copy documents for all non-ESI produced in this
`litigation.
`
`Production Media. A Producing Party shall produce Documents on a CD-ROM,
`5.
`DVD, external hard drive, or such other readily accessible computer or electronic media as the
`Producing Party and the Receiving Party may hereafter agree upon (the “Production Media”).
`Information that shall be identified on the face of the Production Media shall include: (1) the
`production date, and (2) the confidentiality notation required by the Protective Order entered in
`this case, if the media contains Confidential Information, as defined in the Protective Order. The
`face of the Production Media shall also contain the Bates Number range(s) of the Documents on
`the Production Media, and where not practicable to do so, may be provided in an accompanying
`letter. If the Producing Party encrypts or “locks” the production, the Producing Party shall provide
`under separate cover, an explanation of how to decrypt the files.
`
`At the discretion of the Producing Party, Documents may be produced by File Transfer
`Protocol (FTP) or Secure File Transfer (SFT). When Documents are produced in this manner, the
`Producing Party may forego delivering the Documents to the Receiving Party on Production Media
`as described above.
`
`Third-Party Software. To the extent that documents produced pursuant to this
`6.
`Document Production Protocol cannot be rendered or viewed without the use of proprietary or
`third-party software, 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 which are the
`property of a third party.
`
`Document Unitization. When scanning paper documents into Document Images as
`7.
`described in paragraph 4(a), they shall be unitized in a manner so as to maintain the document(s)
`and any attachments, as they existed in their original state, to the extent reasonably possible. For
`electronic documents, the relationship of documents in a document collection (e.g., cover letter
`and enclosures, e-mail and attachments, binder containing multiple documents, or other documents
`where a parent-child relationship exists between the documents) shall be maintained through the
`scanning or conversion process from native format to TIFF, provided however, that the Parties
`shall only be required to present one level of parent child relationship. Document Images
`generated from attachments
`to e-mails stored
`in Native Format shall be produced
`contemporaneously and sequentially immediately after the parent e-mail. All hard copy
`documents imaged and produced electronically shall include a unitization file (“load file”) in
`accordance with paragraph 4(c).
`
`
`
`5
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1171 Page 6 of 15
`
`Paper Documents Containing Fixed Notes. Paper Documents that contain fixed
`8.
`notes shall be scanned with the notes affixed, if it can be done so in a manner so as not to obstruct
`other content on the document. If the content of the Document is obscured by the affixed notes,
`the Document and note shall be scanned separately.
`
`Duplicates. Where a Producing Party has more than one identical copy of an
`9.
`electronic document as determined through a verifiable MD5 Hash de-duplication process (i.e.,
`the documents are actual duplicates or duplicates determined by the e-discovery vendor software),
`the Producing Party need only produce a single copy of that document (as long as all family
`relationships are maintained). A Producing Party need not produce the same electronically stored
`information in more than one form.
`
`10.
`follows:
`
`Bates Numbering. Each Producing Party shall Bates number its production(s) as
`
`Document Images. Each page of a produced Document shall have a legible,
`(a)
`unique page identifier (“Bates Number”) electronically “burned” onto the image at a location that
`does not unreasonably obliterate, conceal, or interfere with any information from the source
`document. The confidentiality legend, if any, shall be “burned” onto each document’s image at a
`location that does not unreasonably obliterate or obscure any information from the source
`document. Redacted documents will be so identified by electronically “burning” the legend
`“Redacted” onto each document’s image at a location that does not unreasonably obliterate or
`obscure any information from the source document.
`
`Native Format Documents. Documents produced in Native Format will be
`(b)
`produced with a placeholder TIFF image. Each TIFF placeholder will contain the Bates number
`and confidentiality designation, if any. Native format files shall be labeled with a Bates prefix,
`number, abbreviated designation under any applicable Protective Order, and original file
`extension.
` For example, a native format file named “123.xls”
`that
`is designated
`“CONFIDENTIAL - ATTORNEYS EYES ONLY” with Bates label XYZ000001 would be named
`“XYZ000001-CONF-AEO-123.XLS.”
`
`File Naming Conventions. Each Document Image shall be named with the unique
`11.
`Bates Number for each page of document, as set forth in Paragraph 10 above.
`
`Non-Convertible Files. Certain types of files such as system, program, video and
`12.
`sound files may not be amenable to conversion into anything meaningful in TIFF format. Non-
`convertible files will be produced in native format with a placeholder TIFF image. Some examples
`of file types that may not convert include file types with the following extensions: *.exp : *.exp
`*.ilk *.res *.trg *.tlh *.idb *.pdb *.pch *.opt *.lib *.cab *.mov *.mp3 *.swf *.psp *.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. Other files may not be able to be converted to TIFF for reasons including, but not
`limited to password protection. If reasonable efforts to obtain useful TIFF images of these files
`
`
`
`6
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1172 Page 7 of 15
`
`are unsuccessful, the Receiving Party and the Producing Party will meet and confer with respect
`to such production as set forth in Paragraph 3.
`
`13. Metadata. The Producing Party shall produce the metadata information described
`below with each production and in the format described in Paragraph 4 above, to the extent such
`metadata already exists. Nothing in this paragraph shall be construed to obligate a party to create
`new metadata that is not already in existence at the time of collection of the document. For images
`generated from native electronic documents, a Producing Party shall produce with each production
`the following fields, where reasonably available.
`
`FIELD
`
`
`
`DEFINITION
`
`
`
`1
`
`2
`
`3
`
`4
`5
`
`6
`7
`8
`9
`10
`11
`
`12
`
`CUSTODIAN OR NON-
`CUSTODIAL SOURCE
`
`BEGINBATES
`
`ENDBATES
`
`NATIVELINK
`TEXTPATH
`
`FROM
`TO
`CC
`BCC
`SUBJECT
`BEGATTACH
`
`ENDATTACH
`
`13 DATESENT (mm/dd/yyyy)
`14 TIMESENT (hh:mm:ss TZ)
`15
`FileExtension
`
`16
`17
`
`18
`
`AUTHOR
`ORIGINALFILEPATH
`
`ORIGIN ALFILENAME
`
` Name of the person from whose files
`the document/data is being produced or
`name of data source location if not
`associated with single custodian
` Beginning Bates Number (production
`number)
` Ending Bates Number (production
`number)
` Field containing link to native file
` File path for OCR or Extracted Text
`files
` Sender
` Recipient
` Additional Recipients
` Blind Additional Recipients
` Subject line of Email
` First Bates number of a family range
`(i.e. Bates number of the first page of
`the parent email)
` Last Bates number of a family range
`(i.e. Bates number of the last page of
`the last attachment)
` Date sent
` Time sent
` Document extension (e.g. .doc, .pst,
`.ppt, .xls, .pdf)
` Creator of document
` File path location where document was
`originally saved
` File name initially given when file was
`originally saved
`
`DOC TYPE
`
`ALL
`
`ALL
`
`ALL
`
`ALL
`ALL
`
`EMAIL
`EMAIL
`EMAIL
`EMAIL
`EMAIL
`EMAIL/EDOCS
`
`EMAIL/EDOCS
`
`EMAIL
`EMAIL
`EDOCS
`
`EDOCS
`EDOCS
`
`EDOCS
`
`
`
`7
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1173 Page 8 of 15
`
`
`
`19
`20
`21
`
`22
`
`FIELD
`
`
`
`DEFINITION
`
`DATECREATED
`DATELASTMODIFIED
`HASH
`
`CONFIDENTIALITY
`
` Date (and time) file was created
` Date (and time) file was last modified
` The hash value or “de-duplication key”
`assigned to a document. PID’s for email
`families should also be preserved.
` Confidentiality Designation
`
`DOC TYPE
`
`EDOCS
`EDOCS
`EMAIL/EDOCS
`
`All Docs
`
`
`
`Discovery and Admissibility. Nothing herein shall be construed to affect the
`14.
`discoverability or admissibility of any document or data. All objections to the discoverability or
`admissibility of any document or data are preserved and may be asserted at any time.
`
`15.
`
`Privilege
`
`Consistent with Federal Rules of Civil Procedure, a Party withholding or
`(a)
`redacting any responsive Document on the grounds of privilege, immunity, or any similar claim
`shall provide to the Receiving Party a log containing the information described in paragraph 15(b)
`(“Privilege Log”), except that:
`
`the Parties shall have no obligation to log information generated
`(i)
`
`after the filing of the complaint; and
`
`activities undertaken in compliance with the duty to preserve
`(ii)
`
`information (including, but not limited to, litigation hold letters) are protected from disclosure
`under Fed. R. Civ. P. 26(b)(3)(A) and (B). Notwithstanding the foregoing, if a party makes a
`good-faith assertion that specific documents should have been but were not preserved in the
`anticipation or conduct of litigation, the parties shall timely meet and confer in good faith to
`determine the appropriate scope, if any, of discovery regarding activities undertaken in compliance
`with the duty to preserve information or regarding the alleged failure to preserve such documents.
`In the event that the parties do not reach agreement, the party making the assertion may seek leave
`from the Court to request appropriate discovery. For avoidance of doubt, however, this paragraph
`does not constitute a waiver or other abrogation of the protections provided under Fed. R. Civ. P.
`26, nor does it constitute any concession that activities undertaken in compliance with the duty to
`preserve information (and documents related to those activities) cannot be withheld on the basis
`of the attorney-client privilege, work product, or other immunity to the extent applicable.
`
`For each document withheld or redacted, the Privilege Log shall contain the
`(b)
`following information: an entry number, a production number where an entry corresponds to
`redacted portions of a document, the author(s) of the document, the direct recipient(s) of the
`document, the copied recipient(s) of the document, the date on which the document was created
`or sent, a description of the document, and any privilege(s) asserted.
`
`
`
`8
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1174 Page 9 of 15
`
`To the extent E-mail is searched, any E-mail stream (i.e., a series of E-mails
`(c)
`linked together by-email responses and forwarding) that is withheld or redacted on the grounds of
`privilege, immunity or any similar claim shall be logged by the most recent, i.e., top-most E-mail
`in the stream.
`
`Each member of a family (i.e., E-mail attaching memorandum) that is
`(d)
`withheld or redacted on the grounds of privilege, immunity or any similar claim shall be logged in
`the same entry as the parent E-mail, provided that each such entry describes all attachments that
`are also withheld as privileged.
`
`Search Methodology. The following governs the search methodologies for
`16.
`Producing Party’s keyword searching to locate potentially responsive Documents contained in
`ESI. This Section shall supplement the parties’ obligations under the Federal Rules of Civil
`Procedure and shall not excuse a party from those obligations, including the obligation to search
`for and produce documents from locations (including both paper and electronic files) it knows or
`reasonably believes to have responsive information.
`
`Each Party shall use its best efforts to filter out common system files using
` (a)
`a commercially reasonable hash identification process. Hash values that may be filtered out during
`this process are located in the National Software Reference Library (“NSRL”) NIST hash set list.
`
`(b) With respect to the search terms, a conjunctive combination of multiple
`words or phrases (e.g., “computer” and “system”) narrows the search and shall count as a single
`search term. A disjunctive combination of multiple words or phrases (e.g., “computer” or
`“system”) broadens the search, and thus each word or phrase shall count as a separate search term
`unless they are contextually variants of the same word or phrase. Use of narrowing search criteria
`(e.g., “and,” “but not,” “w/x”) is encouraged to limit the production.
`
`(c)
`
`Search Methodology
`
`The Requesting Party may request the searching and production of
`(i)
`
`custodial data from up to ten (10) individuals identified pursuant to Fed. R. Civ. P. 26(a)(1) or
`other individuals identified by the Requesting Party through any other means, including discovery,
`according to the methodology set forth herein. The Parties may jointly agree to modify these limits
`without the Court’s leave. The Court will consider contested requests for additional individuals
`by the Requesting Party as the case develops and based upon the Requesting Party’s showing of
`need. Regardless of the number of individuals whose custodial documents are searched, the Parties
`will cooperate to identify proper search terms and time frame (e.g., date ranges) on a custodian-
`by-custodian basis. The parties agree that the identification of documents using search terms shall
`be conducted by a third party electronic discovery vendor retained and directed by counsel of
`record.
`
`To the extent a Producing Party elects to use search terms to locate
`(ii)
`
`ESI that may contain potentially responsive Documents for the individuals specifically identified
`by the Requesting Party under paragraph 15(d)(i), the Producing Party shall identify ten (10) search
`
`
`
`9
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1175 Page 10 of 15
`
`terms to be applied to all custodial data. The Producing Party must provide any such search terms
`to the Requesting Party within seven (7) days of the Requesting Party’s identification of a
`custodian for searching and production.
`
`(iii) Within seven (7) days of identifying a custodian for searching and
`
`production, the Requesting Party may additionally propose up to five (5) search terms for the
`custodial data. The search terms shall be narrowly tailored to particular issues, and to the extent
`necessary, the Parties shall meet and confer to reach agreed-to search term lists and reasonable
`date restrictions. The Producing Party shall timely apply all the search terms proposed by both
`Parties to the custodial data, and shall timely provide the Requesting Party with resulting hit counts
`for each individual. The hit counts shall reflect the total number of documents that hit on each
`search term for each such individual, and shall separately identify the total number of responsive
`documents including all parents and attachments to documents that hit on each search term (i.e.,
`families) for each such individual. If requested, the Producing Party shall also timely provide the
`Requesting Party hit counts that reflect the total number of unique documents that hit on each
`search term for each such individual (i.e., documents that contain only that term and no other
`search terms).
`
`(iv) Within ten (10) days of the identification of a custodian for
`
`searching and production, or at a time mutually agreeable, the Parties shall timely meet and confer
`in good faith to determine whether the parties can agree on all search terms to be used for the
`custodial data to ensure that any requested searching and production of ESI is reasonable, narrowly
`tailored for specific and material issues in the case, does not impose an undue burden on the
`Producing Party, and is commensurate with the Producing Party’s obligations under the Federal
`Rules. For example, and without limitation, in the event that a particular search term selected by
`the Requesting Party is resulting in an excessive volume of ESI where that term appears, or
`numerous “false positives” (i.e., non-responsive and/or immaterial documents), the Parties will
`meet and confer in an attempt to further narrow the search requests. Such narrowing may include
`further limiting date ranges or modifying the search terms.
`
`The Producing Party shall not unreasonably refuse additional
`(v)
`
`requests by the Requesting Party to apply additional search terms for an individual where
`circumstances warrant additional searching, provided that such requests are narrowly tailored to
`the circumstances. Examples of such circumstances include, without limitation: (1) an individual
`having possession of information that the Requesting Party could not have anticipated with
`reasonable diligence to be in that individual’s possession, or having possession of information that
`the Requesting Party could not have appreciated with reasonable diligence to be relevant, (2)
`material changes to the Producing Party’s position on legal or factual issues, or (3) rulings or
`decisions of the Court, or changes in applicable law, that change the Requesting Party’s needs for
`discovery or affect the scope of permissible discovery. The burden of showing that any additional
`searching is warranted shall be on the Requesting Party.
`
`In the event of any requests to apply additional search terms
`(vi)
`
`pursuant to paragraph 16(d)(iv), the parties shall timely meet and confer as provided in paragraph
`
`
`
`10
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1176 Page 11 of 15
`
`16(d)(iii) to ensure that any additional requested searching and production of ESI is reasonable, is
`narrowly tailored for specific and material issues in the case, does not impose an undue burden on
`the Producing Party, and is commensurate with the Producing Party’s obligations under the Federal
`Rules.
`
`17.
`
`Processing Specifications
`
`The Producing Party shall collect and process documents using methods
`(a)
`that avoid spoliation of data. The Producing Party shall use the following specifications in this
`paragraph when converting ESI from its native format into TIFF image files prior to production.
`
`All tracked changes shall be maintained, to the extent reasonably feasible
`(b)
`upon collection, so that all tracked changes to a document are evident.
`
`Author comments shall remain or be made visible, to the extent reasonably
`(c)
`feasible upon collection.
`
`(d)
`
`Presenter notes shall be made visible, to the extent reasonably feasible upon
`
`collection.
`
`To the extent reasonably feasible, auto-populated fields, with the exception
`(e)
`of autopopulating “page-number” fields, shall be replaced with text indicating the field name. For
`example, auto-populating “date” fields shall be replaced with the text “DATE.”
`
`To the extent documents in a foreign language are produced, processing of
`(f)
`such documents shall be unicode-compliant.
`
`Notwithstanding the foregoing, a Producing Party may produce Documents
`(g)
`that were produced in a prior litigation in the same manner as they were produced in that litigation
`(e.g., TIFF, native files, etc.). The Producing Party must identify any Documents as having been
`previously produced in another action and include the action for which they were produced. A
`Receiving Party make seek re-production of any such Documents in accordance with the
`processing specifications above, provided the Documents are available to the Producing Party and
`the request is made for good reason.
`
`As used herein, “to the extent reasonably feasible” does not obligate a
`(h)
`Producing Party to obtain new or updated software if the Producing Party’s current software is
`incapable of performing a particular processing specification listed in paragraph 17.
`
`18. CONFIDENTIAL INFORMATION – SOURCE CODE
`
`To the extent that any party wishes to obtain access to material designated as CONFIDENTIAL
`INFORMATION – SOURCE CODE, the following procedures shall apply:
`
`
`
`11
`
`

`

`Case 2:21-cv-00283-TS-DAO Document 58 Filed 02/25/22 PageID.1177 Page 12 of 15
`
`(a) The Producing Party shall make all relevant and properly requested Source
`Code available for inspection on one stand-alone, non-networked personal
`computer