Build a patent-infringement chronology by separating event dates from document dates, linking each factual proposition to an exact source, and identifying the asserted claim, accused product version, or defense it affects. Preserve conflicting accounts and distinguish documentary support from technical inference. The deliverable is a reviewable timeline with pinpoint citations, uncertainty flags, and assigned follow-up—not merely a date-sorted document list. Counsel can use it to test infringement narratives, prepare witnesses, and identify evidentiary gaps without treating chronology entries as legal conclusions.
Use this workflow when an initial production arrives, revised contentions change the relevant product versions, or deposition preparation exposes inconsistent accounts of development, deployment, notice, or sales. It serves litigation counsel, in-house teams, technical reviewers, and experts working from a common factual record.
Keep the chronology tied to disputed questions. A firmware release deserves an entry when it helps explain a change in accused functionality; a notice communication deserves separate entries when transmission, receipt, or attachment contents remain disputed. Do not infer legal significance from chronological proximity.
This guide assumes US federal district-court litigation. Check the applicable rules, judge’s orders, and protective order rather than transferring this framework unchanged to arbitration, ITC investigations, or PTAB proceedings. The Northern District of California rules cited here cover the utility-patent actions described in Patent L.R. 1-2; they are not nationwide patent-litigation requirements. See Patent L.R. 1-2. (cand.uscourts.gov)
Start with the operative pleadings, asserted patents and claims, current contentions, claim-construction materials, and accused-product list. Include version identifiers and the particular configurations under examination. These inputs define which events belong in the timeline.
Gather available supporting records:
Maintain a source register with Bates ranges or native IDs, document families, custodians, confidentiality designations, and collection information. Note unavailable repositories and incomplete families instead of treating the production as complete.
Keep requests for missing evidence within the applicable discovery scope. Rule 26(b)(1) permits discovery of nonprivileged matter relevant to claims or defenses and proportional to the case; information need not be admissible to be discoverable. Relevance alone does not establish entitlement to unrestricted collection or production. See Federal Rule of Civil Procedure 26(b)(1). (uscourts.gov)
Use Patent Infringement Matters — Case chronology as the working template. You can copy this table into your working document or spreadsheet. Assign stable event IDs so sorting does not break cross-references.
| Event ID | Event date / basis | Document date | Event / status | Patent / version / issue | Source / pinpoint | Conflict / gap | Action / owner |
|---|---|---|---|---|---|---|---|
“Event date / basis” distinguishes an exact date, supported range, retrospective report, or inference. “Document date” records when the source was created or communicated, not necessarily when the event happened. Keep collection dates in the linked source register.
Use “Event / status” for one narrow proposition and a label such as documented, reported, inferred, or disputed. “Documented” means the cited record directly supports the stated proposition; it does not mean the proposition is conclusively established.
For “Source / pinpoint,” supply a Bates page, transcript lines, or native ID and precise location. Identify code by version or commit, path, and relevant lines or function; identify spreadsheets by file version, worksheet, and cells.
The issue field links to a specific patent and claim-chart entry, accused configuration, defense question, or damages issue. Put contradictory event IDs and missing evidence in the gap field. Assign follow-up and any foundation question to a named role or reviewer.
Write three to five factual questions before extracting events: When did the accused function enter a shipping build? Which customer configurations contained it? What did the recipient receive with the notice email?
Set a provisional date range, patent list, and version naming convention. Distinguish hardware revisions, firmware versions, feature settings, and customer configurations when a commercial name encompasses different implementations.
In the Northern District of California, Patent L.R. 3-1 requires identification of asserted claims and accused instrumentalities and charts locating claim limitations, subject to modification under Rule 1-3. Use those contentions as organizing inputs, not as substitutes for underlying evidence. See Patent L.R. 1-3 and 3-1. (cand.uscourts.gov)
Record: Apply consistent patent, claim, and version labels; flag unresolved product identity in the gap field.
Confirm that each source can be reopened and distinguished from duplicates, later revisions, and attachments. Preserve the original filename, native identifier, production reference, and family relationships in the source register.
For repository records, distinguish author dates, commit dates, export dates, and release records. For email, inspect the message, headers where available, and attachments rather than relying on a search snippet. Treat a planned release date as a plan unless another record supports actual release or deployment.
Record: Enter the precise source location and provenance limitation. Keep an unavailable source only as an unverified lead with a retrieval action, not as a verified event.
Write one independently testable proposition per row. Separate internal testing, release approval, shipment, installation, and activation even if a witness calls them collectively “launch.”
Retain original timestamps and time zones when sequence matters. If dates are normalized, preserve the original values and conversion method in the source register. Do not convert “late spring” into an exact day or silently assign the first day of a month.
A later email describing an earlier event supports a retrospective report. Its precise timestamp does not make the reported event contemporaneously documented.
Record: Enter the event date, its basis, document date, and factual-status label. Use a supported range or “unknown” rather than unsupported precision.
Link technical events to the relevant claim-chart entry and accused version. Ask whether the source describes actual operation, proposed design, testing, or a reviewer’s interpretation. Keep those propositions separate.
For potential prior art, distinguish filing, publication, public accessibility, sale, and use dates. Track their supporting evidence without deciding statutory eligibility in the chronology. For notice, separate preparation, transmission, receipt, and attachment contents; assign the legal-effect question for counsel’s separate analysis.
For sales records, identify the transaction date and product configuration actually shown. Do not label a shipment “infringing” merely because it falls within an asserted damages period.
Record: Populate the issue field and identify missing technical interpretation, configuration evidence, or legal analysis.
Compare engineering, sales, support, and witness accounts. Apparent conflicts may involve different builds, regions, customers, or meanings of “available.” Test those explanations before choosing a preferred account.
Where sources genuinely disagree, preserve separate propositions with linked event IDs. Explain why one account currently appears better supported while keeping contrary evidence visible. A limited production’s silence should remain a collection gap, not become a finding that an event never occurred.
Record: Identify the conflicting IDs, unresolved question, and concrete next action. Replace “investigate” with “compare build manifest against shipment configurations; technical reviewer responsible.”
Identify who could explain each important source and whether that person has firsthand knowledge. Distinguish signed statements, testimony, interview notes, and counsel’s inferences.
Evidence Rule 901 requires sufficient evidence supporting a finding that an item is what its proponent claims; testimony from a knowledgeable witness is one listed authentication method. Authentication is a separate question from other admissibility requirements. See Federal Rule of Evidence 901. (uscourts.gov)
Carry confidentiality designations into working references, particularly for restricted source code. Keep legal hypotheses in appropriately restricted linked notes. Refer protection and sharing questions for individualized review rather than assuming a privilege label resolves them.
Record: Assign foundation and protection-review questions in the action field without exposing sensitive analysis in broadly shared rows.
Have a reviewer reopen every source supporting a central event. Confirm that the citation supports the whole proposition, not merely a nearby date or product name. Review contrary records and maintain an inclusion log explaining material exclusions.
Label the output by intended use. Rule 1006 concerns summaries of voluminous admissible materials that cannot conveniently be examined in court, whether or not the underlying materials are introduced. Originals or duplicates must be available for examination or copying at a reasonable time and place. Charts functioning only as illustrative aids instead fall under Rule 107. See Federal Rules of Evidence 1006 and 107. (uscourts.gov)
Record: Close verified actions, assign open issues, and identify the version and its internal, illustrative, or proposed evidentiary purpose. Preserve superseded versions and explain material corrections.
Fictional scenario: Latticebrook Instruments accuses Harborcoil Systems’ Beacon controller of practicing claim 7 of fictional Patent P-Alpha. Counsel’s working claim chart associates limitation 7(c) with adaptive queue control. The factual dispute concerns firmware 4.2 in customer units and a later notice communication. All parties, products, clauses of the claim chart, documents, and references are fictional.
The production contains a release memorandum, a shipment extract, and an email export from the recipient’s mailbox. It lacks the relevant build manifest, customer configurations, and email attachment. The export shows a received-message timestamp, but the attachment’s contents remain unknown.
| Event ID | Event date / basis | Document date | Event / status | Patent / version / issue | Source / pinpoint | Conflict / gap | Action / owner |
|---|---|---|---|---|---|---|---|
| E-01 | Mar. 4, 2025; retrospective report | Mar. 5, 2025 | Memorandum reports 4.2 approval; reported | P-Alpha / 7(c) / 4.2 approval | HC000120, p. 2 | Approval does not establish deployed behavior; manifest missing | Obtain manifest and compare implementation; technical reviewer |
| E-02 | Mar. 11–14, 2025; shipment rows | Mar. 18, 2025 | Extract records Beacon shipments; documented | P-Alpha / 7(c) / version unknown | HC-N17, Shipments!A21:F26 | Firmware field blank; no link to 4.2 | Match units to configurations; discovery lead |
| E-03 | Apr. 9, 2025; received-message timestamp | Apr. 9, 2025 | Mailbox export records message referencing attachment; documented | P-Alpha / notice contents | HC000244, header and body | Attachment missing; contents unverified | Retrieve message family and check receipt evidence; review counsel |
These entries change the next decision. March 4 cannot yet be described as the first infringing shipment: it is a reported approval date, and the shipment extract does not identify firmware. Counsel should first match shipped units to configurations and examine the accused function against the relevant limitation.
The email likewise supports a narrower proposition than receipt of a particular patent attachment. Its missing family member requires targeted retrieval, not reconstruction from the sender’s description. Even if the attachment is recovered, its legal significance remains a separate question. Neither missing record is supplied by inference.
DecoverAI is the Legal Intelligence Platform for litigation and transactions. Its verified litigation capabilities include document review, chronology, evidence analysis, privilege and confidentiality analysis, and deposition preparation. Use its chronology capabilities to support timeline work and trial preparation capabilities for related witness preparation. Counsel retains responsibility for verifying citations, configuration distinctions, and legal significance. To discuss this patent chronology workflow, book a demo.
No. One document may support several events, and several documents may support one proposition. Include events answering the defined factual questions; retain other materials in the source register. Avoid duplicate rows that merely repeat the same event from different sources.
Identify the repository extract, commit or version, path, and relevant location. Separate code changes from released builds and deployed configurations. Assign technical review when operation is inferred, and observe the protective order’s restrictions on copying or sharing code references.
Date sorting is not the eligibility analysis. Track distinct date types, provenance, and evidence of public accessibility where relevant. Assign statutory treatment and claim mapping for separate review rather than labeling an early internal record qualifying prior art.
Review its purpose, confidentiality restrictions, and sensitive analysis first. Prepare a scoped version with source references and visible uncertainty. Keep counsel’s hypotheses separate so the witness can identify firsthand knowledge, disagreement, and matters outside their knowledge.
Scope: General workflow guidance for professional readers, not advice for a particular matter.
This guide is general information about legal workflows, not legal advice for any matter. It was drafted and reviewed with AI assistance. The worked example is fictional. Contract rights and procedure depend on the governing law, the actual wording, and the facts, so check the cited sources and the rules that apply in your jurisdiction before relying on it.