DCT

7:25-cv-00311

Netlens Tech Inc v. Microsoft Corp

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 7:25-cv-311, W.D. Tex., 10/15/2025
  • Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas based on Defendant’s regular and established places of business, including permanent offices in Austin and San Antonio, and extensive Azure datacenter facilities in the Greater San Antonio area that anchor the Azure South Central US region and allegedly host the infringing technologies.
  • Core Dispute: Plaintiff alleges that Defendant’s Azure cloud computing platform infringes four patents related to virtualization management, network quality of service, dynamic network monitoring, and declarative service orchestration.
  • Technical Context: The dispute centers on foundational technologies for managing large-scale, multi-tenant cloud environments, a critical component of the modern digital infrastructure market.
  • Key Procedural History: The filing is a First Amended Complaint. The complaint alleges that Defendant has had knowledge of at least U.S. Patent No. 8,910,154 since the filing of the original complaint, which may form the basis for allegations of willful infringement.

Case Timeline

Date Event
2010-12-23 ’154 Patent Priority Date
2013-01-11 ’901 Patent Priority Date
2014-06-30 ’745 Patent Priority Date
2014-12-09 U.S. Patent No. 8,910,154 Issues
2015-04-03 ’630 Patent Priority Date
2016-08-16 U.S. Patent No. 9,417,901 Issues
2017-07-11 U.S. Patent No. 9,705,745 Issues
2018-08-28 U.S. Patent No. 10,063,630 Issues
2018-09-01 Approximate date of Azure outage in San Antonio datacenter cited in complaint
2025-10-15 First Amended Complaint Filed

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

U.S. Patent No. 8,910,154 - "Obtaining Diagnostic Information in a Virtual Environment"

The Invention Explained

  • Problem Addressed: The patent’s background section describes the problem of managing virtual machine instances as opaque "black boxes," which prevents system owners from understanding the internal state or performance of the applications running inside them (Compl. ¶20; ’154 Patent, col. 1:40-49). This makes detailed diagnostics difficult or impossible (Compl. ¶20).
  • The Patented Solution: The invention proposes a system where a dedicated "service manager module" is associated with each virtual instance. This module acts as an interface between the virtualization software and the guest software running inside the instance, enabling "application-aware white-box testing" to verify and validate the instance's operation from an internal perspective (’154 Patent, Abstract; col. 4:35-44; Compl. ¶33). This architecture provides a unified control interface for sending diagnostic requests and reset commands to individual instances (’154 Patent, col. 5:1-7).
  • Technical Importance: This approach provided a mechanism for more granular and insightful management of large-scale virtualized environments, moving beyond simple system-level monitoring. (Compl. ¶24).

Key Claims at a Glance

  • The complaint asserts at least independent claim 1. (Compl. ¶39).
  • Essential elements of independent claim 1 include:
    • Providing a server with a virtualization system running virtual instances and a plurality of service managers, with each service manager associated with a single virtual instance.
    • Sending a request for diagnostic information through a control interface to the service managers.
    • Communicating the request from the service managers to the virtual instances.
    • Sending the diagnostic information from the virtual instances back to their corresponding service managers.
    • Communicating the diagnostic information from the service managers through the control interface to a user interface.
    • Sending and communicating a reset command to the selected virtual instances via the service managers.
  • The complaint reserves the right to identify additional claim mappings. (Compl. ¶39).

U.S. Patent No. 9,417,901 - "Switch and Method for Guaranteeing QoS of Multi-Tenant Cloud Service"

The Invention Explained

  • Problem Addressed: In shared, multi-tenant cloud environments, there is a need for a solution that can guarantee Quality of Service (QoS) for the many network flows generated by different tenants, ensuring that one tenant's workload does not starve another's of resources. (Compl. ¶21, ¶45; ’901 Patent, col. 1:40-49).
  • The Patented Solution: The patent discloses a "dynamic virtual flow switch" that includes a "switch flow agent" and a "flow processing unit." The agent receives and stores QoS information for both entire virtual machines and for individual network flows. The processing unit then uses this stored information to determine a QoS priority for each flow it receives, allowing it to enforce fairness and performance guarantees at a granular level. (’901 Patent, Abstract; col. 2:1-8).
  • Technical Importance: The invention describes a system for per-tenant and per-flow QoS enforcement, a critical capability for providing reliable service level agreements in modern cloud infrastructure. (Compl. ¶24).

Key Claims at a Glance

  • The complaint asserts at least one claim of the ’901 Patent. (Compl. ¶51). Independent claim 1 is representative.
  • Essential elements of independent claim 1 include:
    • A dynamic virtual flow switch comprising a switch flow agent and a flow processing unit.
    • The switch flow agent receives and stores both virtual machine QoS information and flow-specific QoS information from a virtual flow controller.
    • The flow processing unit receives a flow and determines its QoS priority based on both the stored virtual machine QoS information and the stored flow QoS information.
    • The system includes a plurality of such dynamic virtual flow switches connected over a network.
  • The complaint reserves the right to identify additional claim mappings. (Compl. ¶51).

U.S. Patent No. 9,705,745 - "System and Method for Virtualizing SDN-Based Network Monitoring"

  • Patent Identification: U.S. Patent No. 9,705,745, "System and Method for Virtualizing SDN-Based Network Monitoring," issued July 11, 2017. (Compl. ¶55).
  • Technology Synopsis: The patent addresses the technical challenge of monitoring high-volume network traffic in Software-Defined Networks (SDNs) without exhausting system capacity. (Compl. ¶57). The proposed solution is a system for dynamically creating "virtual monitors," including both basic and user-defined types, which are instantiated on-demand using allocated computing resources to provide scalable monitoring. (Compl. ¶57, ¶60).
  • Asserted Claims: The complaint asserts at least one claim. (Compl. ¶63).
  • Accused Features: The complaint accuses Azure Packet Monitor (PktMon), Istio service mesh, Envoy proxies, Prometheus, and Container Insights of infringing by functioning as the claimed basic and user-defined virtual monitors. (Compl. ¶58, ¶60).

U.S. Patent No. 10,063,630 - "System and Method for Service Orchestration in Distributed Cloud Environment"

  • Patent Identification: U.S. Patent No. 10,063,630, "System and Method for Service Orchestration in Distributed Cloud Environment," issued August 28, 2018. (Compl. ¶67).
  • Technology Synopsis: The patent addresses the need for a reliable and declarative method for orchestrating services across complex, distributed cloud environments, to overcome the error-prone nature of manual configuration. (Compl. ¶22, ¶69). The invention describes an orchestration system that receives a high-level "service profile," analyzes it to generate a detailed "service specification," sets a "service flow" based on the specification, and transmits execution commands to distributed cloud resources. (Compl. ¶69; ’630 Patent, Abstract).
  • Asserted Claims: The complaint asserts at least one claim. (Compl. ¶75).
  • Accused Features: The complaint accuses Azure Service Fabric, Azure Resource Manager, and the Kubernetes orchestration system (using YAML manifests, the API Server, and Ingress controllers) of infringing by implementing this declarative orchestration model. (Compl. ¶70, ¶72).

III. The Accused Instrumentality

Product Identification

  • Microsoft's Azure cloud platform, including both its "legacy" architecture (e.g., Hyper-V, System Center Virtual Machine Manager ("SCVMM"), Service Fabric, Azure Monitor) and its "more recent" Kubernetes-based architecture (e.g., Azure Kubernetes Service ("AKS"), Istio, Envoy, Prometheus). (Compl. ¶4).

Functionality and Market Context

  • The complaint describes the accused instrumentality as a comprehensive cloud computing platform that provides infrastructure for deploying and managing virtualized and containerized applications. (Compl. ¶4-5). Key accused functionalities include the deployment of monitoring agents (Azure Monitor Agent, kubelets) within virtual instances for data collection and control; a software-defined networking (SDN) fabric with a Virtual Filtering Platform (VFP) for enforcing network policies like QoS; dynamic monitoring through tools such as Packet Monitor and Prometheus; and declarative service orchestration via manifests in Service Fabric and Kubernetes. (Compl. ¶26-27). The complaint positions these technologies as "foundational" and integral to the operation of the Azure platform. (Compl. ¶1, ¶28).

IV. Analysis of Infringement Allegations

No probative visual evidence provided in complaint.

The complaint states that exemplary claim charts are attached as exhibits (e.g., Exhibits 2A, 4A); however, these exhibits were not provided with the complaint document. Accordingly, the narrative infringement theories are summarized below.

’154 Patent Infringement Allegations

  • Narrative Summary: The complaint alleges that Microsoft's Azure platform meets the limitations of the ’154 Patent’s claims for application-aware diagnostics. (Compl. ¶33, ¶35). The theory posits that in-instance components like the Azure Monitor Agent (in legacy VMs) or the kubelet (on Kubernetes nodes) function as the claimed "service managers" associated with individual virtual instances. (Compl. ¶26-27). A centralized management plane, such as Azure Monitor or the Kubernetes API server, allegedly acts as the "control interface" to send diagnostic requests and "reset commands" (allegedly performed by mechanisms like the Horizontal Pod Autoscaler) to these managers, which in turn communicate with the guest software and return diagnostic data to the management plane. (Compl. ¶27, ¶35).

’901 Patent Infringement Allegations

  • Narrative Summary: Plaintiff's infringement theory for the ’901 Patent targets Azure's networking stack. (Compl. ¶47-48). It alleges that Azure’s software-defined network fabric, including the Hyper-V Virtual Filtering Platform (VFP) and the Azure Network Controller, collectively function as the claimed "dynamic virtual flow switch." (Compl. ¶26, ¶46). These components are accused of storing and enforcing QoS policies on both a per-VM (tenant) and per-flow basis. (Compl. ¶48). The Azure Network Controller is alleged to be the "virtual flow controller" that provides QoS information to the enforcement points (the "switch flow agent," allegedly part of the VFP), which then prioritize traffic (performing the role of the "flow processing unit"). (Compl. ¶26, ¶48).

Identified Points of Contention

  • Scope Questions: A potential point of contention for the ’154 Patent may be whether a modern container orchestration agent like a "kubelet" and a scaling mechanism like a "Horizontal Pod Autoscaler" fall within the scope of a "service manager" and "reset command" as described in a patent focused on traditional virtual machine environments. For the ’901 Patent, a question may arise as to whether Microsoft's distributed SDN fabric, composed of a central controller and numerous VFP instances on host servers, constitutes a "dynamic virtual flow switch" as claimed, or represents a different architecture.
  • Technical Questions: The infringement analysis may raise the question of what evidence demonstrates that Azure's general health monitoring and resource scaling functions perform the specific "application-aware white-box testing" required by the ’154 Patent’s claims. (Compl. ¶33). Similarly, for the ’901 Patent, a key question may be whether the Azure VFP performs the specific multi-step bandwidth comparison logic recited in the patent’s independent claims or uses a different technical method for QoS enforcement.

V. Key Claim Terms for Construction

"service manager" (’154 Patent)

  • Context and Importance: This term is central to the infringement theory for the ’154 Patent, as the complaint maps it to modern components like the Azure Monitor Agent and the Kubernetes kubelet. (Compl. ¶26-27). The construction of this term will determine whether these general-purpose agents can be considered the specific structure claimed in the patent.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes the manager’s function broadly as providing "a process for interfacing the virtual instances... to a management station." (’154 Patent, col. 4:57-59).
    • Evidence for a Narrower Interpretation: The patent depicts the associated "instance interface" with a specific three-part structure comprising "a metadata division, a test division, and a data division," which could support a narrower construction limited to agents with this explicit architecture. (’154 Patent, FIG. 3; col. 5:11-13).

"dynamic virtual flow switch" (’901 Patent)

  • Context and Importance: This term defines the core infringing instrumentality for the ’901 Patent. Plaintiff maps this term to components of Azure's distributed SDN fabric. (Compl. ¶46-48). Practitioners may focus on this term because the viability of the infringement case depends on whether a distributed architecture can read on the claimed "switch."
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The patent defines the switch by its functional components: a "switch flow agent" to store QoS data and a "flow processing unit" to determine priority, which could be interpreted as logical functions that may be physically distributed. (’901 Patent, Abstract).
    • Evidence for a Narrower Interpretation: Claim 1 requires that the "dynamic virtual flow switch is plural in number" and that these plural switches are "connected over an intranet or the Internet," suggesting a system composed of multiple distinct switch entities rather than a single, integrated fabric. (’901 Patent, Claim 1).

VI. Other Allegations

  • Indirect Infringement: The complaint alleges inducement to infringe all four asserted patents. The basis for this allegation is that Microsoft provides customers with technical documentation, tutorials, default configurations, and marketing materials that allegedly instruct and encourage users to configure and operate the Azure platform in an infringing manner. (Compl. ¶35, ¶49, ¶61, ¶73). Specific examples cited include instructions for deploying the Istio service mesh, configuring QoS in Azure Virtual Networks, and using Service Fabric manifests. (Compl. ¶79).
  • Willful Infringement: The complaint alleges willful infringement of at least the ’154 Patent based on Microsoft's alleged knowledge of the patent since "at least service of the original Complaint." (Compl. ¶78).

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

  • Architectural Equivalence: A core issue will be one of architectural mapping: can the highly distributed, software-defined components of Microsoft's modern cloud platform (e.g., kubelets, a central network controller, VFP instances) be construed to meet the limitations of the more discretely defined functional blocks (e.g., "service manager," "dynamic virtual flow switch") described in patents filed during an earlier phase of virtualization technology?
  • Functional Specificity: A key evidentiary question will be one of functional operation: does the accused Azure functionality perform the specific technical operations required by the claims? For instance, does Azure's QoS system implement the precise multi-step bandwidth comparison logic claimed in the ’901 patent, and do Azure's diagnostic tools perform "application-aware white-box testing" as taught by the ’154 patent, or is there a fundamental mismatch in technical methods?
  • Definitional Scope: The case may turn on the construction of key terms. For the ’630 patent, a central question will likely be whether a standard Kubernetes YAML manifest submitted by a user constitutes the claimed "service profile" that is subsequently analyzed to generate a distinct "service specification," or if this represents a different, more integrated process of declarative configuration that does not map to the patent's specific multi-step orchestration model.