DCT

2:26-cv-00524

G98 Networks LLC v. Ericsson Inc

Log In
Key Events
Complaint
complaint Intelligence

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:26-cv-00524, E.D. Tex., 06/30/2026
  • Venue Allegations: Venue is alleged to be proper in the Eastern District of Texas because the Defendant maintains an established place of business in the District.
  • Core Dispute: Plaintiff alleges that Defendant infringes a patent related to an interface device for integrating non-standard networking hardware into a Software-Defined Networking (SDN) environment.
  • Technical Context: The lawsuit concerns Software-Defined Networking, an architecture that separates a network's control functions from its data-forwarding functions, allowing for centralized and more flexible network management.
  • Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.

Case Timeline

Date Event
2016-05-23 '757 Patent Priority Date
2017-05-23 '757 Patent Application Filing Date
2021-08-17 '757 Patent Issue Date
2026-06-30 Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

The Invention Explained

  • Problem Addressed: The patent's background section states that standard SDN protocols, such as OpenFlow, are designed for digital, packet-switched networks and are not applicable to optical or wireless networks where data transport is analogue in nature ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 1:59-col. 2:2). This limitation prevents a wide range of hardware, including modern optical switches, various wireless technologies (like LTE or Bluetooth), and Internet of Things (IoT) gateways, from being integrated into and managed by a unified SDN controller ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 2:20-41).
  • The Patented Solution: The '757](https://ai-lab.exparte.com/patent/11095757) Patent describes an "interface device" that acts as a translation "middlebox" between a standard SDN controller and a non-compliant network device ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 2:41-49). As illustrated in Figure 3, this device comprises three key software modules: (1) a "vendor and technology specific layer" that communicates with the network device using its native protocol; (2) a "device abstraction layer" that generates a standardized "device abstraction model" representing the device's capabilities (e.g., in time, space, and frequency domains); and (3) a "protocol mapping layer" that translates commands between the SDN controller's protocol and the device's native protocol via the abstraction model ('757](https://ai-lab.exparte.com/patent/11095757) Patent, abstract; '757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 2:56-col. 3:6).
  • Technical Importance: The invention purports to extend the centralized control and flexibility of SDN to a broader ecosystem of networking hardware, including legacy and specialized equipment that do not natively support standard SDN protocols ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 2:41-50).

Key Claims at a Glance

  • The complaint does not identify any specific claims asserted, instead referencing "the exemplary claims of the '757 Patent" identified in an unprovided exhibit Compl. ¶11 The analysis below is based on independent claim 1, which is the broadest claim of the patent.
  • Independent Claim 1 requires:
    • An interface device for interfacing between a network device and an SDN controller.
    • A first interface for connecting to the SDN controller.
    • A second interface for connecting to the network device.
    • A "vendor and technology specific layer module" for communicating with the network device in its native protocol.
    • A "device abstraction layer module" for generating a "device abstraction model" that represents the network device's capabilities.
    • A "protocol mapping layer module" for mapping data between the SDN controller and the network device using the device abstraction model.

III. The Accused Instrumentality

Product Identification

The complaint does not name any specific accused products, methods, or services. It refers generally to "Exemplary Defendant Products" that are purportedly identified in "charts incorporated into this Count" via a reference to "Exhibit 2" Compl. ¶11 This exhibit was not filed with the complaint.

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the accused instrumentality's functionality or market context, as all such information is deferred to the unprovided Exhibit 2 Compl. ¶16

IV. Analysis of Infringement Allegations

The complaint alleges that Defendant directly infringes the '757](https://ai-lab.exparte.com/patent/11095757) Patent by "making, using, offering to sell, selling and/or importing" the "Exemplary Defendant Products" Compl. ¶11 However, the complaint provides no specific factual allegations regarding how these products infringe. Instead, it states that "Exhibit 2 includes charts comparing the Exemplary '757 Patent Claims to the Exemplary Defendant Products" Compl. ¶16 As Exhibit 2 was not provided, a detailed infringement analysis is not possible.

No probative visual evidence provided in complaint.

  • Identified Points of Contention:
    • Architectural Equivalence: A central question may be whether the accused products, which are not identified, contain the specific three-layer software architecture required by claim 1 (vendor-specific layer, abstraction layer, and mapping layer). The dispute may focus on whether distinct components within Defendant's systems can be mapped to these claimed modules.
    • Functional Mismatch: The infringement analysis may turn on whether any software component in the accused products performs the function of generating a "device abstraction model" and then using that model to "map" communications, as recited in the claims. A potential defense could be that any translation performed by the accused products occurs through a different technical mechanism that does not align with the claimed process.

V. Key Claim Terms for Construction

  • The Term: "device abstraction model"

  • Context and Importance: This term is central to the invention, defining the intermediate data structure used for translation. The outcome of the infringement analysis may depend on whether any data structure within the accused products falls within the scope of this term. Practitioners may focus on this term because its construction will determine whether the claim covers any generic data representation of a device or is limited to the specific structure disclosed in the patent.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The claim language itself is broad, defining the model simply as "representing capabilities of the network device" ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 9:8-10). This could support an interpretation that covers a wide variety of data structures.
    • Evidence for a Narrower Interpretation: The specification, particularly Figure 4, discloses a detailed embodiment of the model with specific fields such as "Port or Space," "Lambda or Centre Frequency," "Bandwidth," and "Time Slot" ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 6:41-col. 7:16). A party could argue that the term should be limited to a model incorporating such specific types of capability data, as this detailed structure is presented as a key aspect of the invention.

  • The Term: "protocol mapping layer module"

  • Context and Importance: This term recites the active translation engine of the claimed device. Infringement will require showing that an accused product contains a "module" that performs the claimed "mapping" function.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The claim requires the module to "map control and message data... onto the device abstraction model" ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 9:11-14). This could be interpreted to encompass any software component that uses an intermediate data model to facilitate protocol translation.
    • Evidence for a Narrower Interpretation: The specification describes this module as performing a "translation" of messages between the SDN controller's format (e.g., OpenFlow) and the device's native format, explicitly using the "device abstraction model" as the basis for this translation ('757](https://ai-lab.exparte.com/patent/11095757) Patent, col. 7:48-61). A party may argue this requires a direct, two-way mapping process centered on the specifically defined abstraction model, not just any form of protocol conversion.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges induced infringement, stating that Defendant sells the accused products to customers and provides "product literature and website materials" that direct end users to use the products in an infringing manner Compl. ¶14 Compl. ¶15 The complaint references an unprovided exhibit for details on this alleged inducement Compl. ¶14
  • Willful Infringement: The willfulness allegation is based exclusively on post-suit conduct. The complaint asserts that "service of this Complaint... constitutes actual knowledge" and that Defendant's continued alleged infringement thereafter is willful Compl. ¶13 Compl. ¶14 No facts are alleged to support pre-suit knowledge of the patent or infringement.

VII. Analyst's Conclusion: Key Questions for the Case

  • Evidentiary Sufficiency: The complaint's complete reliance on an unprovided exhibit for identifying the accused products and the infringement theory raises a foundational question of evidentiary sufficiency. A primary issue will be whether the Plaintiff can produce evidence to demonstrate that Defendant's unspecified products incorporate the specific three-layer software architecture ("vendor specific layer", "abstraction layer", "mapping layer") required by the asserted claims.

  • Claim Scope and Technical Match: A core legal issue will be the construction of the term "device abstraction model." The case may turn on whether this term is construed broadly to cover any intermediate data representation of a device's capabilities, or narrowly to the specific, multi-field structure disclosed in the patent's specification. The resolution of this definitional scope question will likely dictate whether the functionality of Defendant's products can be shown to match the patent's claims.

Loading Complaint