DCT
1:20-cv-00131
Exafer Ltd v. Microsoft Corporation
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Exafer Ltd. (Israel)
- Defendant: Microsoft Corporation (Washington)
- Plaintiff’s Counsel: The Mort Law Firm, PLLC; Goldberg Segalla LLP
- Case Identification: 1:20-cv-00131, W.D. Tex., 09/08/2020
- Venue Allegations: Plaintiff alleges venue is proper because Microsoft has committed acts of infringement in the district and maintains a regular and established place of business, including corporate sales offices, retail stores, and multiple datacenters that house and operate its accused Azure cloud infrastructure.
- Core Dispute: Plaintiff alleges that Defendant’s Microsoft Azure cloud computing platform infringes patents related to Software-Defined Networking (SDN), specifically methods for dynamically managing and optimizing network data flows.
- Technical Context: The patents relate to foundational concepts in Software-Defined Networking, a paradigm that separates the network's control plane from the data plane to allow for more flexible and programmable network management, a critical technology for large-scale cloud services.
- Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patents-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 2009-07-02 | U.S. Patent No. 8,971,335 Priority Date |
| 2009-09-09 | U.S. Patent No. 8,325,733 Priority Date |
| 2012-12-04 | U.S. Patent No. 8,325,733 Issued |
| 2015-03-03 | U.S. Patent No. 8,971,335 Issued |
| 2017-11-09 | Report of Microsoft purchasing Chevron datacenter in San Antonio |
| 2020-09-08 | Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,325,733 - "Method and System For Layer 2 Manipulator and Forwarder"
The Invention Explained
- Problem Addressed: The patent’s background section describes a lack of networking systems that can control and manipulate data forwarding rules for individual data flows or sessions at the switch level. It notes that existing methods like Deep Packet Inspection (DPI) are computationally intensive, expensive, and slow, and that smart switches lack mechanisms for receiving dynamic, per-flow control information from a remote entity (’733 Patent, col. 2:34-59).
- The Patented Solution: The invention proposes a system architecture featuring a “Layer 2 Forwarder and Manipulator” (L2FM) that operates on the data path and a separate, external “Remote admission and information controller” (RAIC) that operates on the control path. When the L2FM identifies a new data flow, its dedicated “flow manager” obtains forwarding instructions from the RAIC. Based on these instructions, the L2FM can manipulate headers of the data frames (e.g., re-writing MAC or IP addresses) and forward them along an optimized path, decoupling data-plane forwarding from control-plane decisions (’733 Patent, Abstract; Fig. 1).
- Technical Importance: This architecture embodies a key principle of Software-Defined Networking by separating the network’s control and data planes, allowing for more granular, programmable, and efficient management of network traffic (Compl. ¶64).
Key Claims at a Glance
- The complaint asserts at least independent claim 26 (Compl. ¶137).
- Claim 26 is a method for forwarding frames via an L2FM, comprising the essential elements:
- identifying, at the L2FM, one or more first frames of a new flow;
- obtaining forward control information for the new flow, where this is done "out of band" and the information includes instructions for "re-writing of at least one field in an original header";
- changing the at least one field in an original header according to the obtained information;
- forwarding the frames according to the obtained information; and
- wherein the control information is obtained from a "remote-admission-and-information controller (RAIC)."
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
U.S. Patent No. 8,971,335 - "System and Method for Creating a Transitive Optimized Flow Path"
The Invention Explained
- Problem Addressed: The patent’s background section explains that conventional networks often create optimized paths by encapsulating data flows and adding new headers (e.g., tunneling), which increases overhead, consumes more bandwidth, and adds complexity. This approach often requires specialized "edge devices" to perform the encapsulation and de-encapsulation (’335 Patent, col. 3:22-54).
- The Patented Solution: The invention proposes a method to optimize traffic paths by creating a “collective virtual network” (CVN) that logically combines disparate underlying networks (e.g., networks operating at different OSI layers). A central "flow-path optimizer-and-creator" identifies an optimal path for a flow within this CVN. Instead of adding new headers, a “Transmitting Device Set with Promiscuous and Re-writing Capabilities” (TDSPRC) modifies the original data frames to make them compatible with the optimal path, thereby avoiding encapsulation overhead (’335 Patent, Abstract; col. 4:1-12).
- Technical Importance: This approach allows for creating optimized, transitive data paths across different network types without the performance penalty of traditional tunneling, a valuable capability in heterogeneous cloud networking environments (Compl. ¶112).
Key Claims at a Glance
- The complaint asserts at least independent claim 26 (Compl. ¶160).
- Claim 26 is a method to optimize information delivery between two nodes, comprising the essential elements:
- utilizing a "Transmitting Device Set with Promiscuous and Re-writing Capabilities (TDSPRC)";
- collecting topology information related to three or more different OSI model layers;
- identifying alternate paths based on the collected information;
- creating a "collective virtual network (CVN)" that includes known and alternate paths, and identifying an optimal path within the CVN; and
- modifying the data frames of a flow to be compatible with the optimal path, where the modification is done by the TDSPRC, and the "TDSPRC is not a member in at least one of the networks."
- The complaint does not explicitly reserve the right to assert dependent claims for this patent.
III. The Accused Instrumentality
Product Identification
The Microsoft Azure Platform, which includes the Azure cloud computing platform, its associated hardware and software systems, and cloud-based services that leverage the platform (Compl. ¶10). The complaint specifically identifies Azure Smart Network Interface Cards (SmartNICs) and the Virtual Filtering Platform (VFP) software as key components (Compl. ¶¶140, 142).
Functionality and Market Context
The complaint describes Azure as a large-scale cloud platform that utilizes Software-Defined Networking (SDN) to manage network traffic efficiently. A diagram from a Microsoft presentation illustrates the "SmartNIC Design," which uses an FPGA (Field-Programmable Gate Array) for reconfigurable networking functions (Compl. ¶140). The VFP software component is alleged to identify new network traffic flows by parsing packet headers to create a "Unified FlowID" (Compl. ¶142). This system separates the control plane (managed by "controllers") from the data plane (executed on SmartNICs and virtual switches), allowing policies to be applied on a per-flow basis to millions of virtual machines (Compl. ¶144). A diagram from an Azure presentation shows this separation of "management, control, and data planes" (Compl. ¶144). The complaint alleges these technologies are central to Azure's ability to offer high-performance, scalable cloud networking (Compl. ¶163).
IV. Analysis of Infringement Allegations
’733 Patent Infringement Allegations
| Claim Element (from Independent Claim 26) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a. identifying, at the L2FM, one or more first frames of a new flow | The Azure Virtual Filtering Platform (VFP) packet processor and SmartNIC identify new flows by parsing packet headers to create a "Unified FlowID (UFID)" (Compl. ¶142). | ¶142 | col. 6:49-56 |
| b. obtaining forward control information for frames of the new flow... wherein obtaining forward control information is done out of band | Azure servers and SmartNICs obtain forward control information from "controllers" that define and program network policy. The complaint alleges this separation of control and data planes constitutes "out of band" communication (Compl. ¶¶143, 147). | ¶¶143, 147 | col. 8:32-35 |
| ...wherein the forward control information includes re-writing of at least one field in an original header of the frames of the new flow | The control information obtained from Azure controllers allegedly includes instructions for re-writing header fields. The complaint provides a "Header Transposition - Actions" table showing actions like "Pop," "Push," and "Modify" that can be applied to headers (Compl. ¶146). | ¶146 | col. 4:19-24 |
| c. changing the at least one field in an original header of the frames of the new flow according to the obtained forward control information | Azure components, including servers, virtual switches, and SmartNICs, allegedly change header fields according to the control information. The complaint provides an "Example Actions" table showing how fields like Source/Destination MAC or IP can be modified (Compl. ¶148). | ¶148 | col. 4:33-38 |
| d. forwarding the frames of the new flow according to the forward control information | Azure components forward the modified frames according to the forward control information received from the controllers (Compl. ¶149). | ¶149 | col. 4:1-3 |
| wherein at least portion of the control information is obtained from a remote-admission-and-information controller (RAIC) | The complaint alleges that the Azure "controllers" that provide policy and control information function as the claimed "remote-admission-and-information controller (RAIC)" (Compl. ¶150). | ¶150 | col. 3:10-14 |
- Identified Points of Contention:
- Scope Questions: A central question will be whether Microsoft’s SDN "controllers" fall within the scope of the patent's term "remote-admission-and-information controller (RAIC)." The defense may argue that Azure's policy controllers do not perform "admission" control in the specific manner described in the patent (e.g., analogous to a RADIUS server), but rather function as general-purpose policy engines.
- Technical Questions: The analysis may turn on whether the communication between Azure's data plane (VFP/SmartNICs) and its control plane is technically "out of band" as the term is understood in the patent's context.
’335 Patent Infringement Allegations
| Claim Element (from Independent Claim 26) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| collecting topology information related to three or more different Open System Interconnection (OSI) model layers from a plurality of network devices | Azure controllers or the VFP are alleged to collect topology information by parsing L2, L3, and L4 headers, potentially across multiple layers of encapsulation (e.g., outer and inner headers in a tunnel), to identify flows (Compl. ¶167). | ¶167 | col. 9:49-58 |
| identifying alternate paths, based at least in part on the collected topology information... between the first node and the second node | Azure controllers are alleged to identify alternate network paths based on the collected topology information (Compl. ¶168). | ¶168 | col. 10:47-51 |
| creating a collective virtual network (CVN) including the known paths and the alternate paths, for a particular flow, identify an optimal path in the CVN instead of a known path | The complaint alleges Azure creates a plurality of "collective virtual networks," providing as an example a diagram showing traffic between nodes being routed through a "GRE:Green" virtual network based on a forwarding policy, which it contends constitutes identifying an optimal path (Compl. ¶¶169-170, 162). | ¶¶169-170 | col. 10:55-62 |
| modifying the data frames of the particular flow to be compatible with a network technology employed by the identified optimal path, wherein the modification is implemented by the TDSPRC | Azure components (servers, SmartNICs, VFP, virtual switch) are alleged to collectively function as a TDSPRC, modifying data frames via actions like encapsulation to make them compatible with the optimal path determined by the controller (Compl. ¶¶165, 171). | ¶¶165, 171 | col. 11:21-32 |
| ...and the TDSPRC is not a member in at least one of the networks. | The complaint alleges that the Azure components functioning as a TDSPRC are not members in at least one of the networks to which the communicating nodes belong (Compl. ¶172). | ¶172 | col. 11:30-32 |
- Identified Points of Contention:
- Scope Questions: The definition of "collective virtual network (CVN)" will be critical. The defense may argue that Azure's use of standard virtual networking technologies (like GRE tunnels) does not amount to the specific "CVN" structure described in the patent, which is built upon the concept of "Coupled Promiscuity Networks."
- Technical Questions: The infringement claim may depend on factual evidence supporting the limitation that the accused TDSPRC is "not a member in at least one of the networks." The complaint makes this allegation without providing specific architectural facts to substantiate how the Azure VFP or SmartNICs are external to the networks they manage.
V. Key Claim Terms for Construction
The Term: "remote-admission-and-information controller (RAIC)" (’733 Patent, Claim 26)
Context and Importance: This term is the lynchpin of the infringement allegation against the ’733 patent. The case may turn on whether Microsoft’s Azure SDN "controllers" perform the functions of a "RAIC." Practitioners may focus on this term because "admission" control implies a gatekeeping function that may be distinct from the general policy programming function of a standard SDN controller.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states, "Exemplary RAIC can be admission control servers such as but not limited to Radius and other AAA... application control servers such as but not limited to Peer-to-Peer applications, specific video streaming services, Web servers, etc." (’733 Patent, col. 3:11-17). This broad list suggests the term is not limited to traditional authentication servers.
- Evidence for a Narrower Interpretation: The patent’s title ("Layer 2 Manipulator") and many examples focus on specific applications like anonymous P2P file sharing, where the RAIC acts as a tracker that "admits" peers to a session. This could support an argument that the RAIC must perform an application-specific session admission function, not just general network policy distribution.
The Term: "creating a collective virtual network (CVN)" (’335 Patent, Claim 26)
Context and Importance: The novelty of the ’335 patent appears to rest heavily on this concept. Infringement will depend on whether Azure’s architecture "creates" a "CVN." Practitioners may focus on this term because it appears to be a patent-specific neologism whose scope must be defined entirely by the patent's intrinsic evidence.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The abstract describes combining "various kinds of users/computers/devices, working in the same or in different abstraction layer networks, into one collective virtual network" (’335 Patent, Abstract). This could support a broad reading that any logical overlay network qualifies as a CVN.
- Evidence for a Narrower Interpretation: The specification links the CVN to the concept of "Coupled Promiscuity Networks (CPN)," which are defined as two or more networks whose traffic is entirely handled by a common TDSPRC (’335 Patent, col. 4:35-42). This suggests a CVN is not just any virtual network, but one constructed from these specific CPN building blocks.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement for both patents. It asserts that Microsoft encourages its customers to directly infringe by providing user guides, manuals, advertisements, promotional materials, and other instructions on how to use the accused Azure Platform (Compl. ¶¶153, 174).
- Willful Infringement: The complaint does not contain an allegation of pre-suit willfulness. It alleges knowledge of the patents "at least as early as the filing and service of the Complaint" or "since its post-filing knowledge" (Compl. ¶¶151, 153, 173, 174). These allegations may form a basis for seeking enhanced damages for any post-filing infringement but do not assert pre-suit knowledge.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the patent-specific terms from the 2009-era applications, such as "remote-admission-and-information controller (RAIC)" and "collective virtual network (CVN)", be construed to read on the components of Microsoft's modern, large-scale cloud SDN architecture? The dispute will likely center on whether these terms require specific functions (like session "admission") and structures (like "Coupled Promiscuity Networks") that are absent from the accused Azure system.
- A second key issue will be one of technical mapping: beyond claim construction, the case will require a detailed factual analysis of Azure's complex architecture. A primary evidentiary question for the ’733 patent will be whether the communication between Azure's control and data planes meets the "out of band" limitation. For the ’335 patent, a crucial factual question will be whether the accused hardware and software, which are deeply integrated into the host servers, can be considered "not a member" of the networks they are managing, as required by the claim.