1014-00004 · Hawthorne Vega & Cruz LLP · Discovery

esi-protocol-agreement.docx DOCUMENT Litigation

46 / 168 ← → ✕

Contract analysis Extract to table

UNITED STATES DISTRICT COURT EASTERN DISTRICT OF TEXAS MARSHALL DIVISION

OPTIWAVE SEMICONDUCTOR CORP.,

Plaintiff,

LUMICORE TECHNOLOGIES, INC.,

Defendant.

Case No. 2:24-cv-00319-JRG

The Honorable James R. Gilstrap

AGREED PROTOCOL FOR DISCOVERY OF ELECTRONICALLY STORED INFORMATION

August 15, 2024

Plaintiff Optiwave Semiconductor Corp. ("OWS"), by and through its counsel of record Calderwood & Harkness LLP (Alan Ngo, Responsible Partner; Wendy Schultz, Lead Associate) and local counsel Whitmore & Callahan LLP (James "Jim" Callahan), and Defendant Lumicore Technologies, Inc. ("Lumicore"), by and through its counsel of record Hawthorne Vega & Cruz LLP (Catherine "Kate" Rourke, Lead Partner; Samantha Briggs, Lead Associate) and local counsel Trask Eddington LLP (Maria Garza), hereby submit this Agreed Protocol for discovery of Electronically Stored Information (the "ESI Protocol" or "Protocol") governing the identification, preservation, collection, processing, review, and production of electronically stored information ("ESI") in this patent infringement action.

Right-click to update Table of Contents

I. RECITALS AND PURPOSE

1.1 Background of the Action

On April 22, 2024, Plaintiff Optiwave Semiconductor Corp. filed this action against Defendant Lumicore Technologies, Inc. asserting infringement of four United States utility patents: U.S. Patent No. 10,234,847 (the "'847 Patent"), U.S. Patent No. 10,891,193 (the "'193 Patent"), U.S. Patent No. 9,678,562 (the "'562 Patent"), and U.S. Patent No. 11,402,015 (the "'015 Patent"). The asserted patents relate to optical transceiver and waveguide multiplexing technologies, including but not limited to silicon photonic integrated circuits, coherent optical transceivers, micro-channel heat sink architectures, grating coupler designs, and polarization-diverse waveguide multiplexing methods used in high-speed data communications applications.

On June 17, 2024, Lumicore filed its Answer and Counterclaims (D.E. 12), asserting defenses of non-infringement as to all four asserted patents, invalidity under 35 U.S.C. §§ 102 and 103, unenforceability on the basis of inequitable conduct, and a counterclaim seeking a declaratory judgment of non-infringement. Lumicore's counterclaims further allege that OWS's asserted patents are invalid in view of prior art not considered during prosecution, including certain publications and patent filings by researchers at the National University of Singapore and the University of Southampton.

The Court's Scheduling Order (D.E. 27, entered August 12, 2024) establishes the following key deadlines relevant to this Protocol: fact discovery closes on May 1, 2025; claim construction briefing is to be completed by February 14, 2025; the Markman hearing is set for March 14, 2025; expert reports are due on July 15, 2025 (opening) and September 15, 2025 (rebuttal); dispositive motions are due on November 3, 2025; and trial is set to commence on February 2, 2026.

1.2 Purpose of the ESI Protocol

This Protocol is entered by agreement of the parties pursuant to their respective obligations under Federal Rule of Civil Procedure 26(f) and is consistent with the Joint discovery Plan and Report filed by the parties on July 29, 2024 (D.E. 24). During the parties' Rule 26(f) conference, conducted on July 22, 2024, counsel for both parties identified the need for a comprehensive protocol to govern the discovery of ESI in light of the substantial volume of electronic documents, the complex technical nature of the subject matter, and the multiple categories of ESI at issue in a patent infringement case of this magnitude.

This Protocol governs the identification, preservation, collection, processing, review, and production of ESI in this action and is intended to supplement, but not replace, the Federal Rules of Civil Procedure, the Local Rules for the Eastern District of Texas, and any applicable Patent Rules of the Eastern District of Texas. To the extent any provision of this Protocol conflicts with the Federal Rules, the Local Rules, or the Patent Rules, the Rules shall govern unless the parties have expressly agreed otherwise and such agreement is consistent with law.

The purpose of this Protocol is to: (a) reduce the likelihood and frequency of discovery disputes related to ESI; (b) ensure that ESI discovery is conducted in a manner consistent with the proportionality requirements of Federal Rule of Civil Procedure 26(b)(1); (c) promote the efficient management of large-volume document productions by establishing agreed-upon standards for format, metadata, and production specifications; (d) protect the integrity of ESI and its associated metadata throughout the discovery process; (e) establish clear procedures for the handling of privileged and protected materials in the context of large-scale document review and production; and (f) ensure that both parties have meaningful access to the ESI necessary to prosecute and defend the claims and counterclaims in this action.

This Protocol operates in conjunction with the Stipulated Protective Order, which the parties expect will be entered by the Court on or about August 19, 2024. The Stipulated Protective Order establishes three tiers of confidentiality for information produced in discovery: (i) "Confidential," (ii) "Highly Confidential — Attorneys' Eyes Only," and (iii) "Highly Confidential — Source Code." References to confidentiality designations throughout this Protocol shall be understood to correspond to the tiers established in the Stipulated Protective Order.

1.3 Definitions. The following definitions shall apply throughout this Protocol:

"ESI" means electronically stored information as that term is used in Federal Rule of Civil Procedure 34(a)(1)(A), and includes, without limitation, any and all information stored in electronic form regardless of the media on which it resides or the format in which it exists.

"Producing Party" means the party producing ESI in response to discovery requests, subpoenas, or other obligations under the Federal Rules of Civil Procedure or this Protocol.

"Receiving Party" means the party receiving ESI from the Producing Party.

"Document Review Platform" means Relativity, as agreed upon by the parties and described in Section IV of this Protocol.

"Native Format" means the original file format in which ESI was created, used, or stored by the originating application, preserving all underlying data, metadata, and functionality associated with the file.

"TIFF" means Tagged Image File Format, a widely used raster image file format for storing and exchanging image data.

"Load File" means a file containing metadata fields and document-level coding information used to import documents, images, and associated data into a document review platform. As used in this Protocol, "Load File" refers specifically to a concordance DAT-format file unless otherwise specified.

"OCR" means Optical Character Recognition, the electronic conversion of images of typed, handwritten, or printed text into machine-encoded text.

"Custodian" means an individual identified as having possession, custody, or control of potentially responsive ESI. A custodian may be a current or former employee, officer, director, agent, or contractor of a party.

"Source Code" means software source code (whether in high-level programming languages such as C, C++, Python, or Verilog, or in lower-level representations), RTL (Register Transfer Level) schematics, photonic-IC layout files (including GDS-II and OASIS format files), mask files, and related design files used in the development, testing, and fabrication of the accused products or competing products.

"Source Code Materials" has the meaning set forth in Section VIII of this Protocol.

"De-NIST" or "De-NISTing" means the process of removing known system and application files from a collection of ESI by comparing the hash values of collected files against the hash library maintained by the National Institute of Standards and Technology ("NIST") through its National Software Reference Library ("NSRL").

"Protective Order" or "Stipulated Protective Order" means the Stipulated Protective Order entered or to be entered by the Court in this action, establishing three tiers of confidentiality: "Confidential," "Highly Confidential — Attorneys' Eyes Only," and "Highly Confidential — Source Code." All references to confidentiality designations in this Protocol shall have the meanings ascribed to them in the Stipulated Protective Order.

II. SCOPE AND PROPORTIONALITY

2.1 Scope of ESI discovery

ESI discovery in this action shall be limited to materials relevant to any party's claim or defense and proportional to the needs of the case, consistent with Federal Rule of Civil Procedure 26(b)(1). The claims and defenses for which ESI discovery is relevant include, without limitation: infringement (literal and under the doctrine of equivalents) of each of the four asserted patents; validity of each of the asserted patents under 35 U.S.C. §§ 102, 103, and 112; enforceability, including Lumicore's affirmative defense of inequitable conduct; willful infringement; damages, including lost profits, reasonable royalties, and any enhanced damages under 35 U.S.C. § 284; and all counterclaims for declaratory relief asserted by Lumicore.

ESI subject to discovery under this Protocol includes, without limitation: emails (including attachments); word processing documents; spreadsheets; presentations; databases; CAD (Computer-Aided Design) files; engineering design files; source code (including Verilog, VHDL, C, C++, Python, and any other programming languages used in the development of the accused or competing products); photonic-IC layout files (including GDS-II and OASIS format files); mask files; fabrication run data; simulation data and results; test and characterization data; instant messages; text messages (SMS and MMS); collaboration platform messages (including messages and files shared via Meridian Solutions, Northgate Data Systems, confluence, Jira, and similar platforms); voicemail recordings stored digitally; meeting recordings and transcripts stored electronically; and structured data from enterprise resource planning ("ERP") systems, customer relationship management ("CRM") systems, and other enterprise databases.

2.2 Proportionality Considerations

The parties acknowledge that this action involves substantial document volumes. As of the date of this Protocol, based on preliminary collection and processing estimates, OWS has identified approximately 182,000 potentially responsive documents comprising approximately 1.4 million pages. Lumicore has identified approximately 147,000 potentially responsive documents comprising approximately 980,000 pages. These estimates are preliminary and may be revised as collection and processing activities continue. The parties further acknowledge that additional ESI may be identified as discovery progresses, particularly with respect to source code repositories, engineering databases, and structured data exports.

In light of these volumes, the parties agree to apply proportionality principles under Federal Rule of Civil Procedure 26(b)(1) throughout the ESI discovery process. In evaluating whether specific discovery requests or categories of ESI are proportional to the needs of the case, the parties and the Court shall consider, among other factors: the importance of the issues at stake in this action (OWS claims approximately $210 million in damages across the four asserted patents, encompassing both lost profits and reasonable royalty theories); the amount in controversy; the parties' relative access to relevant information (recognizing that Lumicore has unique access to its own engineering and design files for the accused products, while OWS has unique access to its patent prosecution files and competing product design files); the importance of the discovery in resolving the issues; whether the burden or expense of the proposed discovery outweighs its likely benefit; and the resources of the parties (both parties are established semiconductor companies with annual revenues exceeding $500 million).

The parties further agree that discovery of ESI from sources that are not reasonably accessible because of undue burden or cost shall not be required absent a showing of good cause under Federal Rule of Civil Procedure 26(b)(2)(B). Examples of sources that may not be reasonably accessible include, but are not limited to: disaster recovery backup tapes that are not indexed or searchable; legacy email systems or file servers that were decommissioned prior to the relevant time periods specified in Section 2.3; data stored on damaged or degraded media that would require specialized forensic recovery; and voicemail systems or other transient data repositories for which no routine preservation mechanism exists. If a party seeks discovery from a source claimed to be not reasonably accessible, the responding party shall identify the source and explain the basis for its claim of inaccessibility, and the requesting party may move the Court for an order compelling production upon a showing of good cause.

2.3 Temporal Scope

Unless otherwise agreed in writing by the parties or ordered by the Court, ESI shall be collected and produced for the following time periods, which the parties agree are reasonable and proportional given the nature of the claims and defenses in this action:

Patent prosecution and development documents: From November 22, 2014 (the filing date of the '562 Patent, which is the earliest priority date among the four asserted patents) through the present. This time period is intended to capture all documents relating to the conception, reduction to practice, and prosecution of the asserted patents, including inventor notebooks, prosecution correspondence with the United States Patent and Trademark Office, and internal communications regarding patentability assessments.

Accused product design and development documents (Lumicore): From January 1, 2015 (the year in which Lumicore was founded and incorporated in the State of Delaware) through the present. This time period is intended to capture the full lifecycle of the accused product families, from initial concept and design through current production, including all engineering specifications, design review documents, testing and characterization data, and product development meeting minutes.

Licensing and notice documents: From January 1, 2018 through the present. This time period is intended to encompass all licensing activities relating to the asserted patents, including the Asset Purchase Agreement between OWS and Solara Optics, Inc. dated June 15, 2018 (through which OWS acquired certain patent rights), the correspondence initiated by FairPoint Licensing Group, LLC beginning on or about January 15, 2023 (in its capacity as OWS's former licensing agent), and all subsequent licensing offers, negotiations, and pre-suit communications between or among the parties and their agents.

Financial and damages-related documents: From January 1, 2020 through the present. This time period is intended to encompass the period relevant to damages calculations, including revenue data, cost data, pricing information, profit margins, market share analyses, customer lists, and sales projections for the accused product lines and competing OWS products.

Prior-art-related documents: No temporal limitation shall apply to ESI relating to prior art, as prior art references may predate the earliest priority date of the asserted patents. This category includes, without limitation, documents relating to the identification, evaluation, or analysis of prior art by either party, as well as prior art references themselves.

Willful infringement documents: From October 2022 (the approximate date when OWS's internal engineering team first identified potential infringement by Lumicore's products) through the present. This time period is intended to capture all documents relevant to OWS's claim of willful infringement, including internal OWS analyses, communications with counsel regarding infringement opinions, and any communications between the parties regarding the asserted patents.

The temporal scope set forth above is without prejudice to either party's right to request production of ESI outside these time periods upon a showing of relevance and proportionality, subject to the meet-and-confer procedures in Section XI.

2.4 Custodians. Each party shall identify its ESI custodians in its initial disclosures served pursuant to Federal Rule of Civil Procedure 26(a)(1) and may supplement its custodian list as discovery progresses and additional relevant custodians are identified. The identification of an individual as a custodian does not constitute an admission that all ESI in that individual's possession, custody, or control is responsive or relevant; rather, it reflects the party's good-faith assessment that the individual is likely to have potentially responsive ESI.

OWS has identified fourteen (14) custodians in its Litigation Hold Memorandum dated March 22, 2024. These custodians include, but are not limited to, the following individuals:

(a) Dr. Jian-Wei Huang, Chief Technology Officer;

(b) Dr. Nikolai Petrov, Vice President of Engineering, Photonics Division;

(d) David Leitner, Chief Financial Officer;

(e) Dr. Priya Ramaswamy, Chief Executive Officer;

(f) Additional custodians as identified in OWS's initial disclosures and any supplemental disclosures.

Lumicore shall identify its custodians in its initial disclosures. Based on the parties' preliminary discussions, Lumicore's anticipated custodians include, but are not limited to, the following individuals:

(a) Dr. Sandra Michaud, Chief Technology Officer;

(b) Thomas "Tom" Kessler, Chief Executive Officer;

(d) Dr. Eric Dalmqvist, Vice President of Product Development;

(e) Janet Moreno, Chief Financial Officer;

(f) Relevant engineering personnel involved in the design and development of the LumiLink 400G-ZR+, LumiLink 800G-DR8, and LumiEdge 1600G-LR product lines, whose identities will be disclosed in Lumicore's initial disclosures.

Either party may request the addition of custodians by written notice to the opposing party. The parties shall meet and confer in good faith regarding any proposed addition of custodians. If the parties cannot agree on whether a particular individual should be designated as a custodian, they shall follow the meet-and-confer procedures set forth in Section XI below before seeking Court intervention. In evaluating whether the addition of a custodian is warranted, the parties and the Court shall consider the likelihood that the proposed custodian possesses unique, non-duplicative responsive ESI, the burden and cost of collecting and processing the custodian's data, and the relevance of the anticipated ESI to the claims and defenses in this action.

III. PRESERVATION OBLIGATIONS

3.1 Litigation Hold

Each party represents and warrants that it has issued appropriate litigation hold notices to all identified custodians and relevant information technology personnel directing the preservation of all potentially relevant ESI. Each party further represents that its litigation hold is reasonably designed to ensure the preservation of ESI relevant to the claims and defenses in this action and that it has taken reasonable steps to monitor compliance with its litigation hold obligations.

OWS represents that its litigation hold was issued on March 22, 2024, to all identified custodians and the OWS Information Technology Department. The OWS litigation hold covers all documents, ESI, and communications relating to U.S. Patent Nos. 10,234,847; 10,891,193; 9,678,562; and 11,402,015, including patent prosecution files, inventor notebooks, and internal communications regarding the patented technologies; Lumicore and its products; and pre-suit licensing contacts and negotiations, including communications with FairPoint Licensing Group, LLC and its representatives. OWS further represents that it has issued reminder notices to all custodians on a periodic basis and has confirmed compliance with its litigation hold through direct communications with each custodian and the IT Department.

Lumicore represents that its litigation hold was issued on or before May 20, 2024, the date of its first appearance in this action. Lumicore further represents that its litigation hold covers all documents, ESI, and communications relevant to the claims and defenses in this action, including documents related to the design, development, manufacture, marketing, and sale of the accused product families; prior art references; and licensing and pre-suit communications.

3.2 Preservation of Metadata

Each party shall take reasonable steps to preserve the metadata of ESI, including but not limited to: file creation date, last-modified date, author, file path, file name, file extension, file size, and, for emails, email header information (including To, From, CC, BCC, Subject, and Date/Time Sent fields). Metadata preservation is essential to the integrity of the ESI discovery process and to the ability of both parties to authenticate and evaluate produced documents.

Neither party shall take any steps that would alter or destroy metadata of potentially responsive ESI, including but not limited to: opening or resaving files in a manner that overwrites metadata fields; converting files from one format to another without preserving the original file and its metadata; or moving files in a manner that alters their creation date, last-modified date, or file path. To the extent that collection or processing activities necessarily alter certain metadata fields (e.g., last-accessed date), the parties shall document such changes and preserve the original metadata values where feasible.

3.3 Suspension of Auto-Deletion Policies

Each party shall suspend any automatic deletion policies, programs, or routines as to all identified custodians and data sources for the duration of this litigation. This obligation extends to, but is not limited to: email retention policies that automatically delete emails after a specified period (including policies implemented through Strathmore Data Systems, Crestline Software, or similar email platforms); auto-purge settings on messaging platforms (including Meridian Solutions, Northgate Data Systems, and similar collaboration tools); document lifecycle management rules that automatically archive or delete documents based on age or usage criteria; and any other automated processes that would result in the destruction or alteration of potentially responsive ESI.

Each party shall take reasonable steps to confirm that all applicable auto-deletion policies have been suspended and shall monitor its systems on an ongoing basis to ensure continued suspension throughout the duration of this litigation.

3.4 Preservation of Source Code and Design Files

Lumicore shall preserve all source code, RTL schematics, photonic-IC layout files (including GDS-II and OASIS format files), mask files, fabrication run data, simulation data, and related design files for the accused product lines — specifically, the LumiLink 400G-ZR+, LumiLink 800G-DR8, and LumiEdge 1600G-LR — in their native formats. This preservation obligation extends to all version histories maintained in source code repositories (including Git, SVN, Perforce, or any other version control systems used by Lumicore), including commit logs, branch histories, merge histories, and associated author and date information. Lumicore shall not delete, overwrite, or alter any branches, tags, or commit history in the relevant repositories.

OWS shall preserve all source code and design files for its own competing products — specifically, the OWS-400ZR, OWS-800XR, and OWS-1600DR — to the extent such materials are responsive to Lumicore's discovery requests and counterclaims. OWS's preservation obligation with respect to its own source code and design files is subject to the same standards set forth above regarding the preservation of version histories and repository data.

IV. DOCUMENT REVIEW PLATFORM

4.1 Agreed Platform

The parties agree to use Relativity as the document review platform for purposes of hosting, reviewing, and producing documents in this litigation. Relativity is a widely used, industry-standard platform that supports the complex review, coding, and production workflows required in large-scale patent litigation. The parties have selected Relativity based on their mutual familiarity with the platform, its robust support for metadata management and advanced analytics, and its compatibility with the production format specifications agreed upon in this Protocol.

Each party shall maintain its own Relativity workspace for review and production purposes. The Producing Party's Relativity workspace shall be configured to house and manage that party's collected ESI, support the party's document review workflow (including privilege review, responsiveness review, and confidentiality designation), and generate productions in the formats specified in Section VII of this Protocol. The Receiving Party's Relativity workspace shall be configured to ingest and host productions received from the opposing party.

Relativity workspaces shall be configured to support the three-tier confidentiality designations established in the Stipulated Protective Order, such that documents may be coded and tracked at the "Confidential," "Highly Confidential — Attorneys' Eyes Only," and "Highly Confidential — Source Code" levels. Access controls within each party's workspace shall be implemented consistent with the access restrictions established in the Protective Order.

4.2 Vendor Selection

Each party may retain its own e-discovery vendor for the collection, processing, and hosting of ESI in connection with this litigation. The selection of an e-discovery vendor is within the sole discretion of each party, provided that the vendor selected has the capability and experience to comply with the specifications set forth in this Protocol. Neither party shall have any obligation to disclose the identity of its e-discovery vendor to the opposing party, although such disclosure may facilitate coordination on technical issues.

The parties shall coordinate on Relativity load file specifications to ensure interoperability between their respective workspaces. To that end, the parties have agreed upon the load file specifications set forth in Exhibit A to this Protocol. In the event that a party's e-discovery vendor encounters a technical issue that prevents compliance with the load file specifications, the party shall promptly notify opposing counsel and the parties shall meet and confer to resolve the issue.

4.3 Technology-Assisted Review (TAR)

Either party may, at its discretion, use technology-assisted review ("TAR"), predictive coding, or other advanced analytics tools as part of its document review process. The decision to employ TAR and the selection of a specific TAR methodology are within the discretion of each party, subject to the transparency obligations set forth below.

A party using TAR shall, upon reasonable request from the opposing party, disclose the following information regarding its TAR methodology:

(a) The TAR methodology employed, including whether the party used continuous active learning ("CAL"), simple active learning ("SAL"), simple passive learning ("SPL"), or another methodology, and a general description of the workflow;

(b) The seed set or training set methodology, including the approximate size of the seed set, how the seed set was selected (e.g., random sampling, judgmental sampling, or a combination), and the qualifications of the reviewers who coded the seed set;

(c) Validation metrics, including recall and precision rates achieved by the TAR model as determined through validation sampling, and the confidence level and margin of error associated with the validation sample; and

(d) The overall richness of the document population (i.e., the percentage of documents in the population that were coded as responsive by the TAR model).

The use of TAR shall not relieve either party of its obligation to conduct a reasonable review for attorney-client privilege and work-product protection prior to production. Each party employing TAR shall ensure that its TAR workflow includes appropriate privilege screening measures, which may include keyword-based privilege filters, domain-based filters (e.g., filtering for communications with counsel domains), and manual review of documents flagged as potentially privileged.

Any disputes regarding the adequacy of a party's TAR methodology, including disputes regarding the sufficiency of validation metrics or the reasonableness of the party's overall approach, shall be subject to the meet-and-confer procedures set forth in Section XI of this Protocol before any motion is filed with the Court.

V. COLLECTION PROTOCOLS

5.1 Collection Standards

All ESI shall be collected in a forensically sound manner that preserves the integrity of the data and all associated metadata. Collection activities shall be designed to ensure that the collected data is a true and complete copy of the original data as it existed at the time of collection, and that the collection process does not alter, corrupt, or destroy any portion of the data or its metadata.

Collection shall be performed by qualified personnel with training and experience in forensic data collection or by a third-party e-discovery vendor with demonstrated expertise in forensic collection of ESI. All collections shall be documented through chain-of-custody records that identify: the data source from which the collection was made; the date and time of collection; the individual or vendor performing the collection; the collection methodology and tools used; and the hash value(s) of the collected data. Chain-of-custody documentation shall be maintained by the collecting party for the duration of this litigation and shall be made available to the opposing party upon reasonable request.

Collections shall be verified using hash values (MD5 or SHA-1) to ensure data integrity. The hash value of the collected data shall be compared to the hash value of the source data (where feasible) to confirm that the collection is a complete and accurate copy. Any discrepancies shall be documented and addressed through re-collection where necessary.

5.2 Data Sources

Each party shall collect ESI from the following categories of data sources, as applicable to the party's data environment and to the extent such sources contain potentially responsive ESI:

(a) Email systems, including Strathmore Data Systems, Ashgrove Software / Drayton Solutions, Ridgeline Software, or other enterprise email platforms used by the party, for all identified custodians;

(b) Network file shares and shared drives, including departmental drives, project drives, and any other shared storage locations used by identified custodians or relevant departments (e.g., engineering, legal, finance, marketing);

(c) Local hard drives and laptops of identified custodians, to the extent such devices contain unique, non-duplicative ESI not available from network or cloud sources;

(d) Cloud storage services, including Severin Services Inc., Aldermere Systems, Hollowell Health IT, Larkspur Technologies, box, and any other cloud-based file storage platforms used by the party or its custodians;

(e) Collaboration platforms, including Northgate Data Systems, Meridian Solutions, Penmark Data Systems, Northpoint Technologies, and any other collaboration or project management tools used by identified custodians or relevant teams, including both messages and files shared through these platforms;

(f) Enterprise databases and ERP systems, including financial databases, accounting systems, and enterprise resource planning systems containing financial data relevant to damages calculations;

(g) Source code repositories, including Git, SVN (Apache Subversion), Perforce, and any other version control systems used to manage source code and design files for the accused product lines (Lumicore) or competing product lines (OWS);

(h) Engineering design tools and PLM systems, including product lifecycle management platforms, CAD systems, electronic design automation ("EDA") tools, and simulation software used in the design and development of the products at issue;

(i) Mobile devices, including smartphones and tablets of identified custodians, to the extent such devices contain unique, non-duplicative responsive ESI (e.g., text messages or messaging application data not available from other sources); and

(j) Paper documents that have been scanned and stored electronically, including documents maintained in document management systems, scanned archives, or PDF repositories.

The foregoing list is not exhaustive, and each party reserves the right to identify additional data sources as warranted by the circumstances of this case. The parties shall meet and confer regarding any disputes about the scope of data sources to be collected.

5.3 De-Duplication. Each party shall de-duplicate ESI at the custodian level prior to production. Specifically, exact duplicates within a single custodian's collection shall be removed, such that only one copy of each unique document is retained for that custodian. Where the same document appears in multiple custodians' collections, the document shall be produced once and cross-referenced to all relevant custodians through the "Custodian" and "All Custodians" metadata fields in the load file.

De-duplication shall be performed using MD5 or SHA-1 hash values. Two documents shall be considered exact duplicates if and only if they produce identical hash values. Documents that are substantively similar but not identical (e.g., documents with different metadata but identical content) shall not be treated as duplicates unless they produce identical hash values.

Email de-duplication shall be based on a combination of email header fields (To, From, CC, BCC, Subject, Date/Time Sent, and Message-ID) and the hash value of the message body and attachments. An email shall be treated as a duplicate of another email only if all of the foregoing header fields are identical and the hash values of the message body and attachments are identical. Email threading shall be preserved such that complete email chains, including all prior messages in a thread, are maintained even where individual component messages within a chain are exact duplicates of messages in other chains.

5.4 De-NISTing. System and application files shall be removed from collected ESI using the NIST National Software Reference Library ("NSRL") hash set prior to processing. The NSRL hash set identifies known, commercially available software files (e.g., operating system files, application program files) that are unlikely to be responsive to discovery requests. Removing such files reduces the volume of ESI that must be processed and reviewed without eliminating potentially responsive documents.

Notwithstanding the foregoing, De-NISTing shall not be applied to files that are specifically identified as responsive or potentially responsive, including proprietary software constituting source code at issue in this action. If a party has reason to believe that a file matching a NIST hash value is nonetheless responsive (e.g., because it is a proprietary file that happens to match a known file hash), the party shall retain the file for review and production.

VI. PROCESSING PROTOCOLS

6.1 Processing Standards

ESI shall be processed using industry-standard e-discovery processing tools, such as Brightmoor Health IT, Severin Software, or equivalent platforms, that are capable of extracting text, metadata, and embedded objects from a range file formats. The processing tools selected by each party shall be capable of handling the file types identified in this Protocol, including email files, office documents, PDF files, image files, engineering design files, and structured data exports.

Processing shall extract full text content from all documents where text extraction is available, as well as all metadata fields specified in Section 6.2 of this Protocol. Embedded objects (such as images, charts, and OLE objects within documents) shall be extracted and processed to the extent technically feasible. Where embedded objects contain text, that text shall be included in the extracted text output for the parent document.

Optical Character Recognition ("OCR") shall be applied to image-only documents (e.g., scanned PDFs, TIFF images) and to documents for which extracted text is not available or is insufficient (e.g., documents containing embedded images of text). OCR shall be performed using industry-standard OCR software at a quality level sufficient to produce reasonably accurate and searchable text. The parties acknowledge that OCR may not produce perfect text for all documents, particularly documents with poor image quality, handwritten content, or complex formatting, and the parties shall exercise good faith in evaluating the accuracy of OCR text.

6.2 Metadata Fields to Be Extracted

The following metadata fields shall be extracted and preserved for all processed ESI. These fields correspond to the load file specifications set forth in Exhibit A to this Protocol.

For emails:

For loose files (documents, spreadsheets, presentations, and other non-email files):

For source code and design files:

6.3 Date/Time Normalization

All date and time fields in processed ESI and production load files shall be normalized to Central Time ("CT"), which is consistent with the time zone of the Court (located in marshall, Texas) and the principal location of Lumicore's headquarters (Austin, Texas). This normalization ensures consistency across productions from both parties and facilitates the chronological ordering and searching of documents within the parties' respective Relativity workspaces.

Where the original time zone of a document or email cannot be determined (e.g., where the email system does not record time zone information), the processing vendor shall apply Central Time as the default time zone and note the assumption in the processing log. The parties acknowledge that time zone normalization may result in minor discrepancies for documents originating in other time zones, and such discrepancies shall not be a basis for objecting to the validity or admissibility of the produced document.

6.4 Handling of Encrypted or Password-Protected Files

If a party encounters encrypted or password-protected files during processing, it shall make reasonable efforts to obtain the password or decryption key from the custodian or from the party's IT department. "Reasonable efforts" include, but are not limited to: contacting the custodian identified as having possession, custody, or control of the file; checking any centralized password management systems maintained by the party; and attempting commonly used passwords or decryption methods.

If a password or decryption key cannot be obtained after reasonable efforts, the party shall log the file on a separate "Inaccessible Files Log" that identifies, at minimum: the file name; the file path; the custodian; the file type or extension; the approximate file size; and a brief description of the reason the file could not be processed (e.g., "Password-protected; password unknown and not obtainable from custodian"). The Inaccessible Files Log shall be provided to the opposing party upon request. If the opposing party believes that a file on the Inaccessible Files Log is likely to contain responsive, non-privileged material, the parties shall meet and confer regarding additional efforts to access the file, which may include the engagement of a forensic specialist at the requesting party's expense.

6.5 Exception Files

Files that cannot be processed due to corruption, unsupported file formats, or other technical errors shall be logged on the Inaccessible Files Log described in Section 6.4. The log entry for each exception file shall include the same information specified in Section 6.4, with the reason for the processing failure identified (e.g., "File corrupted; unable to extract text or metadata" or "Unsupported file format: .xyz"). The Inaccessible Files Log, including entries for both password-protected files and exception files, shall be provided to the opposing party upon request and shall be updated on a rolling basis as additional processing is completed.

VII. PRODUCTION FORMAT

7.1 General Production Format — TIFF + Load File

Unless otherwise specified in this Protocol, ESI shall be produced in single-page TIFF format at a resolution of 300 DPI (dots per inch) using Group IV compression. Each TIFF image shall represent a single page of the original document. Each TIFF production shall be accompanied by the following supporting files:

(a) A document-level load file in concordance DAT format, with pipe ("|") delimited fields and carrot ("þ") delimited multi-value fields, containing all extracted metadata fields specified in Section 6.2 of this Protocol. The load file shall use newline characters as row delimiters. Each row in the load file shall correspond to a single document (or a single email message, with attachments treated as separate documents linked by parent-child relationship fields). The complete load file specifications are set forth in Exhibit A to this Protocol.

(b) An image cross-reference file in Opticon OPT format, linking each page image to its document identifier (Bates number). The OPT file shall identify, for each page image: the Bates number of the page, the volume or folder designation, the file path to the image, the document break indicator (identifying whether the page is the first page of a new document), and the page count for the document.

(c) Extracted text files, one per document, containing the full text extracted from the document during processing. For image-only documents or documents for which extracted text is not available, OCR text files (one per document) shall be provided in lieu of extracted text files. Text files shall be named with the Bates number of the first page of the corresponding document (e.g., OWS-0000001.txt).

Each page produced in TIFF format shall be Bates-stamped with a unique production number in the following format: [Party Prefix]-[Seven-Digit Sequential Number]. OWS shall use the prefix "OWS-" (e.g., OWS-0000001, OWS-0000002, OWS-0000003). Lumicore shall use the prefix "LTC-" (e.g., LTC-0000001, LTC-0000002, LTC-0000003). Bates numbers shall be applied sequentially within each party's production and shall not contain gaps, duplicates, or non-sequential numbering. Bates numbers shall appear in the lower-right corner of each TIFF image in a legible font (minimum 10-point). The specifications for Bates numbering format and placement are further detailed in Exhibit B to this Protocol.

7.2 Redactions. Where a Producing Party determines that a document contains both responsive, non-privileged content and content that is subject to a valid privilege or that requires redaction for confidentiality purposes under the Protective Order, the Producing Party may produce the document in redacted form. Redactions shall be applied to the TIFF image and shall be clearly indicated by a black or white redaction box overlaid on the redacted content. Each redaction box shall bear a legend identifying the basis for the redaction, such as "REDACTED — Attorney-Client Privilege," "REDACTED — Work Product," or "REDACTED — Confidential Third-Party Information," as applicable.

The corresponding extracted text or OCR text for any redacted document shall likewise be redacted to remove the privileged or protected content. The Producing Party shall ensure that the redacted text file does not contain any portion of the text underlying a redaction on the TIFF image. All redacted documents shall be logged on the Producing Party's privilege log in accordance with Section IX of this Protocol, with sufficient detail to permit the Receiving Party to assess the validity of the asserted privilege or protection.

Redactions shall not be used as a substitute for withholding documents in their entirety where partial redaction is not appropriate. If the privileged content of a document is so extensive that meaningful partial production is not possible, the document shall be withheld in full and logged on the privilege log.

7.3 Native-Format Productions

The following categories of ESI shall be produced in native format (in addition to or in lieu of TIFF, as specified below), in recognition of the fact that TIFF conversion is not adequate to preserve the full content, functionality, or utility of these file types:

Source code, RTL schematics, photonic-IC layout files, and mask files: These materials shall be produced in native format only; TIFF production is not required for source code or design files. All Source Code Materials shall be designated "Highly Confidential — Source Code" under the Protective Order. The production and inspection procedures for Source Code Materials are set forth in Section VIII of this Protocol.

Spreadsheets (Microsoft Excel, Stonefield Services Inc., and equivalent formats): Spreadsheets shall be produced in native format (.xlsx, .csv, or equivalent) in addition to the standard TIFF + load file production. The native format production is necessary to preserve formulas, embedded data, pivot tables, linked worksheets, and multi-tab structure that are not adequately captured in TIFF images. Where a spreadsheet contains multiple tabs or worksheets, the TIFF production shall include images of all tabs, and the native file shall include all tabs in their original configuration.

Databases and structured data exports: Databases and structured data shall be produced in native format (e.g., .csv, .xlsx, .accdb, or .sql) or in a mutually agreed-upon format that preserves the relational structure of the data, including table relationships, field definitions, and data types. The parties shall meet and confer on a case-by-case basis regarding the appropriate format for production of specific database or structured data sources, taking into account the nature and volume of the data and the Receiving Party's ability to import and analyze the data.

Presentations (Microsoft Northgate Services Inc., Tidewater Data Systems, and equivalent formats): Presentations shall be produced in native format in addition to the standard TIFF + load file production, where the TIFF production does not adequately capture embedded animations, speaker notes, multimedia content (such as embedded audio or video), or other features that are material to the content of the presentation. Where a presentation does not contain any such features and the TIFF production adequately represents the content of all slides, native format production is not required.

CAD files and engineering design files: CAD files (including files in Glenrock Technologies, Meridian Data Systems, cadence, Ridgeline Data Systems, and similar formats) shall be produced in native format. Where feasible, TIFF representations shall also be provided for reference purposes, but the native files shall be the authoritative production. The parties acknowledge that CAD and design files may require specialized software to view and that the Receiving Party is responsible for obtaining appropriate viewing tools.

Audio and video files: Audio and video files shall be produced in native format only. TIFF production is not applicable to audio and video content. Audio and video files shall be accompanied by load file entries identifying the file name, file path, file size, duration (where available), custodian, and date created or last modified.

7.4 Email Production

Emails shall be produced in TIFF + load file format as specified in Section 7.1 of this Protocol. Each email message shall be treated as a separate document, and each email attachment shall be produced as a separate document linked to its parent email through parent-child relationship metadata fields in the load file. The load file shall include the following parent-child relationship fields: ParentDocID (identifying the Bates number of the parent email for each attachment), AttachmentRange (identifying the Bates range of all attachments to a parent email), and FamilyID (a common identifier linking the parent email and all of its attachments).

Email threading shall be preserved through the Thread-ID and/or Conversation-Index metadata field, where such information is available from the email system. Preservation of email threading metadata enables the Receiving Party to reconstruct email conversations and identify the chronological sequence of communications within a thread.

Where an email contains inline images (e.g., images embedded in the body of the email rather than included as separate attachments), such inline images shall be rendered in the TIFF image of the email body. Where technically feasible, inline images shall also be extracted and produced as separate files linked to the parent email through the load file.

7.5 Confidentiality Designations

Each document produced pursuant to this Protocol shall bear a confidentiality designation consistent with the three-tier Stipulated Protective Order. Confidentiality designations shall be applied as follows:

For documents produced in TIFF format, the confidentiality designation shall appear in the lower-left corner of each TIFF image as a stamped legend (e.g., "CONFIDENTIAL," "HIGHLY CONFIDENTIAL — ATTORNEYS' EYES ONLY," or "HIGHLY CONFIDENTIAL — SOURCE CODE"). The confidentiality designation shall be in a legible font (minimum 8-point) and shall not obscure any portion of the document content.

For documents produced in native format, the confidentiality designation shall be identified in the load file metadata through a dedicated "Confidentiality" field. Additionally, native format productions shall be accompanied by a cover letter or transmittal identifying the confidentiality designation applicable to each document or group of documents.

A Producing Party may re-designate documents to a higher or lower tier of confidentiality upon written notice to the Receiving Party, subject to the provisions of the Protective Order. The Receiving Party may challenge the confidentiality designation of any document in accordance with the procedures established in the Protective Order.

7.6 Production Media

Productions of up to fifty gigabytes (50 GB) in total size may be transmitted via secure File Transfer Protocol ("FTP"), Secure File Transfer Protocol ("SFTP"), or other encrypted electronic transfer method agreed upon by the parties. The parties shall coordinate on the selection of an appropriate electronic transfer platform, which may include platforms offered by the parties' respective e-discovery vendors (e.g., Relativity Transfer, GoAnywhere, or equivalent).

Productions exceeding fifty gigabytes (50 GB) in total size shall be delivered on encrypted external hard drives or other encrypted physical media. All physical production media shall be encrypted using AES-256 encryption or an equivalent standard, and the encryption password shall be communicated separately from the physical media (e.g., by email or telephone). Physical production media shall be shipped via overnight courier with tracking and signature confirmation, and chain-of-custody documentation shall be maintained.

All production media, whether electronic or physical, shall be clearly labeled with: the case name (Optiwave Semiconductor Corp. v. Lumicore Technologies, Inc.); the case number (2:24-cv-00319-JRG); the producing party; the production date; the production volume designation (e.g., "Volume 1 of 3"); and the Bates range of documents included in the production (e.g., "OWS-0000001 through OWS-0045328").

VIII. SOURCE CODE PRODUCTION AND INSPECTION PROTOCOL

8.1 Applicability. This Section VIII governs the production and inspection of source code, RTL schematics, photonic-IC layout files (including GDS-II and OASIS format files), mask files, fabrication run data, simulation data, and related design files (collectively, "Source Code Materials") of both parties. Source Code Materials constitute the most sensitive and commercially valuable information at issue in this litigation, and the parties have agreed to the procedures set forth in this Section to protect the confidentiality of such materials while permitting meaningful access for purposes of prosecuting and defending the claims in this action.

All Source Code Materials shall be designated "Highly Confidential — Source Code" under the Stipulated Protective Order. The procedures set forth in this Section are in addition to, and not in lieu of, the protections afforded by the Protective Order's "Highly Confidential — Source Code" tier.

By way of background, OWS's Second Set of Requests for Production (to be served on or about November 4, 2024) is expected to include thirty (30) supplemental requests for production specifically targeting Lumicore's source code repositories, photonic-IC mask files, and fabrication run data for the accused product families (LumiLink 400G-ZR+, LumiLink 800G-DR8, and LumiEdge 1600G-LR). Lumicore's corresponding discovery requests are expected to target OWS's competing product source code and design files to the extent relevant to Lumicore's invalidity and non-infringement defenses.

8.2 Production in Native Format

Source Code Materials shall be produced in native format, preserving the original directory structure, file naming conventions, and version/commit history as they exist in the Producing Party's source code repositories and file systems. The Producing Party shall not alter, reorganize, or rename files within the production except as necessary to comply with the Bates numbering and load file requirements of this Protocol.

Source code from repositories (e.g., Git, SVN, Perforce) shall be produced as complete repository snapshots or exports at relevant time points designated by the Receiving Party, including commit logs with dates and author information. The Producing Party shall produce, at minimum: (a) a snapshot of the current production version of the accused product's (or competing product's) source code as of the date of production; (b) snapshots at additional relevant time points as reasonably requested by the Receiving Party (e.g., the date of initial commercial release of each accused product, the date of receipt of any notice of infringement, and the date of filing of this action); and (c) commit logs covering the full development history of the relevant product or feature, including author, date, commit message, and files changed. The parties shall meet and confer regarding the specific time points for which repository snapshots are required.

8.3 Inspection Environment

Source Code Materials shall be made available for inspection at a secure, stand-alone computer workstation (the "Inspection Workstation") maintained at the producing party's outside counsel's office, at the following locations:

For OWS Source Code Materials: Calderwood & Harkness LLP, 350 South Grand Avenue, 48th Floor, Los Angeles, California 90071.

For Lumicore Source Code Materials: Hawthorne Vega & Cruz LLP, 600 Congress Avenue, Suite 2400, Austin, Texas 78701.

The Inspection Workstation shall satisfy the following security requirements:

(a) The workstation shall not be connected to any network, whether wired or wireless (i.e., the workstation shall be "air-gapped" from all internal and external networks);

(b) The workstation shall not have any external ports enabled, including USB ports, Thunderbolt ports, SD card slots, Bluetooth adapters, or other data transfer interfaces, other than a single printer connection for making hard-copy excerpts as described in Section 8.5;

(d) The workstation shall be equipped with appropriate software tools for viewing and navigating source code and design files, including a text editor, a source code viewer or IDE (integrated development environment), and, for photonic-IC layout files, an appropriate GDS-II / OASIS viewer; and

(e) The workstation shall be located in a private, lockable room at the producing party's outside counsel's office, and access to the room shall be controlled and logged.

The Producing Party's counsel shall be responsible for setting up and maintaining the Inspection Workstation, including loading the Source Code Materials onto the workstation's local hard drive and ensuring that the workstation remains in compliance with the security requirements specified herein. The cost of setting up and maintaining the Inspection Workstation shall be borne by the Producing Party.

8.4 Access Restrictions

Access to Source Code Materials shall be limited to the individuals designated under the "Highly Confidential — Source Code" tier of the Stipulated Protective Order. As of the date of this Protocol, the individuals authorized to access Source Code Materials include:

(a) Outside counsel of record for the Receiving Party and their direct support staff (including associates, paralegals, and litigation support personnel) who have executed the Acknowledgment and Agreement to Be Bound form required by the Protective Order;

(b) For OWS (as Receiving Party inspecting Lumicore Source Code Materials): Up to two (2) designated technical experts — specifically, Dr. Caroline Ashford and Kevin Ng of Benchmark Semiconductor Analysis, LLC — who have executed the Acknowledgment and Agreement to Be Bound form;

(c) For Lumicore (as Receiving Party inspecting OWS Source Code Materials): Up to two (2) designated technical experts — specifically, Dr. Rajesh Sundaram and one additional designee to be identified by Lumicore no later than thirty (30) days prior to Lumicore's first scheduled source code inspection session — who have executed the Acknowledgment and Agreement to Be Bound form.

No in-house counsel, employees, officers, directors, or agents of any party shall have access to the opposing party's Source Code Materials. This restriction applies regardless of whether such individuals have signed the Acknowledgment and Agreement to Be Bound form required by the Protective Order.

8.5 Inspection Procedures

The Receiving Party shall provide at least five (5) business days' written notice to the Producing Party before scheduling a source code inspection session. The notice shall identify: the individual(s) who will conduct the inspection; the date and time of the proposed inspection; and a reasonable description of the categories of Source Code Materials to be inspected during the session (to enable the Producing Party to ensure that the relevant materials are loaded on the Inspection Workstation).

Inspection sessions shall be conducted during normal business hours (9:00 AM to 6:00 PM local time at the location of the Inspection Workstation) and shall not exceed eight (8) hours per session without the prior written consent of the Producing Party. The Producing Party shall use good faith efforts to accommodate the Receiving Party's scheduling requests, and the parties shall cooperate to ensure that a reasonable number of inspection sessions are made available.

During the inspection, the inspecting individual may take handwritten notes. All such handwritten notes shall be treated as "Highly Confidential — Source Code" under the Protective Order and shall be subject to all of the restrictions applicable to materials bearing that designation, including restrictions on copying, distribution, and storage. The inspecting individual shall not bring any electronic devi

UNITED STATES DISTRICT COURT EASTERN DISTRICT OF TEXAS MARSHALL DIVISION
OPTIWAVE SEMICONDUCTOR CORP.,
Plaintiff,
v.
LUMICORE TECHNOLOGIES, INC.,
Defendant.
Case No. 2:24-cv-00319-JRG
The Honorable James R. Gilstrap
AGREED PROTOCOL FOR DISCOVERY OF ELECTRONICALLY STORED INFORMATION
August 15, 2024
Plaintiff Optiwave Semiconductor Corp. ("OWS"), by and through its counsel of record Calderwood & Harkness LLP (Alan Ngo, Responsible Partner; Wendy Schultz, Lead Associate) and local counsel Whitmore & Callahan LLP (James "Jim" Callahan), and Defendant Lumicore Technologies, Inc. ("Lumicore"), by and through its counsel of record Hawthorne Vega & Cruz LLP (Catherine "Kate" Rourke, Lead Partner; Samantha Briggs, Lead Associate) and local counsel Trask Eddington LLP (Maria Garza), hereby submit this Agreed Protocol for discovery of Electronically Stored Information (the "ESI Protocol" or "Protocol") governing the identification, preservation, collection, processing, review, and production of electronically stored information ("ESI") in this patent infringement action.
Right-click to update Table of Contents
I. RECITALS AND PURPOSE
1.1 Background of the Action
On April 22, 2024, Plaintiff Optiwave Semiconductor Corp. filed this action against Defendant Lumicore Technologies, Inc. asserting infringement of four United States utility patents: U.S. Patent No. 10,234,847 (the "'847 Patent"), U.S. Patent No. 10,891,193 (the "'193 Patent"), U.S. Patent No. 9,678,562 (the "'562 Patent"), and U.S. Patent No. 11,402,015 (the "'015 Patent"). The asserted patents relate to optical transceiver and waveguide multiplexing technologies, including but not limited to silicon photonic integrated circuits, coherent optical transceivers, micro-channel heat sink architectures, grating coupler designs, and polarization-diverse waveguide multiplexing methods used in high-speed data communications applications.
On June 17, 2024, Lumicore filed its Answer and Counterclaims (D.E. 12), asserting defenses of non-infringement as to all four asserted patents, invalidity under 35 U.S.C. §§ 102 and 103, unenforceability on the basis of inequitable conduct, and a counterclaim seeking a declaratory judgment of non-infringement. Lumicore's counterclaims further allege that OWS's asserted patents are invalid in view of prior art not considered during prosecution, including certain publications and patent filings by researchers at the National University of Singapore and the University of Southampton.
The Court's Scheduling Order (D.E. 27, entered August 12, 2024) establishes the following key deadlines relevant to this Protocol: fact discovery closes on May 1, 2025; claim construction briefing is to be completed by February 14, 2025; the Markman hearing is set for March 14, 2025; expert reports are due on July 15, 2025 (opening) and September 15, 2025 (rebuttal); dispositive motions are due on November 3, 2025; and trial is set to commence on February 2, 2026.
1.2 Purpose of the ESI Protocol
This Protocol is entered by agreement of the parties pursuant to their respective obligations under Federal Rule of Civil Procedure 26(f) and is consistent with the Joint discovery Plan and Report filed by the parties on July 29, 2024 (D.E. 24). During the parties' Rule 26(f) conference, conducted on July 22, 2024, counsel for both parties identified the need for a comprehensive protocol to govern the discovery of ESI in light of the substantial volume of electronic documents, the complex technical nature of the subject matter, and the multiple categories of ESI at issue in a patent infringement case of this magnitude.
This Protocol governs the identification, preservation, collection, processing, review, and production of ESI in this action and is intended to supplement, but not replace, the Federal Rules of Civil Procedure, the Local Rules for the Eastern District of Texas, and any applicable Patent Rules of the Eastern District of Texas. To the extent any provision of this Protocol conflicts with the Federal Rules, the Local Rules, or the Patent Rules, the Rules shall govern unless the parties have expressly agreed otherwise and such agreement is consistent with law.
The purpose of this Protocol is to: (a) reduce the likelihood and frequency of discovery disputes related to ESI; (b) ensure that ESI discovery is conducted in a manner consistent with the proportionality requirements of Federal Rule of Civil Procedure 26(b)(1); (c) promote the efficient management of large-volume document productions by establishing agreed-upon standards for format, metadata, and production specifications; (d) protect the integrity of ESI and its associated metadata throughout the discovery process; (e) establish clear procedures for the handling of privileged and protected materials in the context of large-scale document review and production; and (f) ensure that both parties have meaningful access to the ESI necessary to prosecute and defend the claims and counterclaims in this action.
This Protocol operates in conjunction with the Stipulated Protective Order, which the parties expect will be entered by the Court on or about August 19, 2024. The Stipulated Protective Order establishes three tiers of confidentiality for information produced in discovery: (i) "Confidential," (ii) "Highly Confidential — Attorneys' Eyes Only," and (iii) "Highly Confidential — Source Code." References to confidentiality designations throughout this Protocol shall be understood to correspond to the tiers established in the Stipulated Protective Order.
1.3 Definitions.  The following definitions shall apply throughout this Protocol:
"ESI" means electronically stored information as that term is used in Federal Rule of Civil Procedure 34(a)(1)(A), and includes, without limitation, any and all information stored in electronic form regardless of the media on which it resides or the format in which it exists.
"Producing Party" means the party producing ESI in response to discovery requests, subpoenas, or other obligations under the Federal Rules of Civil Procedure or this Protocol.
"Receiving Party" means the party receiving ESI from the Producing Party.
"Document Review Platform" means Relativity, as agreed upon by the parties and described in Section IV of this Protocol.
"Native Format" means the original file format in which ESI was created, used, or stored by the originating application, preserving all underlying data, metadata, and functionality associated with the file.
"TIFF" means Tagged Image File Format, a widely used raster image file format for storing and exchanging image data.
"Load File" means a file containing metadata fields and document-level coding information used to import documents, images, and associated data into a document review platform. As used in this Protocol, "Load File" refers specifically to a concordance DAT-format file unless otherwise specified.
"OCR" means Optical Character Recognition, the electronic conversion of images of typed, handwritten, or printed text into machine-encoded text.
"Custodian" means an individual identified as having possession, custody, or control of potentially responsive ESI. A custodian may be a current or former employee, officer, director, agent, or contractor of a party.
"Source Code" means software source code (whether in high-level programming languages such as C, C++, Python, or Verilog, or in lower-level representations), RTL (Register Transfer Level) schematics, photonic-IC layout files (including GDS-II and OASIS format files), mask files, and related design files used in the development, testing, and fabrication of the accused products or competing products.
"Source Code Materials" has the meaning set forth in Section VIII of this Protocol.
"De-NIST" or "De-NISTing" means the process of removing known system and application files from a collection of ESI by comparing the hash values of collected files against the hash library maintained by the National Institute of Standards and Technology ("NIST") through its National Software Reference Library ("NSRL").
"Protective Order" or "Stipulated Protective Order" means the Stipulated Protective Order entered or to be entered by the Court in this action, establishing three tiers of confidentiality: "Confidential," "Highly Confidential — Attorneys' Eyes Only," and "Highly Confidential — Source Code." All references to confidentiality designations in this Protocol shall have the meanings ascribed to them in the Stipulated Protective Order.
II. SCOPE AND PROPORTIONALITY
2.1 Scope of ESI discovery
ESI discovery in this action shall be limited to materials relevant to any party's claim or defense and proportional to the needs of the case, consistent with Federal Rule of Civil Procedure 26(b)(1). The claims and defenses for which ESI discovery is relevant include, without limitation: infringement (literal and under the doctrine of equivalents) of each of the four asserted patents; validity of each of the asserted patents under 35 U.S.C. §§ 102, 103, and 112; enforceability, including Lumicore's affirmative defense of inequitable conduct; willful infringement; damages, including lost profits, reasonable royalties, and any enhanced damages under 35 U.S.C. § 284; and all counterclaims for declaratory relief asserted by Lumicore.
ESI subject to discovery under this Protocol includes, without limitation: emails (including attachments); word processing documents; spreadsheets; presentations; databases; CAD (Computer-Aided Design) files; engineering design files; source code (including Verilog, VHDL, C, C++, Python, and any other programming languages used in the development of the accused or competing products); photonic-IC layout files (including GDS-II and OASIS format files); mask files; fabrication run data; simulation data and results; test and characterization data; instant messages; text messages (SMS and MMS); collaboration platform messages (including messages and files shared via Meridian Solutions, Northgate Data Systems, confluence, Jira, and similar platforms); voicemail recordings stored digitally; meeting recordings and transcripts stored electronically; and structured data from enterprise resource planning ("ERP") systems, customer relationship management ("CRM") systems, and other enterprise databases.
2.2 Proportionality Considerations
The parties acknowledge that this action involves substantial document volumes. As of the date of this Protocol, based on preliminary collection and processing estimates, OWS has identified approximately 182,000 potentially responsive documents comprising approximately 1.4 million pages. Lumicore has identified approximately 147,000 potentially responsive documents comprising approximately 980,000 pages. These estimates are preliminary and may be revised as collection and processing activities continue. The parties further acknowledge that additional ESI may be identified as discovery progresses, particularly with respect to source code repositories, engineering databases, and structured data exports.
In light of these volumes, the parties agree to apply proportionality principles under Federal Rule of Civil Procedure 26(b)(1) throughout the ESI discovery process. In evaluating whether specific discovery requests or categories of ESI are proportional to the needs of the case, the parties and the Court shall consider, among other factors: the importance of the issues at stake in this action (OWS claims approximately $210 million in damages across the four asserted patents, encompassing both lost profits and reasonable royalty theories); the amount in controversy; the parties' relative access to relevant information (recognizing that Lumicore has unique access to its own engineering and design files for the accused products, while OWS has unique access to its patent prosecution files and competing product design files); the importance of the discovery in resolving the issues; whether the burden or expense of the proposed discovery outweighs its likely benefit; and the resources of the parties (both parties are established semiconductor companies with annual revenues exceeding $500 million).
The parties further agree that discovery of ESI from sources that are not reasonably accessible because of undue burden or cost shall not be required absent a showing of good cause under Federal Rule of Civil Procedure 26(b)(2)(B). Examples of sources that may not be reasonably accessible include, but are not limited to: disaster recovery backup tapes that are not indexed or searchable; legacy email systems or file servers that were decommissioned prior to the relevant time periods specified in Section 2.3; data stored on damaged or degraded media that would require specialized forensic recovery; and voicemail systems or other transient data repositories for which no routine preservation mechanism exists. If a party seeks discovery from a source claimed to be not reasonably accessible, the responding party shall identify the source and explain the basis for its claim of inaccessibility, and the requesting party may move the Court for an order compelling production upon a showing of good cause.
2.3 Temporal Scope
Unless otherwise agreed in writing by the parties or ordered by the Court, ESI shall be collected and produced for the following time periods, which the parties agree are reasonable and proportional given the nature of the claims and defenses in this action:
Patent prosecution and development documents: From November 22, 2014 (the filing date of the '562 Patent, which is the earliest priority date among the four asserted patents) through the present. This time period is intended to capture all documents relating to the conception, reduction to practice, and prosecution of the asserted patents, including inventor notebooks, prosecution correspondence with the United States Patent and Trademark Office, and internal communications regarding patentability assessments.
Accused product design and development documents (Lumicore): From January 1, 2015 (the year in which Lumicore was founded and incorporated in the State of Delaware) through the present. This time period is intended to capture the full lifecycle of the accused product families, from initial concept and design through current production, including all engineering specifications, design review documents, testing and characterization data, and product development meeting minutes.
Licensing and notice documents: From January 1, 2018 through the present. This time period is intended to encompass all licensing activities relating to the asserted patents, including the Asset Purchase Agreement between OWS and Solara Optics, Inc. dated June 15, 2018 (through which OWS acquired certain patent rights), the correspondence initiated by FairPoint Licensing Group, LLC beginning on or about January 15, 2023 (in its capacity as OWS's former licensing agent), and all subsequent licensing offers, negotiations, and pre-suit communications between or among the parties and their agents.
Financial and damages-related documents: From January 1, 2020 through the present. This time period is intended to encompass the period relevant to damages calculations, including revenue data, cost data, pricing information, profit margins, market share analyses, customer lists, and sales projections for the accused product lines and competing OWS products.
Prior-art-related documents: No temporal limitation shall apply to ESI relating to prior art, as prior art references may predate the earliest priority date of the asserted patents. This category includes, without limitation, documents relating to the identification, evaluation, or analysis of prior art by either party, as well as prior art references themselves.
Willful infringement documents: From October 2022 (the approximate date when OWS's internal engineering team first identified potential infringement by Lumicore's products) through the present. This time period is intended to capture all documents relevant to OWS's claim of willful infringement, including internal OWS analyses, communications with counsel regarding infringement opinions, and any communications between the parties regarding the asserted patents.
The temporal scope set forth above is without prejudice to either party's right to request production of ESI outside these time periods upon a showing of relevance and proportionality, subject to the meet-and-confer procedures in Section XI.
2.4 Custodians.  Each party shall identify its ESI custodians in its initial disclosures served pursuant to Federal Rule of Civil Procedure 26(a)(1) and may supplement its custodian list as discovery progresses and additional relevant custodians are identified. The identification of an individual as a custodian does not constitute an admission that all ESI in that individual's possession, custody, or control is responsive or relevant; rather, it reflects the party's good-faith assessment that the individual is likely to have potentially responsive ESI.
OWS has identified fourteen (14) custodians in its Litigation Hold Memorandum dated March 22, 2024. These custodians include, but are not limited to, the following individuals:
(a) Dr. Jian-Wei Huang, Chief Technology Officer;
(b) Dr. Nikolai Petrov, Vice President of Engineering, Photonics Division;
(c) Rebecca Tanaka, General Counsel;
(d) David Leitner, Chief Financial Officer;
(e) Dr. Priya Ramaswamy, Chief Executive Officer;
(f) Additional custodians as identified in OWS's initial disclosures and any supplemental disclosures.
Lumicore shall identify its custodians in its initial disclosures. Based on the parties' preliminary discussions, Lumicore's anticipated custodians include, but are not limited to, the following individuals:
(a) Dr. Sandra Michaud, Chief Technology Officer;
(b) Thomas "Tom" Kessler, Chief Executive Officer;
(c) Raymond Bautista, General Counsel;
(d) Dr. Eric Dalmqvist, Vice President of Product Development;
(e) Janet Moreno, Chief Financial Officer;
(f) Relevant engineering personnel involved in the design and development of the LumiLink 400G-ZR+, LumiLink 800G-DR8, and LumiEdge 1600G-LR product lines, whose identities will be disclosed in Lumicore's initial disclosures.
Either party may request the addition of custodians by written notice to the opposing party. The parties shall meet and confer in good faith regarding any proposed addition of custodians. If the parties cannot agree on whether a particular individual should be designated as a custodian, they shall follow the meet-and-confer procedures set forth in Section XI below before seeking Court intervention. In evaluating whether the addition of a custodian is warranted, the parties and the Court shall consider the likelihood that the proposed custodian possesses unique, non-duplicative responsive ESI, the burden and cost of collecting and processing the custodian's data, and the relevance of the anticipated ESI to the claims and defenses in this action.
III. PRESERVATION OBLIGATIONS
3.1 Litigation Hold
Each party represents and warrants that it has issued appropriate litigation hold notices to all identified custodians and relevant information technology personnel directing the preservation of all potentially relevant ESI. Each party further represents that its litigation hold is reasonably designed to ensure the preservation of ESI relevant to the claims and defenses in this action and that it has taken reasonable steps to monitor compliance with its litigation hold obligations.
OWS represents that its litigation hold was issued on March 22, 2024, to all identified custodians and the OWS Information Technology Department. The OWS litigation hold covers all documents, ESI, and communications relating to U.S. Patent Nos. 10,234,847; 10,891,193; 9,678,562; and 11,402,015, including patent prosecution files, inventor notebooks, and internal communications regarding the patented technologies; Lumicore and its products; and pre-suit licensing contacts and negotiations, including communications with FairPoint Licensing Group, LLC and its representatives. OWS further represents that it has issued reminder notices to all custodians on a periodic basis and has confirmed compliance with its litigation hold through direct communications with each custodian and the IT Department.
Lumicore represents that its litigation hold was issued on or before May 20, 2024, the date of its first appearance in this action. Lumicore further represents that its litigation hold covers all documents, ESI, and communications relevant to the claims and defenses in this action, including documents related to the design, development, manufacture, marketing, and sale of the accused product families; prior art references; and licensing and pre-suit communications.
3.2 Preservation of Metadata
Each party shall take reasonable steps to preserve the metadata of ESI, including but not limited to: file creation date, last-modified date, author, file path, file name, file extension, file size, and, for emails, email header information (including To, From, CC, BCC, Subject, and Date/Time Sent fields). Metadata preservation is essential to the integrity of the ESI discovery process and to the ability of both parties to authenticate and evaluate produced documents.
Neither party shall take any steps that would alter or destroy metadata of potentially responsive ESI, including but not limited to: opening or resaving files in a manner that overwrites metadata fields; converting files from one format to another without preserving the original file and its metadata; or moving files in a manner that alters their creation date, last-modified date, or file path. To the extent that collection or processing activities necessarily alter certain metadata fields (e.g., last-accessed date), the parties shall document such changes and preserve the original metadata values where feasible.
3.3 Suspension of Auto-Deletion Policies
Each party shall suspend any automatic deletion policies, programs, or routines as to all identified custodians and data sources for the duration of this litigation. This obligation extends to, but is not limited to: email retention policies that automatically delete emails after a specified period (including policies implemented through Strathmore Data Systems, Crestline Software, or similar email platforms); auto-purge settings on messaging platforms (including Meridian Solutions, Northgate Data Systems, and similar collaboration tools); document lifecycle management rules that automatically archive or delete documents based on age or usage criteria; and any other automated processes that would result in the destruction or alteration of potentially responsive ESI.
Each party shall take reasonable steps to confirm that all applicable auto-deletion policies have been suspended and shall monitor its systems on an ongoing basis to ensure continued suspension throughout the duration of this litigation.
3.4 Preservation of Source Code and Design Files
Lumicore shall preserve all source code, RTL schematics, photonic-IC layout files (including GDS-II and OASIS format files), mask files, fabrication run data, simulation data, and related design files for the accused product lines — specifically, the LumiLink 400G-ZR+, LumiLink 800G-DR8, and LumiEdge 1600G-LR — in their native formats. This preservation obligation extends to all version histories maintained in source code repositories (including Git, SVN, Perforce, or any other version control systems used by Lumicore), including commit logs, branch histories, merge histories, and associated author and date information. Lumicore shall not delete, overwrite, or alter any branches, tags, or commit history in the relevant repositories.
OWS shall preserve all source code and design files for its own competing products — specifically, the OWS-400ZR, OWS-800XR, and OWS-1600DR — to the extent such materials are responsive to Lumicore's discovery requests and counterclaims. OWS's preservation obligation with respect to its own source code and design files is subject to the same standards set forth above regarding the preservation of version histories and repository data.
IV. DOCUMENT REVIEW PLATFORM
4.1 Agreed Platform
The parties agree to use Relativity as the document review platform for purposes of hosting, reviewing, and producing documents in this litigation. Relativity is a widely used, industry-standard platform that supports the complex review, coding, and production workflows required in large-scale patent litigation. The parties have selected Relativity based on their mutual familiarity with the platform, its robust support for metadata management and advanced analytics, and its compatibility with the production format specifications agreed upon in this Protocol.
Each party shall maintain its own Relativity workspace for review and production purposes. The Producing Party's Relativity workspace shall be configured to house and manage that party's collected ESI, support the party's document review workflow (including privilege review, responsiveness review, and confidentiality designation), and generate productions in the formats specified in Section VII of this Protocol. The Receiving Party's Relativity workspace shall be configured to ingest and host productions received from the opposing party.
Relativity workspaces shall be configured to support the three-tier confidentiality designations established in the Stipulated Protective Order, such that documents may be coded and tracked at the "Confidential," "Highly Confidential — Attorneys' Eyes Only," and "Highly Confidential — Source Code" levels. Access controls within each party's workspace shall be implemented consistent with the access restrictions established in the Protective Order.
4.2 Vendor Selection
Each party may retain its own e-discovery vendor for the collection, processing, and hosting of ESI in connection with this litigation. The selection of an e-discovery vendor is within the sole discretion of each party, provided that the vendor selected has the capability and experience to comply with the specifications set forth in this Protocol. Neither party shall have any obligation to disclose the identity of its e-discovery vendor to the opposing party, although such disclosure may facilitate coordination on technical issues.
The parties shall coordinate on Relativity load file specifications to ensure interoperability between their respective workspaces. To that end, the parties have agreed upon the load file specifications set forth in Exhibit A to this Protocol. In the event that a party's e-discovery vendor encounters a technical issue that prevents compliance with the load file specifications, the party shall promptly notify opposing counsel and the parties shall meet and confer to resolve the issue.
4.3 Technology-Assisted Review (TAR)
Either party may, at its discretion, use technology-assisted review ("TAR"), predictive coding, or other advanced analytics tools as part of its document review process. The decision to employ TAR and the selection of a specific TAR methodology are within the discretion of each party, subject to the transparency obligations set forth below.
A party using TAR shall, upon reasonable request from the opposing party, disclose the following information regarding its TAR methodology:
(a) The TAR methodology employed, including whether the party used continuous active learning ("CAL"), simple active learning ("SAL"), simple passive learning ("SPL"), or another methodology, and a general description of the workflow;
(b) The seed set or training set methodology, including the approximate size of the seed set, how the seed set was selected (e.g., random sampling, judgmental sampling, or a combination), and the qualifications of the reviewers who coded the seed set;
(c) Validation metrics, including recall and precision rates achieved by the TAR model as determined through validation sampling, and the confidence level and margin of error associated with the validation sample; and
(d) The overall richness of the document population (i.e., the percentage of documents in the population that were coded as responsive by the TAR model).
The use of TAR shall not relieve either party of its obligation to conduct a reasonable review for attorney-client privilege and work-product protection prior to production. Each party employing TAR shall ensure that its TAR workflow includes appropriate privilege screening measures, which may include keyword-based privilege filters, domain-based filters (e.g., filtering for communications with counsel domains), and manual review of documents flagged as potentially privileged.
Any disputes regarding the adequacy of a party's TAR methodology, including disputes regarding the sufficiency of validation metrics or the reasonableness of the party's overall approach, shall be subject to the meet-and-confer procedures set forth in Section XI of this Protocol before any motion is filed with the Court.
V. COLLECTION PROTOCOLS
5.1 Collection Standards
All ESI shall be collected in a forensically sound manner that preserves the integrity of the data and all associated metadata. Collection activities shall be designed to ensure that the collected data is a true and complete copy of the original data as it existed at the time of collection, and that the collection process does not alter, corrupt, or destroy any portion of the data or its metadata.
Collection shall be performed by qualified personnel with training and experience in forensic data collection or by a third-party e-discovery vendor with demonstrated expertise in forensic collection of ESI. All collections shall be documented through chain-of-custody records that identify: the data source from which the collection was made; the date and time of collection; the individual or vendor performing the collection; the collection methodology and tools used; and the hash value(s) of the collected data. Chain-of-custody documentation shall be maintained by the collecting party for the duration of this litigation and shall be made available to the opposing party upon reasonable request.
Collections shall be verified using hash values (MD5 or SHA-1) to ensure data integrity. The hash value of the collected data shall be compared to the hash value of the source data (where feasible) to confirm that the collection is a complete and accurate copy. Any discrepancies shall be documented and addressed through re-collection where necessary.
5.2 Data Sources
Each party shall collect ESI from the following categories of data sources, as applicable to the party's data environment and to the extent such sources contain potentially responsive ESI:
(a) Email systems, including Strathmore Data Systems, Ashgrove Software / Drayton Solutions, Ridgeline Software, or other enterprise email platforms used by the party, for all identified custodians;
(b) Network file shares and shared drives, including departmental drives, project drives, and any other shared storage locations used by identified custodians or relevant departments (e.g., engineering, legal, finance, marketing);
(c) Local hard drives and laptops of identified custodians, to the extent such devices contain unique, non-duplicative ESI not available from network or cloud sources;
(d) Cloud storage services, including Severin Services Inc., Aldermere Systems, Hollowell Health IT, Larkspur Technologies, box, and any other cloud-based file storage platforms used by the party or its custodians;
(e) Collaboration platforms, including Northgate Data Systems, Meridian Solutions, Penmark Data Systems, Northpoint Technologies, and any other collaboration or project management tools used by identified custodians or relevant teams, including both messages and files shared through these platforms;
(f) Enterprise databases and ERP systems, including financial databases, accounting systems, and enterprise resource planning systems containing financial data relevant to damages calculations;
(g) Source code repositories, including Git, SVN (Apache Subversion), Perforce, and any other version control systems used to manage source code and design files for the accused product lines (Lumicore) or competing product lines (OWS);
(h) Engineering design tools and PLM systems, including product lifecycle management platforms, CAD systems, electronic design automation ("EDA") tools, and simulation software used in the design and development of the products at issue;
(i) Mobile devices, including smartphones and tablets of identified custodians, to the extent such devices contain unique, non-duplicative responsive ESI (e.g., text messages or messaging application data not available from other sources); and
(j) Paper documents that have been scanned and stored electronically, including documents maintained in document management systems, scanned archives, or PDF repositories.
The foregoing list is not exhaustive, and each party reserves the right to identify additional data sources as warranted by the circumstances of this case. The parties shall meet and confer regarding any disputes about the scope of data sources to be collected.
5.3 De-Duplication.  Each party shall de-duplicate ESI at the custodian level prior to production. Specifically, exact duplicates within a single custodian's collection shall be removed, such that only one copy of each unique document is retained for that custodian. Where the same document appears in multiple custodians' collections, the document shall be produced once and cross-referenced to all relevant custodians through the "Custodian" and "All Custodians" metadata fields in the load file.
De-duplication shall be performed using MD5 or SHA-1 hash values. Two documents shall be considered exact duplicates if and only if they produce identical hash values. Documents that are substantively similar but not identical (e.g., documents with different metadata but identical content) shall not be treated as duplicates unless they produce identical hash values.
Email de-duplication shall be based on a combination of email header fields (To, From, CC, BCC, Subject, Date/Time Sent, and Message-ID) and the hash value of the message body and attachments. An email shall be treated as a duplicate of another email only if all of the foregoing header fields are identical and the hash values of the message body and attachments are identical. Email threading shall be preserved such that complete email chains, including all prior messages in a thread, are maintained even where individual component messages within a chain are exact duplicates of messages in other chains.
5.4 De-NISTing.  System and application files shall be removed from collected ESI using the NIST National Software Reference Library ("NSRL") hash set prior to processing. The NSRL hash set identifies known, commercially available software files (e.g., operating system files, application program files) that are unlikely to be responsive to discovery requests. Removing such files reduces the volume of ESI that must be processed and reviewed without eliminating potentially responsive documents.
Notwithstanding the foregoing, De-NISTing shall not be applied to files that are specifically identified as responsive or potentially responsive, including proprietary software constituting source code at issue in this action. If a party has reason to believe that a file matching a NIST hash value is nonetheless responsive (e.g., because it is a proprietary file that happens to match a known file hash), the party shall retain the file for review and production.
VI. PROCESSING PROTOCOLS
6.1 Processing Standards
ESI shall be processed using industry-standard e-discovery processing tools, such as Brightmoor Health IT, Severin Software, or equivalent platforms, that are capable of extracting text, metadata, and embedded objects from a range file formats. The processing tools selected by each party shall be capable of handling the file types identified in this Protocol, including email files, office documents, PDF files, image files, engineering design files, and structured data exports.
Processing shall extract full text content from all documents where text extraction is available, as well as all metadata fields specified in Section 6.2 of this Protocol. Embedded objects (such as images, charts, and OLE objects within documents) shall be extracted and processed to the extent technically feasible. Where embedded objects contain text, that text shall be included in the extracted text output for the parent document.
Optical Character Recognition ("OCR") shall be applied to image-only documents (e.g., scanned PDFs, TIFF images) and to documents for which extracted text is not available or is insufficient (e.g., documents containing embedded images of text). OCR shall be performed using industry-standard OCR software at a quality level sufficient to produce reasonably accurate and searchable text. The parties acknowledge that OCR may not produce perfect text for all documents, particularly documents with poor image quality, handwritten content, or complex formatting, and the parties shall exercise good faith in evaluating the accuracy of OCR text.
6.2 Metadata Fields to Be Extracted
The following metadata fields shall be extracted and preserved for all processed ESI. These fields correspond to the load file specifications set forth in Exhibit A to this Protocol.
For emails:
For loose files (documents, spreadsheets, presentations, and other non-email files):
For source code and design files:
6.3 Date/Time Normalization
All date and time fields in processed ESI and production load files shall be normalized to Central Time ("CT"), which is consistent with the time zone of the Court (located in marshall, Texas) and the principal location of Lumicore's headquarters (Austin, Texas). This normalization ensures consistency across productions from both parties and facilitates the chronological ordering and searching of documents within the parties' respective Relativity workspaces.
Where the original time zone of a document or email cannot be determined (e.g., where the email system does not record time zone information), the processing vendor shall apply Central Time as the default time zone and note the assumption in the processing log. The parties acknowledge that time zone normalization may result in minor discrepancies for documents originating in other time zones, and such discrepancies shall not be a basis for objecting to the validity or admissibility of the produced document.
6.4 Handling of Encrypted or Password-Protected Files
If a party encounters encrypted or password-protected files during processing, it shall make reasonable efforts to obtain the password or decryption key from the custodian or from the party's IT department. "Reasonable efforts" include, but are not limited to: contacting the custodian identified as having possession, custody, or control of the file; checking any centralized password management systems maintained by the party; and attempting commonly used passwords or decryption methods.
If a password or decryption key cannot be obtained after reasonable efforts, the party shall log the file on a separate "Inaccessible Files Log" that identifies, at minimum: the file name; the file path; the custodian; the file type or extension; the approximate file size; and a brief description of the reason the file could not be processed (e.g., "Password-protected; password unknown and not obtainable from custodian"). The Inaccessible Files Log shall be provided to the opposing party upon request. If the opposing party believes that a file on the Inaccessible Files Log is likely to contain responsive, non-privileged material, the parties shall meet and confer regarding additional efforts to access the file, which may include the engagement of a forensic specialist at the requesting party's expense.
6.5 Exception Files
Files that cannot be processed due to corruption, unsupported file formats, or other technical errors shall be logged on the Inaccessible Files Log described in Section 6.4. The log entry for each exception file shall include the same information specified in Section 6.4, with the reason for the processing failure identified (e.g., "File corrupted; unable to extract text or metadata" or "Unsupported file format: .xyz"). The Inaccessible Files Log, including entries for both password-protected files and exception files, shall be provided to the opposing party upon request and shall be updated on a rolling basis as additional processing is completed.
VII. PRODUCTION FORMAT
7.1 General Production Format — TIFF + Load File
Unless otherwise specified in this Protocol, ESI shall be produced in single-page TIFF format at a resolution of 300 DPI (dots per inch) using Group IV compression. Each TIFF image shall represent a single page of the original document. Each TIFF production shall be accompanied by the following supporting files:
(a) A document-level load file in concordance DAT format, with pipe ("|") delimited fields and carrot ("þ") delimited multi-value fields, containing all extracted metadata fields specified in Section 6.2 of this Protocol. The load file shall use newline characters as row delimiters. Each row in the load file shall correspond to a single document (or a single email message, with attachments treated as separate documents linked by parent-child relationship fields). The complete load file specifications are set forth in Exhibit A to this Protocol.
(b) An image cross-reference file in Opticon OPT format, linking each page image to its document identifier (Bates number). The OPT file shall identify, for each page image: the Bates number of the page, the volume or folder designation, the file path to the image, the document break indicator (identifying whether the page is the first page of a new document), and the page count for the document.
(c) Extracted text files, one per document, containing the full text extracted from the document during processing. For image-only documents or documents for which extracted text is not available, OCR text files (one per document) shall be provided in lieu of extracted text files. Text files shall be named with the Bates number of the first page of the corresponding document (e.g., OWS-0000001.txt).
Each page produced in TIFF format shall be Bates-stamped with a unique production number in the following format: [Party Prefix]-[Seven-Digit Sequential Number]. OWS shall use the prefix "OWS-" (e.g., OWS-0000001, OWS-0000002, OWS-0000003). Lumicore shall use the prefix "LTC-" (e.g., LTC-0000001, LTC-0000002, LTC-0000003). Bates numbers shall be applied sequentially within each party's production and shall not contain gaps, duplicates, or non-sequential numbering. Bates numbers shall appear in the lower-right corner of each TIFF image in a legible font (minimum 10-point). The specifications for Bates numbering format and placement are further detailed in Exhibit B to this Protocol.
7.2 Redactions.  Where a Producing Party determines that a document contains both responsive, non-privileged content and content that is subject to a valid privilege or that requires redaction for confidentiality purposes under the Protective Order, the Producing Party may produce the document in redacted form. Redactions shall be applied to the TIFF image and shall be clearly indicated by a black or white redaction box overlaid on the redacted content. Each redaction box shall bear a legend identifying the basis for the redaction, such as "REDACTED — Attorney-Client Privilege," "REDACTED — Work Product," or "REDACTED — Confidential Third-Party Information," as applicable.
The corresponding extracted text or OCR text for any redacted document shall likewise be redacted to remove the privileged or protected content. The Producing Party shall ensure that the redacted text file does not contain any portion of the text underlying a redaction on the TIFF image. All redacted documents shall be logged on the Producing Party's privilege log in accordance with Section IX of this Protocol, with sufficient detail to permit the Receiving Party to assess the validity of the asserted privilege or protection.
Redactions shall not be used as a substitute for withholding documents in their entirety where partial redaction is not appropriate. If the privileged content of a document is so extensive that meaningful partial production is not possible, the document shall be withheld in full and logged on the privilege log.
7.3 Native-Format Productions
The following categories of ESI shall be produced in native format (in addition to or in lieu of TIFF, as specified below), in recognition of the fact that TIFF conversion is not adequate to preserve the full content, functionality, or utility of these file types:
Source code, RTL schematics, photonic-IC layout files, and mask files: These materials shall be produced in native format only; TIFF production is not required for source code or design files. All Source Code Materials shall be designated "Highly Confidential — Source Code" under the Protective Order. The production and inspection procedures for Source Code Materials are set forth in Section VIII of this Protocol.
Spreadsheets (Microsoft Excel, Stonefield Services Inc., and equivalent formats): Spreadsheets shall be produced in native format (.xlsx, .csv, or equivalent) in addition to the standard TIFF + load file production. The native format production is necessary to preserve formulas, embedded data, pivot tables, linked worksheets, and multi-tab structure that are not adequately captured in TIFF images. Where a spreadsheet contains multiple tabs or worksheets, the TIFF production shall include images of all tabs, and the native file shall include all tabs in their original configuration.
Databases and structured data exports: Databases and structured data shall be produced in native format (e.g., .csv, .xlsx, .accdb, or .sql) or in a mutually agreed-upon format that preserves the relational structure of the data, including table relationships, field definitions, and data types. The parties shall meet and confer on a case-by-case basis regarding the appropriate format for production of specific database or structured data sources, taking into account the nature and volume of the data and the Receiving Party's ability to import and analyze the data.
Presentations (Microsoft Northgate Services Inc., Tidewater Data Systems, and equivalent formats): Presentations shall be produced in native format in addition to the standard TIFF + load file production, where the TIFF production does not adequately capture embedded animations, speaker notes, multimedia content (such as embedded audio or video), or other features that are material to the content of the presentation. Where a presentation does not contain any such features and the TIFF production adequately represents the content of all slides, native format production is not required.
CAD files and engineering design files: CAD files (including files in Glenrock Technologies, Meridian Data Systems, cadence, Ridgeline Data Systems, and similar formats) shall be produced in native format. Where feasible, TIFF representations shall also be provided for reference purposes, but the native files shall be the authoritative production. The parties acknowledge that CAD and design files may require specialized software to view and that the Receiving Party is responsible for obtaining appropriate viewing tools.
Audio and video files: Audio and video files shall be produced in native format only. TIFF production is not applicable to audio and video content. Audio and video files shall be accompanied by load file entries identifying the file name, file path, file size, duration (where available), custodian, and date created or last modified.
7.4 Email Production
Emails shall be produced in TIFF + load file format as specified in Section 7.1 of this Protocol. Each email message shall be treated as a separate document, and each email attachment shall be produced as a separate document linked to its parent email through parent-child relationship metadata fields in the load file. The load file shall include the following parent-child relationship fields: ParentDocID (identifying the Bates number of the parent email for each attachment), AttachmentRange (identifying the Bates range of all attachments to a parent email), and FamilyID (a common identifier linking the parent email and all of its attachments).
Email threading shall be preserved through the Thread-ID and/or Conversation-Index metadata field, where such information is available from the email system. Preservation of email threading metadata enables the Receiving Party to reconstruct email conversations and identify the chronological sequence of communications within a thread.
Where an email contains inline images (e.g., images embedded in the body of the email rather than included as separate attachments), such inline images shall be rendered in the TIFF image of the email body. Where technically feasible, inline images shall also be extracted and produced as separate files linked to the parent email through the load file.
7.5 Confidentiality Designations
Each document produced pursuant to this Protocol shall bear a confidentiality designation consistent with the three-tier Stipulated Protective Order. Confidentiality designations shall be applied as follows:
For documents produced in TIFF format, the confidentiality designation shall appear in the lower-left corner of each TIFF image as a stamped legend (e.g., "CONFIDENTIAL," "HIGHLY CONFIDENTIAL — ATTORNEYS' EYES ONLY," or "HIGHLY CONFIDENTIAL — SOURCE CODE"). The confidentiality designation shall be in a legible font (minimum 8-point) and shall not obscure any portion of the document content.
For documents produced in native format, the confidentiality designation shall be identified in the load file metadata through a dedicated "Confidentiality" field. Additionally, native format productions shall be accompanied by a cover letter or transmittal identifying the confidentiality designation applicable to each document or group of documents.
A Producing Party may re-designate documents to a higher or lower tier of confidentiality upon written notice to the Receiving Party, subject to the provisions of the Protective Order. The Receiving Party may challenge the confidentiality designation of any document in accordance with the procedures established in the Protective Order.
7.6 Production Media
Productions of up to fifty gigabytes (50 GB) in total size may be transmitted via secure File Transfer Protocol ("FTP"), Secure File Transfer Protocol ("SFTP"), or other encrypted electronic transfer method agreed upon by the parties. The parties shall coordinate on the selection of an appropriate electronic transfer platform, which may include platforms offered by the parties' respective e-discovery vendors (e.g., Relativity Transfer, GoAnywhere, or equivalent).
Productions exceeding fifty gigabytes (50 GB) in total size shall be delivered on encrypted external hard drives or other encrypted physical media. All physical production media shall be encrypted using AES-256 encryption or an equivalent standard, and the encryption password shall be communicated separately from the physical media (e.g., by email or telephone). Physical production media shall be shipped via overnight courier with tracking and signature confirmation, and chain-of-custody documentation shall be maintained.
All production media, whether electronic or physical, shall be clearly labeled with: the case name (Optiwave Semiconductor Corp. v. Lumicore Technologies, Inc.); the case number (2:24-cv-00319-JRG); the producing party; the production date; the production volume designation (e.g., "Volume 1 of 3"); and the Bates range of documents included in the production (e.g., "OWS-0000001 through OWS-0045328").
VIII. SOURCE CODE PRODUCTION AND INSPECTION PROTOCOL
8.1 Applicability.  This Section VIII governs the production and inspection of source code, RTL schematics, photonic-IC layout files (including GDS-II and OASIS format files), mask files, fabrication run data, simulation data, and related design files (collectively, "Source Code Materials") of both parties. Source Code Materials constitute the most sensitive and commercially valuable information at issue in this litigation, and the parties have agreed to the procedures set forth in this Section to protect the confidentiality of such materials while permitting meaningful access for purposes of prosecuting and defending the claims in this action.
All Source Code Materials shall be designated "Highly Confidential — Source Code" under the Stipulated Protective Order. The procedures set forth in this Section are in addition to, and not in lieu of, the protections afforded by the Protective Order's "Highly Confidential — Source Code" tier.
By way of background, OWS's Second Set of Requests for Production (to be served on or about November 4, 2024) is expected to include thirty (30) supplemental requests for production specifically targeting Lumicore's source code repositories, photonic-IC mask files, and fabrication run data for the accused product families (LumiLink 400G-ZR+, LumiLink 800G-DR8, and LumiEdge 1600G-LR). Lumicore's corresponding discovery requests are expected to target OWS's competing product source code and design files to the extent relevant to Lumicore's invalidity and non-infringement defenses.
8.2 Production in Native Format
Source Code Materials shall be produced in native format, preserving the original directory structure, file naming conventions, and version/commit history as they exist in the Producing Party's source code repositories and file systems. The Producing Party shall not alter, reorganize, or rename files within the production except as necessary to comply with the Bates numbering and load file requirements of this Protocol.
Source code from repositories (e.g., Git, SVN, Perforce) shall be produced as complete repository snapshots or exports at relevant time points designated by the Receiving Party, including commit logs with dates and author information. The Producing Party shall produce, at minimum: (a) a snapshot of the current production version of the accused product's (or competing product's) source code as of the date of production; (b) snapshots at additional relevant time points as reasonably requested by the Receiving Party (e.g., the date of initial commercial release of each accused product, the date of receipt of any notice of infringement, and the date of filing of this action); and (c) commit logs covering the full development history of the relevant product or feature, including author, date, commit message, and files changed. The parties shall meet and confer regarding the specific time points for which repository snapshots are required.
8.3 Inspection Environment
Source Code Materials shall be made available for inspection at a secure, stand-alone computer workstation (the "Inspection Workstation") maintained at the producing party's outside counsel's office, at the following locations:
For OWS Source Code Materials: Calderwood & Harkness LLP, 350 South Grand Avenue, 48th Floor, Los Angeles, California 90071.
For Lumicore Source Code Materials: Hawthorne Vega & Cruz LLP, 600 Congress Avenue, Suite 2400, Austin, Texas 78701.
The Inspection Workstation shall satisfy the following security requirements:
(a) The workstation shall not be connected to any network, whether wired or wireless (i.e., the workstation shall be "air-gapped" from all internal and external networks);
(b) The workstation shall not have any external ports enabled, including USB ports, Thunderbolt ports, SD card slots, Bluetooth adapters, or other data transfer interfaces, other than a single printer connection for making hard-copy excerpts as described in Section 8.5;
(c) The workstation shall not have any screen-capture, screen-recording, or remote-access software installed;
(d) The workstation shall be equipped with appropriate software tools for viewing and navigating source code and design files, including a text editor, a source code viewer or IDE (integrated development environment), and, for photonic-IC layout files, an appropriate GDS-II / OASIS viewer; and
(e) The workstation shall be located in a private, lockable room at the producing party's outside counsel's office, and access to the room shall be controlled and logged.
The Producing Party's counsel shall be responsible for setting up and maintaining the Inspection Workstation, including loading the Source Code Materials onto the workstation's local hard drive and ensuring that the workstation remains in compliance with the security requirements specified herein. The cost of setting up and maintaining the Inspection Workstation shall be borne by the Producing Party.
8.4 Access Restrictions
Access to Source Code Materials shall be limited to the individuals designated under the "Highly Confidential — Source Code" tier of the Stipulated Protective Order. As of the date of this Protocol, the individuals authorized to access Source Code Materials include:
(a) Outside counsel of record for the Receiving Party and their direct support staff (including associates, paralegals, and litigation support personnel) who have executed the Acknowledgment and Agreement to Be Bound form required by the Protective Order;
(b) For OWS (as Receiving Party inspecting Lumicore Source Code Materials): Up to two (2) designated technical experts — specifically, Dr. Caroline Ashford and Kevin Ng of Benchmark Semiconductor Analysis, LLC — who have executed the Acknowledgment and Agreement to Be Bound form;
(c) For Lumicore (as Receiving Party inspecting OWS Source Code Materials): Up to two (2) designated technical experts — specifically, Dr. Rajesh Sundaram and one additional designee to be identified by Lumicore no later than thirty (30) days prior to Lumicore's first scheduled source code inspection session — who have executed the Acknowledgment and Agreement to Be Bound form.
No in-house counsel, employees, officers, directors, or agents of any party shall have access to the opposing party's Source Code Materials. This restriction applies regardless of whether such individuals have signed the Acknowledgment and Agreement to Be Bound form required by the Protective Order.
8.5 Inspection Procedures
The Receiving Party shall provide at least five (5) business days' written notice to the Producing Party before scheduling a source code inspection session. The notice shall identify: the individual(s) who will conduct the inspection; the date and time of the proposed inspection; and a reasonable description of the categories of Source Code Materials to be inspected during the session (to enable the Producing Party to ensure that the relevant materials are loaded on the Inspection Workstation).
Inspection sessions shall be conducted during normal business hours (9:00 AM to 6:00 PM local time at the location of the Inspection Workstation) and shall not exceed eight (8) hours per session without the prior written consent of the Producing Party. The Producing Party shall use good faith efforts to accommodate the Receiving Party's scheduling requests, and the parties shall cooperate to ensure that a reasonable number of inspection sessions are made available.
During the inspection, the inspecting individual may take handwritten notes. All such handwritten notes shall be treated as "Highly Confidential — Source Code" under the Protective Order and shall be subject to all of the restrictions applicable to materials bearing that designation, including restrictions on copying, distribution, and storage. The inspecting individual shall not bring any electronic devi