DCT
6:20-cv-00454
WSOU Investments LLC v. Microsoft Corp
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: WSOU Investments, LLC d/b/a Brazos Licensing and Development (Delaware)
- Defendant: Microsoft Corporation (Washington)
- Plaintiff’s Counsel: Etheridge Law Group, PLLC
- Case Identification: 6:20-cv-00454, W.D. Tex., 04/12/2021
- Venue Allegations: Plaintiff alleges venue is proper because Microsoft maintains regular and established places of business in the district, including corporate offices, retail stores, and data centers, and has committed acts of infringement within the district. The complaint also cites prior cases in the district where venue was deemed proper for Microsoft.
- Core Dispute: Plaintiff alleges that Defendant’s Azure Monitor cloud service infringes a patent related to methods for determining and predicting service trends in communications networks.
- Technical Context: The technology concerns network performance monitoring, a field critical for managing the quality, reliability, and service level agreements (SLAs) of large-scale cloud computing platforms and telecommunications services.
- Key Procedural History: The complaint notes that on March 17, 2021, prior to the filing of this amended complaint, the Court entered a Markman Order construing key terms from the patent-in-suit. The order reportedly adopted a construction for "network parameter" and rejected Microsoft's proposed constructions for "service indicator" and phrases related to parameter measurement, which may influence the infringement analysis.
Case Timeline
| Date | Event |
|---|---|
| 2001-12-03 | Priority Date for U.S. Patent No. 7,366,160 |
| 2008-04-29 | U.S. Patent No. 7,366,160 Issued |
| 2021-03-17 | Court Entered Markman Order Construing Key Claim Terms |
| 2021-04-12 | Plaintiff's First Amended Complaint for Patent Infringement Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,366,160 - "Method of Determining Service Trends"
- Issued: April 29, 2008 (the ’160 Patent)
The Invention Explained
- Problem Addressed: The patent’s background section identifies a lack of tools for accurately forecasting the failure of a network service. It notes that prior art monitoring was based on "a subjective indicator and not on a trend calculation," which prevented the determination of the variation of the indicator over time (’160 Patent, col. 1:13-25).
- The Patented Solution: The invention describes a method to address this problem by first selecting two or more time-variable "network parameters" (e.g., packet loss, bandwidth, jitter). The method then measures these parameters at different times to determine the value of a "service indicator," which is a function of those parameters. Finally, it determines a "trend" of that indicator over time. This trend can then be used to predict when the service quality might cross a defined performance threshold, enabling proactive network management (’160 Patent, Abstract; col. 2:31-45). The patent suggests the trend can be visualized as an "indicator plane" derived from linear regression of parameter values (’160 Patent, col. 4:10-23).
- Technical Importance: This method allows network operators to move from reactive failure response to predictive maintenance, a key capability for providers bound by Service Level Agreements (SLAs) that guarantee a certain level of service quality (’160 Patent, col. 1:19-25).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 of the ’160 Patent (Compl. ¶59).
- The essential elements of independent claim 1 are:
- selecting two or more parameters of a network representative of a network service and variable in time;
- measuring and/or calculating at two or more times values of the network parameters;
- determining at two or more times the value of a service indicator as a function of said measured and/or calculated parameter values;
- determining a trend of the indicator as a function of said determined indicator values, and
- determining as a function of the trend of the indicator a time of the service indicator crossing a defined threshold.
- The complaint’s prayer for relief seeks judgment of infringement on "one or more claims" of the ’160 Patent (Compl. ¶(A)).
III. The Accused Instrumentality
Product Identification
The accused instrumentalities are Microsoft's Azure Monitor services, including its "Azure Monitor for Networks" and "Network Performance Monitor" features (collectively, "Azure Monitor") (Compl. ¶¶31, 35, 38).
Functionality and Market Context
- Azure Monitor is described as a service that provides performance and availability monitoring for applications and services running in Azure, other clouds, or on-premises environments (Compl. ¶¶31, 33).
- It collects data from various sources into a common platform for analysis of trends and anomalies (Compl. ¶33). A screenshot in the complaint depicts the Azure Monitor architecture, showing how data from sources like applications and operating systems flows into "Metrics" and "Logs" for analysis, visualization, and response (Compl. p. 8).
- The service allegedly uses a "Smart Metric Pattern Recognition" feature, which employs machine learning to automatically detect metric patterns, adapt to changes over time, and provide alerts based on deviations from an expected pattern (Compl. ¶37).
- The complaint alleges that Azure Monitor is a central tool for managing the health and performance of resources within Microsoft's significant cloud computing ecosystem (Compl. ¶¶32-33).
IV. Analysis of Infringement Allegations
’160 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| selecting two or more parameters of a network representative of a network service and variable in time | The Network Performance Monitor selects for monitoring network parameters such as bandwidth, packet loss, and latency (Compl. ¶40). The complaint notes the Court's Markman Order construed "network parameter" to include these examples (Compl. ¶25). | ¶40 | col. 3:1-4 |
| measuring and/or calculating at two or more times values of the network parameters | Azure Monitor collects "metrics" (the alleged parameters) at regular intervals, which are identified with a timestamp and a value (Compl. ¶¶36, 43). A provided screenshot shows graphs plotting "Bandwidth Utilization" and "Latency" over time (Compl. p. 16). | ¶¶36, 43 | col. 2:51-53 |
| determining at two or more times the value of a service indicator as a function of said measured and/or calculated parameter values | The complaint alleges that "metrics" and Key Performance Indicators ("KPIs") within Azure Monitor satisfy the "service indicator" term (Compl. ¶¶44, 46). It alleges that a metric like "SuccessE2E Latency" is determined from underlying network parameters (Compl. ¶48). A table of such metrics is provided as evidence (Compl. p. 13). | ¶¶44, 46, 48 | col. 2:37-41 |
| determining a trend of the indicator as a function of said determined indicator values | Azure Monitor determines and displays "Trend charts" for metrics like loss, latency, and throughput (Compl. ¶¶54, 55). An accompanying screenshot shows a metric's trend plotted against dynamic upper and lower thresholds (Compl. p. 17). | ¶¶54, 57 | col. 2:42-45 |
| determining as a function of the trend of the indicator a time of the service indicator crossing a defined threshold | Azure Monitor allegedly provides "near real time alerting" and triggers an "Alarm" when a metric's deviation from a dynamic threshold indicates an anomaly (Compl. ¶¶56, 58). This alert is alleged to be the determination of the time of crossing the threshold. | ¶¶56, 58 | col. 2:46-49 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether an Azure "metric" (e.g., "Average Bandwidth") constitutes a "service indicator" that is determined "as a function of" other "network parameters," as required by the claim. The complaint alleges it is (Compl. ¶48), but the analysis may hinge on whether an aggregated single-type metric is distinct enough from the underlying parameter measurements to satisfy the claim language. The court’s rejection of a "distinctness" requirement in its Markman Order will be significant here (Compl. ¶30).
- Technical Questions: The final claim element requires "determining... a time of the service indicator crossing a defined threshold." The complaint maps this to Azure's real-time "Alert" feature (Compl. ¶¶56, 58). This raises the question of whether a reactive, real-time alert (i.e., determining the time of crossing is "now") meets a limitation that the patent specification repeatedly describes in predictive terms, such as determining a "time remaining up to a threshold crossing" (’160 Patent, col. 4:53-54).
V. Key Claim Terms for Construction
The Term: "service indicator"
Context and Importance: The definition of this term is critical for determining if Azure's "metrics" or "KPIs" meet the claim limitation. The complaint highlights that the court has already addressed this term in its Markman Order, rejecting Microsoft's attempt to require that the "indicator" be "distinct from the network parameters" (Compl. ¶¶29-30). Practitioners may focus on whether a metric derived from a single type of parameter (e.g., "Average Bandwidth" from multiple bandwidth measurements) is an "indicator" that is a "function of" network parameter values.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states, "A level of service indicator can be defined on the basis of measured and/or calculated data" (’160 Patent, col. 2:57-58). This broad language may support the plaintiff's position that aggregated metrics qualify.
- Evidence for a Narrower Interpretation: The patent provides examples where multiple different parameters (e.g., packet loss, time-delay, jitter, bandwidth) are weighted and combined to assess a service, which could suggest the "indicator" is a composite value derived from heterogeneous parameters, not just an aggregation of a single parameter type (’160 Patent, col. 3:20-42).
The Term: "determining as a function of the trend of the indicator a time of the service indicator crossing a defined threshold"
Context and Importance: This term defines the ultimate output of the claimed method and is a likely point of dispute regarding the functionality of Azure's alerting system. The core issue is whether the claim requires a prediction of a future crossing time or if a reaction to a present crossing suffices.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language itself does not explicitly use the word "predict" or "forecast." An argument could be made that determining the time of crossing "is now" upon detection is a valid, literal reading of the claim. The complaint relies on this interpretation by pointing to Azure's "near real time alerting" (Compl. ¶56).
- Evidence for a Narrower Interpretation: The patent specification consistently frames the utility of this step as forecasting. It states the invention can "determine when it will cross the threshold" and "establish a time remaining up to a threshold crossing" (’160 Patent, col. 2:22-23; col. 4:53-54). This language strongly supports an interpretation requiring a predictive calculation of a future time, which may differ from the reactive alerting functionality described in the complaint.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement, stating Microsoft provides and disseminates product descriptions, operating manuals, and instructions that instruct customers on how to configure and use the accused Azure Monitor features in an infringing manner (Compl. ¶62).
- Willful Infringement: Willfulness is alleged based on Microsoft’s knowledge of the ’160 Patent "since at least the date of service of the original Complaint" (Compl. ¶61). The complaint seeks enhanced damages and a finding that the case is exceptional (Compl. ¶¶(D), (E)).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: does an Azure "metric," such as "Average Bandwidth," which is derived from aggregating measurements of a single parameter type, satisfy the claim requirement of a "service indicator" determined "as a function of" network parameter values? The court’s pre-existing Markman ruling on this issue will be a critical factor.
- A key evidentiary question will be one of temporal functionality: does Azure Monitor’s system for issuing real-time "Alerts" when a metric crosses a dynamic threshold perform the function of "determining... a time of the service indicator crossing a defined threshold," or does the patent’s repeated emphasis on forecasting require a predictive calculation of a future crossing time that is absent from the accused product?