DCT
5:25-cv-10399
Synopsys Inc v. Real Intent Inc
Key Events
Amended Complaint
Table of Contents
complaint Intelligence
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Synopsys, Inc. (Delaware)
- Defendant: Real Intent, Inc. (California)
- Plaintiff’s Counsel: Willkie Farr & Gallagher LLP
- Case Identification: 5:25-cv-10399, N.D. Cal., 02/19/2026
- Venue Allegations: Venue is alleged to be proper in the Northern District of California because Defendant is a California corporation with its principal place of business in Sunnyvale, California, within the district.
- Core Dispute: Plaintiff alleges that Defendant’s electronic design automation (EDA) software products for static verification of integrated circuits infringe nine patents related to clock-domain crossing verification, glitch detection, and other circuit analysis techniques.
- Technical Context: The lawsuit concerns highly specialized software tools used in the semiconductor industry to verify the correctness of complex integrated circuit (IC) and System-on-a-Chip (SoC) designs before manufacturing, a critical step to avoid costly errors.
- Key Procedural History: The complaint alleges Defendant had knowledge of several patents-in-suit prior to the lawsuit, based on citations made during the prosecution of Defendant's own patent applications. It also notes a prior lawsuit filed by Plaintiff against Defendant in the Western District of Texas on March 27, 2025, involving six of the same patents, which was litigated for nearly a year before being dismissed for improper venue in December 2025.
Case Timeline
| Date | Event |
|---|---|
| 2002-04-09 | '733 Patent Priority Date |
| 2010-09-20 | '513 Patent Priority Date |
| 2010-10-05 | '560 Patent Priority Date |
| 2011-01-07 | '706 Patent Priority Date |
| 2012-03-09 | '173 Patent Priority Date |
| 2012-10-05 | '993 Patent Priority Date |
| 2013-10-31 | '948 Patent Priority Date |
| 2013-12-10 | '173 Patent Issued |
| 2014-02-11 | '513 Patent Issued |
| 2014-02-11 | '560 Patent Issued |
| 2014-07-22 | '993 Patent Issued |
| 2014-10-07 | '706 Patent Issued |
| 2015-08-21 | '394 Patent Priority Date |
| 2016-06-30 | '773 Patent Priority Date |
| 2016-09-15 | Defendant allegedly aware of '513 Patent via its own patent application filing |
| 2016-12-27 | '948 Patent Issued |
| 2017-10-17 | '394 Patent Issued |
| 2018-01-01 | Plaintiff alleges Defendant searched for and reviewed Plaintiff's patents (approx. date) |
| 2019-05-14 | '773 Patent Issued |
| 2020-02-07 | Defendant allegedly aware of '394 Patent via patent examiner citation |
| 2020-04-03 | Defendant allegedly aware of '773 Patent via patent examiner citation |
| 2025-03-27 | Prior lawsuit (WDTX Case) filed, giving Defendant explicit knowledge of six patents-in-suit |
| 2025-12-01 | WDTX Case dismissed for improper venue (approx. date) |
| 2026-02-19 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,607,173 - Hierarchical Bottom-Up Clock Domain Crossing Verification
- Issued: December 10, 2013 (the ’173 Patent).
The Invention Explained
- Problem Addressed: The patent addresses the time-consuming and complex process of verifying clock-domain crossings (CDC) in large, modern integrated circuit (IC) designs Compl. ¶28 Prior art methods that verified the entire design at once were too slow, while methods that partitioned the design often resulted in incomplete verification because they lacked a "holistic abstraction scheme" Compl. ¶29 Compl. ¶31
- The Patented Solution: The invention proposes a "hierarchical bottom-up" verification method Compl. ¶28 Instead of analyzing the entire IC, the method first verifies the lowest-level modules in the design hierarchy Compl. ¶30 Once a low-level module is successfully verified, it is replaced with a simplified "abstraction module" that retains only the essential CDC information for its inputs and outputs Compl. ¶29 This process is repeated up the hierarchy, allowing for faster verification of higher-level modules because they interact with the simplified abstractions rather than the full, complex sub-modules Compl. ¶33 This process is illustrated in the complaint's reproduction of the patent's Figure 1, which shows module M4 being verified and abstracted before module M2, which in turn is verified and abstracted before module M1 Compl. ¶30 Compl. p. 8
- Technical Importance: This approach allows for efficient, repeated verification cycles on complex System-on-a-Chip (SoC) designs without the high computational burden associated with complete re-runs, improving the function of the verification computer Compl. ¶30 Compl. ¶33
Key Claims at a Glance
- The complaint asserts independent claim 1 and dependent claims 2, 4, and 5 Compl. ¶101 Compl. ¶111
- The essential elements of independent claim 1 include:
- Identifying a module that has not been previously abstracted or changed Compl. ¶101
- Performing a CDC verification on the module in a bottom-up fashion by a computer processor Compl. ¶101
- Replacing the verified module with a corresponding abstraction module that correctly identifies clock-domains for its inputs and outputs Compl. ¶101
- Repeating this identifying, performing, and replacing process for the remaining modules Compl. ¶101
- Storing the updated IC model, which includes at least one replaced module Compl. ¶101
- The complaint explicitly reserves the right to assert additional claims Compl. ¶111
U.S. Patent No. 9,792,394 - Accurate Glitch Detection
- Issued: October 17, 2017 (the ’394 Patent).
The Invention Explained
- Problem Addressed: The patent addresses the challenge of accurately detecting "glitches"—transient, unwanted signal changes—in complex circuit designs Compl. ¶37 Traditional glitch detection tools were prone to producing a large number of false positives because they analyzed a low-level (e.g., "netlist") representation of the circuit without properly accounting for "glitch-blocking circuitry" that is more readily identifiable at a higher level of abstraction (e.g., Register-Transfer Level or "RTL") Compl. ¶41 Compl. ¶47
- The Patented Solution: The patented method involves a two-level analysis to improve accuracy Compl. ¶42 First, a higher-level abstraction (RTL) of the circuit is analyzed to identify glitch-blocking circuits, their corresponding "enable signals," and the "blocking values" that should prevent glitches Compl. ¶43 Second, the lower-level abstraction (netlist) is analyzed to find potential glitches. A design problem is identified only if a potential glitch at the low level is not blocked when its corresponding high-level enable signal is assigned its blocking value Compl. ¶43 This dual-level flow is depicted in the complaint's reproduction of the patent's Figure 3 Compl. ¶45 Compl. p. 15
- Technical Importance: This method provides a more accurate and reliable glitch detection process by filtering out false positives, thereby reducing the time and effort required for designers to identify and fix actual design problems Compl. ¶47
Key Claims at a Glance
- The complaint asserts independent claim 1 and dependent claims 2, 3, 4, and 8 Compl. ¶129 Compl. ¶142
- The essential elements of independent claim 1 include:
- Analyzing a higher-level abstraction to identify glitch-blocking circuits, an enable signal for each, and a corresponding blocking value for each enable signal Compl. ¶129
- Analyzing a lower-level abstraction to identify a possible glitch in a first signal Compl. ¶129
- Identifying a first enable signal in the lower-level abstraction that corresponds to a glitch-blocking circuit intended to block glitches in the first signal Compl. ¶129
- Detecting a design problem upon determining that the possible glitch is not blocked when the first enable signal is assigned the first blocking value Compl. ¶129
- The complaint asserts additional dependent claims Compl. ¶142
U.S. Patent No. 8,650,513 - Reducing X-Pessimism in Gate-Level Simulation and Verification
- Patent Identification: U.S. Patent No. 8,650,513, issued February 11, 2014 Compl. ¶15
- Technology Synopsis: The patent addresses "X-pessimism," a phenomenon in circuit simulation where the propagation of indeterminate ("X") values leads to more indeterminate outputs than would occur in the actual silicon, particularly in paths where a signal splits and later reconverges Compl. ¶¶49-51 The patented solution involves analyzing a design to identify paths likely to exhibit X-pessimism and adding a "correcting block" that produces the deterministic value an actual circuit would produce Compl. ¶52
- Asserted Claims: Independent claims 1 and 21 are asserted Compl. ¶160 Compl. ¶166
- Accused Features: The complaint alleges that Defendant's Ascent XV, Verix SimFix, and other products use static analysis and mathematical techniques to identify and "fix pessimistic X’s in simulation," allegedly implementing the claimed method Compl. ¶163 Compl. ¶165
U.S. Patent No. 8,359,560 - Methods and Systems for Debugging Equivalent Designs Described at Different Design Levels
- Patent Identification: U.S. Patent No. 8,359,560, issued February 11, 2014 Compl. ¶16
- Technology Synopsis: The patent addresses the "technological bottleneck" of debugging IC designs across different levels of abstraction, such as the RTL and gate levels Compl. ¶57 The invention enables synchronous debugging by presenting the design at two levels in separate sets of windows; when a user selects a signal in one window (e.g., RTL level), the corresponding signal in the other window (e.g., gate level) is automatically selected, reducing debugging time Compl. ¶58
- Asserted Claims: Independent claim 1 is asserted Compl. ¶189
- Accused Features: Defendant's iDebug and SafeConnect products are accused of infringement Compl. ¶190 The complaint alleges these tools provide a debugging environment that operates on both RTL and Netlist levels, uses information to correlate signals between them, and presents them in separate windows (iDebug and iVision) Compl. ¶¶192-194
U.S. Patent No. 10,289,773 - Reset Domain Crossing Management Using Unified Power Format
- Patent Identification: U.S. Patent No. 10,289,773, issued May 14, 2019 Compl. ¶17
- Technology Synopsis: The patent presents a method for managing both reset domain crossings (RDCs) and power domain crossings (PDCs) together Compl. ¶63 Conventional approaches handled them separately, leading to redundant isolation circuitry. The invention analyzes both Hardware Description Language (HDL) and Unified Power Format (UPF) files to identify signals that cross both domain types, allowing for the use of shared, non-redundant isolation gates to improve circuit size and performance Compl. ¶63 Compl. ¶66
- Asserted Claims: Independent claims 1 and 11 are asserted Compl. ¶216 Compl. ¶223
- Accused Features: Defendant's Meridian RDC and SafeConnect products are alleged to infringe by incorporating "power related resets" during RDC verification, utilizing both HDL and UPF descriptions to identify signals forming both RDCs and PDCs, and generating reports on candidates for shared isolation Compl. ¶217 Compl. ¶218 Compl. ¶221
U.S. Patent No. 9,529,948 - Minimizing Crossover Paths for Functional Verification of a Circuit Description
- Patent Identification: U.S. Patent No. 9,529,948, issued December 27, 2016 Compl. ¶18
- Technology Synopsis: The patent aims to optimize functional verification by reducing the number of "crossover paths" (signal paths crossing power domains) that need to be evaluated Compl. ¶69 Instead of analyzing all paths, the invention leverages low-power information (from UPF files) to identify which power state combinations are relevant, generating a reduced, "functional" set of crossover paths for analysis, which speeds up verification Compl. ¶¶70-71
- Asserted Claims: Independent claim 1 is asserted Compl. ¶244
- Accused Features: Defendant's Meridian CDC, Meridian RDC, and SafeConnect products are accused of infringement Compl. ¶245 They are alleged to perform functional verification by using power design information (UPF format) to determine power state combinations and generate a reduced set of crossover paths for analysis Compl. ¶249 Compl. ¶253 Compl. ¶255
U.S. Patent No. 8,856,706 - System and Method for Metastability Verification of Circuits of an Integrated Circuit
- Patent Identification: U.S. Patent No. 8,856,706, issued October 7, 2014 Compl. ¶19
- Technology Synopsis: The patent addresses shortcomings in traditional CDC verification, which often generated false violations by relying on a-priori structural recognition (e.g., of a FIFO) Compl. ¶77 The invention provides a "comprehensive and systematic approach" that uses "structural pruning" to identify potential source-destination synchronization points and then checks whether each source is actually synchronized based on a set of domain, logic, and functional requirements Compl. ¶77 Compl. ¶78
- Asserted Claims: Independent claim 14 is asserted Compl. ¶277
- Accused Features: Defendant's Meridian CDC product is accused of performing metastability verification Compl. ¶278 Compl. ¶280 It is alleged to determine source-to-destination paths, perform "structural pruning" to identify synchronization points, and store the synchronized or unsynchronized result Compl. ¶281 Compl. ¶282 Compl. ¶284
U.S. Patent No. 6,993,733 - Apparatus and Method for Handling of Multi-Level Circuit Design Data
- Patent Identification: U.S. Patent No. 6,993,733, issued January 31, 2006 Compl. ¶20
- Technology Synopsis: The patent describes a "look-ahead" design methodology to identify design errors earlier in the multi-stage IC design process Compl. ¶85 Instead of finding errors late and repeating the entire design cycle, the invention uses a "constraint engine" or "constraint database" to collect constraints applicable to various design stages (e.g., synthesis, test) and apply them much earlier, allowing for quicker identification and correction of errors at the highest design level possible Compl. ¶87 Compl. ¶89
- Asserted Claims: Independent claim 35 is asserted Compl. ¶307
- Accused Features: Defendant's SafeConnect and iDebug products are alleged to perform "look-ahead design analysis" Compl. ¶308 Compl. ¶309 They are accused of using a "constraint database" (a customizable "library of rules") to perform hierarchical and structural analysis and detect design violations Compl. ¶310 Compl. ¶311 Compl. ¶312
U.S. Patent No. 8,788,993 - Computer System for Generating an Integrated and Unified View of IP-Cores for Hierarchical Analysis of a System on Chip (SoC) Design
- Patent Identification: U.S. Patent No. 8,788,993, issued July 22, 2014 Compl. ¶21
- Technology Synopsis: The patent addresses the difficulty of verifying large SoCs that incorporate numerous third-party intellectual property (IP) cores Compl. ¶92 The invention creates verification-specific "abstracted views" for each IP core and for each type of verification (e.g., CDC, DFT, PM). It then integrates these different views into a single "unified abstracted view" by comparing attributes, identifying redundancies, and combining them, allowing different verification programs to run efficiently on the same hierarchical design Compl. ¶¶93-94 Compl. ¶96
- Asserted Claims: Independent claim 1 is asserted Compl. ¶330
- Accused Features: Defendant's Meridian CDC and Meridian RDC products are accused of infringement Compl. ¶331 They are alleged to be systems for verifying IP cores in SoCs that receive RTL and block-level constraints as inputs, generate abstracted views (a "transparent hierarchical model" or "Meta-Database"), and use them for verification Compl. ¶¶333-337
III. The Accused Instrumentality
Product Identification
- The complaint names several of Defendant’s EDA software products, principally: Meridian CDC, Meridian RDC, SafeConnect, iDebug (which includes iVision), Ascent XV, Meridian RXV, Verix SimFix, SimPortal, Ascent AutoFormal, and Sentry (Compl. ¶102; Compl. ¶130; Compl. ¶161; Compl. ¶190; Compl. ¶217; Compl. ¶245; Compl. ¶278; Compl. ¶308; Compl. ¶331).
Functionality and Market Context
- The accused products are software tools for the static verification and "sign-off" of digital IC and SoC designs (Compl. ¶7). Their functions, as alleged in the complaint, include clock-domain crossing (CDC) verification, reset-domain crossing (RDC) verification, glitch detection, connectivity checking, and reducing "X-pessimism" during gate-level simulation (Compl. ¶103; Compl. ¶132; Compl. ¶163).
- The complaint alleges these tools operate on various levels of circuit design abstraction, including Register-Transfer Level (RTL) and gate-level (netlist) (Compl. ¶131). The Meridian products are described as employing a "hierarchical flow" and using a "meta-database" to store information from lower-level block analysis for use in higher-level verification (Compl. ¶104; Compl. ¶106). A presentation slide reproduced in the complaint shows Real Intent's "Glitch Sign-off Flow," which depicts separate analysis steps for RTL and Netlist levels (Compl. ¶131; Compl. p. 47).
- The complaint positions Defendant as a direct competitor to Plaintiff in the EDA market for static verification tools (Compl. ¶8).
IV. Analysis of Infringement Allegations
U.S. Patent No. 8,607,173 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method for clock-domain crossing (CDC) verification of a model of an integrated circuit (IC) comprising a plurality of modules... | Defendant's Meridian CDC product "enables quick clock domain crossing verification, from individual blocks to billion-gate SoC designs." | ¶103 | col. 1:7-11 |
| identifying a module from among the plurality of modules that has not been previously abstracted... | Defendant's Meridian CDC product operates with a "hierarchical flow" in which individual IP or blocks are identified for verification. | ¶104 | col. 1:63-66 |
| performing a CDC verification on the module in a bottom-up fashion by a computer processor device; | Defendant's Meridian CDC product enables "bottom-up or top-down CDC analysis," where lower-level CDC information is used at the top level. A slide from a public presentation illustrates Meridian CDC's "hierarchical flow" (Compl. p. 38). | ¶105 | col. 1:67-2:1 |
| replacing the module with a corresponding abstraction module that correctly identifies a corresponding clock-domain for each of the input and the output... | Defendant's product uses a "meta-database" to store abstraction modules for a given IC component. | ¶106 | col. 2:2-5 |
| repeating the identifying, performing, and replacing for each of the remaining modules from among the plurality of modules; | Defendant's product performs an iterative process where "as higher-level subsystems or SoCs are assembled, the CDC information from the lower levels is used at the top level for CDC verification." | ¶108 | col. 2:6-8 |
| storing an updated model of the IC comprising at least a replaced module in storage. | Defendant's product creates a "transparent model database for hierarchical CDC analysis" which, on information and belief, is an updated model of the IC comprising the abstraction models. | ¶109 | col. 2:9-10 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether Defendant’s "meta-database" (Compl. ¶106) legally constitutes the "abstraction module" as contemplated by the patent. The analysis will also raise the question of whether the accused product's capability for both "bottom-up or top-down CDC analysis" (Compl. ¶105) falls within the scope of the "bottom-up fashion" limitation.
- Technical Questions: The complaint alleges that the accused product "creates an updated model of the IC that comprises the abstraction models" (Compl. ¶110). A point of contention may be the nature of this "updated model" and whether it is distinct from the "meta-database" itself, as required by the claim's final "storing" step.
U.S. Patent No. 9,792,394 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| ...a method for detecting design problems in a circuit design... | Defendant's Meridian CDC and SafeConnect products are used in a "Glitch Sign-Off Flow," which is described as a method for detecting design problems. A slide from a Real Intent presentation depicts this flow (Compl. p. 47). | ¶132 | col. 1:8-10 |
| analyzing a higher-level abstraction...to identify...a set of glitch-blocking circuits, and...an enable signal...and...a blocking value... | The accused products analyze higher-level abstractions ("Block" or RTL level) to identify glitch-blocking circuits, such as by verifying that "downstream logic is robust against metastability." | ¶134 | col. 1:67-2:2 |
| analyzing a lower-level abstraction...to identify a possible glitch in a first signal... | The accused products perform "glitch" detection at the "Gate-Level Netlist" (the lower-level abstraction) to ensure no glitch is introduced during synthesis. A presentation slide shows analysis at both RTL and "NETLIST" levels (Compl. p. 50). | ¶134; ¶139 | col. 6:44-50 |
| identifying a first enable signal in the lower-level abstraction...that corresponds to a glitch-blocking circuit... | The accused products identify corresponding circuitry between the higher-level (RTL) and lower-level (NETLIST) to perform glitch detection. | ¶140 | col. 6:51-54 |
| detecting a design problem...in response to determining that the possible glitch...is not blocked when the first enable signal is assigned a first blocking value... | The accused products enable "glitch propagation" analysis as part of "CDC sign-off," which includes detecting design problems where glitches are not properly blocked. | ¶141 | col. 6:63-7:2 |
- Identified Points of Contention:
- Scope Questions: The infringement theory relies on mapping the accused products' general glitch detection features onto a specific, multi-part method. A key question will be whether analyzing an RTL design for "downstream logic [that] is robust against metastability" (Compl. ¶134) constitutes the claimed step of identifying a "glitch-blocking circuit," its specific "enable signal," and its "blocking value."
- Technical Questions: The final claim step requires "detecting a design problem in response to determining that the possible glitch... is not blocked." A factual dispute may arise over whether the accused tools perform this specific two-part logical sequence, or if they simply report all potential glitches at the netlist level without the preceding high-level analysis of what should have been blocked.
V. Key Claim Terms for Construction
’173 Patent
- The Term: "abstraction module"
- Context and Importance: This term is central to infringement, as the Plaintiff’s theory maps it to the Defendant’s "meta-database" (Compl. ¶106). The definition of this term will determine whether a database of stored CDC information qualifies as the claimed "module" that "replaces" the original, more complex module in the design hierarchy.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent specification may describe the "abstraction module" in functional terms as a model that "correctly identifies a corresponding clock-domain for each of the input and the output" ('173 Patent, col. 2:3-5), potentially supporting a view that any data structure performing this function, regardless of its specific format, could qualify.
- Evidence for a Narrower Interpretation: The detailed description may provide specific examples of the abstraction module as a simplified, stand-in circuit model with defined ports and constraints ('173 Patent, col. 5:65-6:67), potentially supporting a narrower construction that a "meta-database" of stored data does not meet.
’394 Patent
- The Term: "detecting a design problem... in response to determining that the possible glitch... is not blocked"
- Context and Importance: This phrase captures the core logic of the asserted method claim. The infringement question will turn on whether the accused tool's process for reporting glitches follows this specific cause-and-effect sequence, or if it performs a more generalized analysis that does not strictly meet this "in response to" limitation.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent may describe the overall goal as simply providing a more accurate glitch report ('394 Patent, abstract). This could support an interpretation where any process that uses both high-level and low-level information to filter or report glitches meets the claim.
- Evidence for a Narrower Interpretation: The claim language recites a specific sequence: a "determination" that a glitch is not blocked, followed by the "detecting" of a design problem "in response to" that determination. This suggests a causal link that may require the tool to first perform the check (is it blocked when it should be?) and only then, as a result, flag the problem, a sequence that a general glitch report might not satisfy ('394 Patent, col. 6:63-7:2).
VI. Other Allegations
- Indirect Infringement: The complaint alleges that Defendant induces infringement of all asserted patents by its customers (e.g., Compl. ¶121; Compl. ¶152). The allegations state that Defendant provides its Accused Products with knowledge and intent that customers will use them to perform the patented methods, supported by advertising, online help documentation, and the work of application engineers who instruct customers on how to use the tools Compl. ¶120 Compl. ¶121
- Willful Infringement: The complaint makes detailed allegations of willful infringement for all asserted patents (e.g., Compl. ¶¶123-126; Compl. ¶¶154-157). The basis for pre-suit knowledge includes: (1) Defendant allegedly citing the '513 patent in its own patent application in 2016; (2) patent examiners citing the '394 and '773 patents against Defendant's applications in 2020 Compl. ¶22; (3) Defendant's alleged general search of Plaintiff's patents "around 2018" Compl. ¶24; and (4) explicit knowledge from the filing of a prior lawsuit in Texas on March 27, 2025, which involved six of the nine patents-in-suit Compl. ¶23 The complaint also alleges willful blindness, arguing that Defendant was aware of Plaintiff's significant patent portfolio in the static verification space and deliberately avoided learning the details Compl. ¶122
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue across all nine asserted patents will be one of technical mapping: does the functionality of Defendant's EDA tools, as described in its marketing materials and user documentation, perform the specific, often multi-step, methods recited in the patent claims? The case will likely involve a granular, feature-by-feature comparison between the accused products and the claim language, focusing on whether general-purpose verification functions embody the particular sequences and structures claimed by the patents.
- A key evidentiary question will concern willfulness and damages: Plaintiff has alleged multiple, specific instances of pre-suit knowledge, including Defendant’s own patent prosecution history and a prior lawsuit. The court will examine the timing and extent of Defendant's awareness of each patent-in-suit to determine if any continued alleged infringement rises to the level of egregious conduct that might warrant enhanced damages.
- The dispute may also be shaped by claim construction, particularly for functional terms that define the patented processes. The construction of terms like "abstraction module" ('173 Patent) and the precise logical sequence required by "detecting... in response to determining" ('394 Patent) will be critical in defining the scope of the claims and could prove dispositive for the infringement analysis.
Analysis metadata