*1 Plaintiff, MedIdea, L.L.C., and Defendants DePuy Orthopaedics, Inc., DePuy Synthes Products, Inc. and DePuy Synthes Sales, Inc. d/b/a DePuy Synthes Joint Reconstruction, by their respective counsel, have stipulated and agreed to this proposed order regarding the production of documents and electronically stored information. The Court, having reviewed the parties' proposed stipulated order, adopts the parties' stipulation and agreement, and orders:

A. DEFINITIONS

A.1. “Document” or “documents” is defined to be synonymous in meaning and equal in scope to the usage of this term in Federal Rules of Civil Procedure 26 and 34 and the Local Rules of this Court.

A.2. “Email” means electronic messages sent or received asynchronously, including any documents incorporated as attachments, including, but not limited to, industry-standard applications like Microsoft Outlook, Google Gmail or Lotus Notes.

A.3. “ESI” is an abbreviation of “electronically stored information” and shall have the same meaning and scope as it has in the Federal Rules of Civil Procedure.

A.4. “Extracted Text” means the text extracted from a Native Format file and includes at least all header, footer and document body information.

A.5. “Hard Copy Document” means a Document that was maintained in paper form at the time this Stipulated Order was entered.

A.6. “Load File” means an electronic file that is used to import all required production information into a document database, including document images, extracted or OCR text, native files where required, and metadata, as well as information indicating document and page breaks, and document relationships such as those between an email and its attachments and between a document and information related to embedded content.

A.7. “Metadata” means structured information about ESI that is created by the file system or application, embedded in the Document or Email and sometimes modified through ordinary business use. Metadata of the ESI describes, inter alia, the characteristics, origins, usage and validity of the collected ESI.

A.8. “Native Format” means the format of ESI in the application in which such ESI was originally created.

A.9. “OCR” means the optical character recognition technology used to read electronic images of Hard Copy Documents and to output readable content of such documents to a searchable text format. The latter text is also referred to as the “OCR text” or simply “OCR.”

A.10. “Party” or “Parties” means, individually or collectively, the Plaintiff and Defendants in the above-captioned action. As appropriate, “Party” can also refer to third parties, if any, who choose or are ordered to produce documents or ESI in this action under the terms of this Order.

A.11. “Producing Party” means a Party that produces documents.

A.12. “Receiving Party” means a Party to whom documents are produced.

A.13. “Tagged Image File Format,” “TIFF,” “.TIFF,” or “.TIF” refers to the CCITT Group IV graphic file format for storing bit-mapped images of ESI or Hard Copy Documents.

B. SCOPE

*2 B.1. The procedures and protocols set forth in this Stipulated Order shall govern the format and processing of Documents or ESI produced by the Parties in the above-captioned matters, to the extent available. Any practice or procedure set forth herein may be modified only by written agreement of the Parties subject to approval by the Court.

B.2. The Parties do not waive any objections to the production, discoverability, admissibility, or confidentiality of Documents, including, without limitation, objections regarding the burden, overbreadth or relevance of document requests related to Documents. This Stipulated Order does not define the scope of production, nor the relevance of any particular information. The discovery requests, objections thereto, agreements of the Parties, and any Court orders in the above-captioned actions shall govern the scope of documents to be produced.

B.3. Nothing in this stipulation is intended to alter the parties' obligations under Federal Rule of Civil Procedure 26(b)(2)(B) and 34(a)(1).

B.4. Nothing in this Stipulated Order is intended to be an exhaustive list of discovery obligations or rights of a Producing Party or a Requesting Party. To the extent additional obligations or rights not addressed in this Order arise under the Federal Rules of Civil Procedure, local rules, or applicable state and federal statutes, they shall be controlling.

B.5. The Parties shall make reasonable efforts to comply with and resolve any differences concerning compliance with this Stipulated Order. If the Parties are unable to reach agreement, the Parties shall submit any dispute to the Court for resolution.

C. PRODUCTION FORMAT

C.1. This Stipulated Order shall govern the production format of Documents and ESI, to the extent available. This Stipulated Order does not govern any procedures or criteria used to limit the scope of production, such as identification and preservation of potentially responsive data types and systems, custodian selection, or any technology-assisted culling or review processes, such as the use of keyword search terms.

C.2. The Parties shall produce Hard Copy Documents and ESI according to the specifications provided in Exhibit A, subject to paragraph C.5. below.

C.3. A Producing Party is only required to produce a single copy of any document. A Producing Party may de-duplicate ESI across its custodians or sources, but if that option is exercised, the Producing Party shall identify each custodian who had a copy of the produced document in the CustodianAll field in the Metadata Load File. De-duplication shall be based on MD5 or SHA-1 hash values, and each Producing Party must disclose the methodology it uses to de-duplicate. However, (i) de-duplication shall be performed only at the document family level so that attachments are not de-duplicated against identical stand-alone versions of such documents and vice versa; (ii) attachments to Emails or other Documents shall not be disassociated from the parent Email or Document, even if they are exact duplicates of another Document in the production; and (iii) Hard Copy Documents may not be eliminated as duplicates of responsive ESI if there is anything written on the Hard Copy Document that makes it different from the electronic copy. A party may only de-duplicate “exact duplicate” Documents and may not de-duplicate “near duplicate” Documents, both of the quoted terms in this sentence being given their ordinary meaning in the e-discovery field. Common system files defined by the NIST library (http://www.nsrl.nist.gov/) need not be produced.

*3 C.4. The Parties will make reasonable efforts to ensure that all encrypted or password-protected Documents reasonably believed to contain responsive material are successfully processed for review and production under the requirements of this Stipulated Order, and that any such decrypted Document believed to be non-privileged and responsive is produced. To the extent encrypted or password-protected Documents are successfully processed according to the requirements of this Stipulated Order, the Parties have no duty to identify the prior encrypted status of such Documents. To the extent such Documents are not successfully processed, the Producing Party agrees to: (a) produce a slipsheet for each encrypted or password protected Document that cannot be successfully processed indicating that the Document cannot be decrypted; and (b) provide the metadata for the Document required by Exhibit A to the extent it can be reasonably extracted from the file in its encrypted form. Nothing in this Stipulated Order shall be deemed to require a Producing Party to process or review for production any encrypted files that do not appear reasonably likely to contain responsive material. The Parties shall meet and confer regarding any requests that a Producing Party undertake additional efforts to decrypt files after production.

C.5. Microsoft Excel, Access, and other spreadsheet files, PowerPoint files, Word files containing tracked changes, comments, or hidden text, video and audio files, and animation files (together, “Native Files”) shall be produced in Native Format. For any Document produced in Native Format, a single-page TIFF image shall be produced with the legend “Document Produced in Native Format”. If a Document to be produced in Native Format contains privileged information, the Document will be produced in redacted TIFF format, or in redacted Native Format, at the Producing Party’s discretion, to the extent reasonably and technically possible. To the extent Documents that fall under this paragraph contain privileged information that cannot be redacted or produced in either TIFF or native format, such Documents will be logged on a privilege log consistent with applicable Orders in this proceeding. To the extent Documents that fall under this paragraph contain non-responsive information, such documents will be redacted in either redacted TIFF format or natively, with a notation on the redacted page(s) indicating “Redacted—Non-Responsive” (or similar language). The Metadata Load Files shall contain a link to the Native Files via fielded data values called “Native Link.” The Native Link values should contain the full directory path and file name of the file as contained in the produced media. Each Party reserves the right to request production of ESI in Native Format for any ESI that is not adequately represented in the TIFF format specified in Exhibit A, and such requests will not be unreasonably denied.

C.6. In Hard Copy Documents, each page of paper should be output to a single page TIFF file. Distinct, logical Document breaks should be defined as such in a standard Opticon Load File as described in Exhibit A. In the case of an organized compilation of separate Documents (e.g., a binder containing several separate Documents behind numbered tabs) the Document behind each tab should be scanned separately, but any Document or family relationship among the scanned Documents in the compilation should be reflected in the data Load File at the appropriate standard fields. Pages containing post-it notes or other detachable notes that obscure the underlying Document should be scanned once with the detachable note intact, and then again without it, and made part of the same Document. The Parties will make reasonable efforts to unitize the Documents correctly, but are not obligated to unitize documents beyond the unitization that exists as maintained in the ordinary course of business.

C.7. Each page of a Document produced in TIFF format shall contain a legible control number that is unique across the Document production (the “Document Number”), has a constant length (0-padded) across the production, and is sequential within a given Document. The Document Number for each Document shall be created so as to identify the Producing Party and the Document Number (e.g., “US00000000”) and may contain an underscore or dash between the prefix and the Document Number. Each Party’s document numbering scheme shall use the unique identifying name agreed upon by the Parties. If a Document Number or set of Document Numbers is skipped in a production, the Producing Party shall notify Receiving Party in a cover letter to the production that the production contains skipped Document Numbers and shall identify the skipped numbers. The Document Number shall be placed on the page image in a manner that does not conceal or interfere with any information contained on the page. Any confidentiality designation shall be placed on the page image in a manner that does not conceal or interfere with any information contained on the page. No other stamp or information will be placed on a Document other than any redactions. This does not apply to Excel spreadsheets or other files produced in Native Format. Each electronic file produced in Native Format shall be assigned a unique Document Number and, as applicable, a suitable confidentiality designation (e.g., “ABC0000002_Confidential”), and the database record for that file shall include a single-page TIFF image branded with this unique Document Number in the lower right corner of the image as a control number, with the phrase “PRODUCED IN NATIVE FORMAT” (or similar language) branded in the center of the page. To protect the confidentiality of files produced in Native Format, any confidentiality designations must appear on the associated TIFF placeholder on the lower left hand comer in no less than 10-pt font.

*4 C.8. The Parties are not obligated to populate manually any of the fields in Exhibit A if such fields cannot be extracted from a Document, with the exception of the following: (a) BegBates, (b) EndBates, (c) BegAttach, (d) EndAttach fields, (e) Custodian, (f) Paper (Y/N), (g) NativeFile (Y/N), (h) ProdVolume, (i) ParentBates, and (j) AttachBates.

C.9. The Producing Party may produce Document images, native files, Load Files, text and/or OCR files, and Metadata on hard drives, CDs, DVDs, secure FTP, or other mutually agreeable media (“Production Media”). Productions made via FTP or other electronic transfer are not required to be supplemented with hard media containing the same Documents. Each piece of Production Media shall include a unique identifying label corresponding to the identity of the Producing Party, the date of the production of Documents on the Production Media and the Document Number ranges of the Documents in that production (e.g., “USG Production September 1, 2013, US00000123-US00000456”). To the extent that the Production Media includes any confidential information, the label on such Production Media shall indicate that the Production Media includes information so designated. Production Media shall include text referencing the case name and number. Further, any replacement Production Media shall cross-reference the original Production Media, clearly identify that it is a replacement, and cross-reference the Document Number range that is being replaced. All Production Media that is capable of write protection should be write-protected before production. All Production Media may be encrypted, with Producing Party to provide a decryption key at the time of production.

C.10. To the extent a response to discovery requires a Party to provide documents from a production set of a prior litigation or investigation, such Party may produce the documents from the production set as they were produced in the prior action and shall not be required to provide any metadata fields that were not produced in the prior action. Notwithstanding this provision, the Parties retain the right to object to the production of documents from prior litigation or investigations.

C.11. Unless otherwise mutually agreed by the Parties, video files are to be produced in the native video file format in which they were maintained in the ordinary course of business, unless redactions are needed. If redactions are needed, the redacted media file may be produced either in the original Native Format or in a standard media format. The Producing Party shall clearly indicate which segments of a video file have been redacted.

C.12. Audio files are to be produced in the native audio file format in which they were maintained in the ordinary course of business, unless redactions are needed. If redactions are needed, the redacted audio file may be produced either in the original Native Format or in a standard media format. The Producing Party shall clearly indicate which segments of an audio file have been redacted.

C.13. Parties producing native documents in lieu of TIFFs shall comply with the applicable specifications for load files, including extracted text, as provided under this Stipulated Order.

C.14. Nothing in this Stipulated Order shall alter any Party’s obligation to retain Native Format copies, including associated Metadata, of all ESI preserved for and produced in the litigation or original versions of all hard-copy Documents preserved for and produced in the litigation. Nothing in this Stipulated Order alters a Party’s obligation to retain data pursuant to the Federal Rules of Civil Procedure, the Local Rules of this Court, or Court Order.

*5 C.15. Nothing in this Stipulated Order shall be interpreted to require disclosure of irrelevant information or relevant information protected by the attorney-client privilege, work product immunity, or any other applicable privilege. The Parties do not waive any objections as to the production, discoverability, admissibility, or confidentiality of Documents or ESI.

D. PROCESSING SPECIFICATIONS

The Producing Party shall collect and process Documents using industry-standard methods that avoid spoliation of data. The Producing Party will use reasonable efforts to generate and preserve the MD5 hash values of all ESI based on the non-spoliated source native file. The Producing Party shall use the following specifications when converting ESI from its Native Format into TIFF image files prior to its production:

D.1. All ESI shall be processed with a single time zone and a date and time setting that is consistent across each Parties' productions. The time zone used for a production shall be specified either as set forth in Exhibit A or by otherwise notifying the Receiving Party.

D.2. All TIFF images shall display tracked changes, comments, and other rich data as displayed in the Document, regardless of the display setting for this information as last saved by the custodian, to the extent technically possible.

D.3. Email threads are email communications that contain lesser-included email communications that also may exist separately in the Party’s electronic document collection. A most-inclusive email is one that contains unique content and all the lesser-included emails, including attachments, for that branch of the email thread. The parties need not individually produce such lesser-included emails if the lesser-included emails contain no unique content from the parent email thread.

D.4. Absent a Party’s specific written notice for good cause, (a) the following categories of ESI are presumed to be inaccessible and not discoverable: (i) ESI deleted in the normal course of business before the time a preservation obligation in this matter came into effect; (ii) Backup data files that are maintained in the normal course of business for purposes of disaster recovery, including (but not limited to) backup tapes, disks, SAN, and other forms of media, and that are substantially duplicative of data that are more accessible elsewhere; (iii) Deleted, “slack,” fragmented, or unallocated data only accessible by forensics; (iv) Random access memory (RAM), temporary files, or other ephemeral data that are difficult to preserve without disabling the operating system; (v) On-line access data such as (without limitation) temporary internet files, history files, cache files, and cookies; (vi) metadata fields such as last-opened or last-printed dates; (vii) Electronic data (e.g., call logs, email, calendars, contact data, notes, etc.) sent to or from mobile devices (e.g., iPhone, iPad, Android, and Blackberry devices), if a copy of such electronic data is reasonably accessible for production elsewhere (such as on a server, laptop, desktop computer, or ‘cloud’ storage); (viii) Voicemail, including Telephone or VOIP voice messages, unless the voicemail is recorded in email (automatic email sent to inbox with voicemail recording); (ix) Text messages and instant messages that are not retained in the ordinary course of business; (x) Server, system, network, or software application logs; (xi) Data remaining from systems no longer in use that is unintelligible on the systems in use; (xii) Electronic data temporarily stored by laboratory equipment or attached electronic equipment, provided that such data is not ordinarily preserved as part of a laboratory report; (xiii) Files included on the National Institute of Standards and Technology (NIST) List (http://www.nsrl.nist.gov/); (xiv) Structural files not material to individual file contents (e.g. .CSS, .XSL, .XML, .DTD, etc.); (xv) Operating System files that do not store user-created content (e.g. CAT, DLL, DMP, EXE, FON, PNF, OPS, SYS etc.); (xvi) Application source code, configuration, and other similar files necessary for the function of an application that do not store user-created content during ordinary use (E.g. BAK, BIN, CFG, DBF, DAT, JS, JSON, JAR, LUA, MSB, RES, WINNT, YTR etc.); and (b) no Party shall be required to modify or suspend procedures, including rotation of backup media, used in the normal course of business to back up data and systems for disaster recovery purposes, as long as such procedure does not conflict with the required litigation hold for this matter.

*6 D.5. The unintentional production of any material constituting or containing attorney-client privileged information or work-product, or constituting or containing information protected by applicable privacy laws or regulations, shall be governed by provisions contained in the Protective Order entered in this action.

It is so ORDERED.

EXHIBIT A

1. Production of Information

ESI is to be produced in 300 DPI Group IV Monochrome Tagged Image File Format (.TIFF or .TIF) files. .TIFF files shall be produced in single-page format along with image load files (.DII file and .OPT file and .LFP file). All Documents are to be provided with multi-page searchable text (.TXT) files. These text files and image load files should indicate page breaks to the extent possible.

During the process of converting ESI from the electronic format of the application in which the ESI is normally created, viewed, or modified to .TIFF, Metadata values should be extracted and produced in a Load File (“Metadata Load File”). Each Document production shall be accompanied by two Load Files: an image Load File and a Metadata Load File. Those Load Files shall be produced in Concordance format (.DAT file using Concordance standard delimiters for the Metadata Load Files, and .OPT file using Concordance standard fields for the image Load Files). The image Load File shall provide image and document break information for the .TIFF files produced that correspond to the beginning control number contained in the Metadata Load File. Every .TIFF file in each production must be referenced in the production’s corresponding image Load File. The total number of .TIFF files referenced in a production’s image Load File should match the number of .TIFF files in the production.

To the extent they are available, the Metadata values that are to be extracted and produced in the Metadata Load Files (.DAT file using Concordance standard delimiters and IDX file) are:

2. Metadata Fields

3. Images

4. Full-Text Extraction/OCR