DCT
2:11-cv-01343
Fortinet Inc v. FireEye Inc
Key Events
Amended Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Fortinet, Inc. (Delaware)
- Defendant: FireEye, Inc. (Delaware)
- Plaintiff’s Counsel: Quinn Emanuel Urquhart & Sullivan, LLP
- Case Identification: 5:13-cv-02496, N.D. Cal., 10/15/2014
- Venue Allegations: Venue is alleged to be proper as Defendant resides in the district and a substantial part of the events giving rise to the claims, including acts of alleged patent infringement, occurred there.
- Core Dispute: Plaintiff alleges that Defendant’s network security products and cloud services infringe six patents related to systems for updating security devices and for classifying network traffic content.
- Technical Context: The dispute involves foundational technologies in the network security market, specifically the methods by which security appliances identify different types of internet traffic and receive threat intelligence updates to protect against malware.
- Key Procedural History: This Second Amended Complaint follows a lawsuit initiated approximately two years prior to its filing. The complaint alleges that Defendant gained knowledge of the patents-in-suit at least by the filing of the First Amended Complaint, a fact relevant to the allegations of willful infringement. The complaint also contains extensive allegations of trade secret misappropriation and employee poaching, framing the patent dispute within a larger context of aggressive corporate competition.
Case Timeline
| Date | Event |
|---|---|
| 2004-03-12 | Earliest Priority Date for ’135, ’483, ’205 Patents |
| 2004-06-18 | Earliest Priority Date for ’543 Patent |
| 2006-02-16 | Earliest Priority Date for ’933, ’974 Patents |
| 2009-08-25 | ’974 Patent Issued |
| 2011-07-12 | ’543 Patent Issued |
| 2011-11-01 | ’483 Patent Issued |
| 2011-11-08 | ’135 Patent Issued |
| 2012-06-19 | ’933 Patent Issued |
| 2012-09-25 | ’205 Patent Issued |
| 2014-10-15 | Second Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,056,135 - "Systems and Methods for Updating Content Detection Devices and Systems," Issued November 8, 2011
The Invention Explained
- Problem Addressed: The patent addresses the vulnerability created when network security devices must manually, or on a fixed schedule, "pull" new threat definitions (e.g., virus signatures) from a central server. This delay between the discovery of a new threat and the distribution of its signature leaves networks exposed (U.S. Patent No. 8,051,483, col. 1:15-67).
- The Patented Solution: The invention describes a "push" update architecture. A central station sends new content detection data to a network of update stations, which in turn transmit the updates to content detection modules (e.g., security appliances) without waiting for a request from those modules. This architecture is designed to distribute critical security updates in substantially real-time, minimizing the window of vulnerability ('135 Patent, Abstract; U.S. Patent No. 8,051,483, col. 2:10-15).
- Technical Importance: This approach significantly reduces latency in threat response across a distributed fleet of security devices, a critical factor in mitigating fast-spreading, zero-day attacks ('135 Patent, col. 9:1-14).
Key Claims at a Glance
- The complaint asserts one or more claims, including independent Claim 1 (Compl. ¶42).
- Claim 1 of the ’135 patent is a method claim directed to:
- Obtaining content detection data.
- Transmitting the content detection data to a content detection module.
- Wherein the transmission is performed "not in response to a request from the content detection module."
- The method also involves a system of a central station and first and second update stations, where the first update station determines if the second has received the data.
- The complaint reserves the right to assert additional claims (Compl. ¶42).
U.S. Patent No. 8,204,933 - "Systems and Methods for Content Type Classification," Issued June 19, 2012
The Invention Explained
- Problem Addressed: Traditional network security systems often classify traffic based on the network port number (e.g., port 80 for web traffic). This method is unreliable for modern applications like peer-to-peer (P2P) file sharing or instant messaging, which can use non-standard or dynamic ports to evade detection (U.S. Patent No. 7,580,974, col. 1:28-48).
- The Patented Solution: The invention discloses a stateful method for classifying traffic by analyzing a sequence of data packets within a communication session. Analysis of a first packet establishes a "potential state of classification" by, for example, ruling out certain content types. Subsequent packets are then analyzed in the context of this state, allowing the system to progressively refine its classification and identify the content type with increasing certainty ('933 Patent, Abstract; ’974 Patent, col. 3:37-55, Fig. 4).
- Technical Importance: This stateful, session-based analysis allows for more accurate and resilient traffic classification than port-based methods, which is necessary for applying appropriate security policies to evasive or complex applications ('974 Patent, col. 5:15-20).
Key Claims at a Glance
- The complaint asserts one or more claims, including independent Claim 1 (Compl. ¶54).
- Claim 1 of the ’933 patent is a method claim directed to:
- Receiving a first packet of a session.
- Determining a potential state of classification for the session that indicates "at least one classification candidate has been ruled out."
- Receiving a second packet of the session.
- Determining a content type for the second packet based at least in part on the previously determined potential state.
- The complaint reserves the right to assert additional claims (Compl. ¶54).
Multi-Patent Capsule: U.S. Patent No. 7,580,974 - "Systems and Methods for Content Type Classification," Issued August 25, 2009
- Technology Synopsis: This patent, related to the ’933 patent, describes a system for identifying the type of content in network traffic by analyzing packets within a session. The system determines a classification state for the session based on an initial packet and uses that state to classify subsequent packets, enabling classification of traffic that does not use standard ports ('974 Patent, Abstract).
- Asserted Claims: One or more claims, including independent Claim 1 (Compl. ¶66).
- Accused Features: The FireEye Malware Protective Systems and VX Engines are alleged to determine content type in a manner that infringes (Compl. ¶¶ 66, 69).
Multi-Patent Capsule: U.S. Patent No. 7,979,543 - "Systems and Methods for Categorizing Network Traffic Content," Issued July 12, 2011
- Technology Synopsis: This patent describes a method for categorizing network traffic by analyzing content using one or more techniques and then categorizing the content based on the results and the associated "probability of accuracy" of those results. This allows for a weighted or confidence-based approach to content categorization ('543 Patent, Abstract).
- Asserted Claims: One or more claims, including independent Claim 1 (Compl. ¶78).
- Accused Features: The FireEye Malware Analysis System and VX Engine are alleged to categorize network traffic content in a manner that infringes (Compl. ¶¶ 78, 81).
Multi-Patent Capsule: U.S. Patent No. 8,051,483 - "Systems and Methods for Updating Content Detection Devices and Systems," Issued November 1, 2011
- Technology Synopsis: This patent, related to the ’135 patent, describes a system for updating content detection modules. A central station transmits detection data (e.g., virus signatures) to update stations, which then "push" the updates to end-user modules without a prior request, thereby reducing update latency ('483 Patent, Abstract).
- Asserted Claims: One or more claims, including independent Claim 1 (Compl. ¶90).
- Accused Features: The FireEye Malware Protection Cloud is alleged to update content detection modules in a manner that infringes (Compl. ¶¶ 90, 93).
Multi-Patent Capsule: U.S. Patent No. 8,276,205 - "Systems and Methods for Updating Content Detection Devices and Systems," Issued September 25, 2012
- Technology Synopsis: This patent is also related to the ’135 and ’483 patents and covers aspects of the "push" update architecture. The system involves a central station, update stations, and content detection modules, designed to distribute threat data without requiring the end module to initiate a request ('205 Patent, Abstract).
- Asserted Claims: One or more claims, including independent Claim 1 (Compl. ¶102).
- Accused Features: The FireEye Malware Protection Cloud is alleged to update content detection modules in a manner that infringes (Compl. ¶¶ 102, 104).
III. The Accused Instrumentality
Product Identification
The complaint identifies three overlapping groups of accused instrumentalities: (1) the "FireEye Malware Protection Cloud instrumentality"; (2) the "FireEye Malware Protective Systems and VX Engines instrumentalities"; and (3) the "FireEye Malware Analysis System and VX Engine instrumentalities" (Compl. ¶¶ 42, 54, 78).
Functionality and Market Context
- The complaint describes the accused instrumentalities as a comprehensive network security platform that can "dynamically generate real-time malware intelligence and share this intelligence through the cloud" to protect against web-based attacks (Compl. ¶¶ 13, 45). The Virtual Execution (VX) Engine is described as a component that can "detect[] advanced attacks exploiting unknown vulnerabilities" and "report out forensic details of the exploit" (Compl. ¶17). These features are alleged to be used for updating content detection modules and determining the type of content being processed (Compl. ¶¶ 13, 17, 45).
- The complaint alleges that FireEye has grown substantially and is a direct competitor to Fortinet, and that this growth is partially a result of the alleged infringement and misappropriation of intellectual property (Compl. ¶¶ 1, 25-26). No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
8,056,135 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method of updating a content detection module by a central station... | The complaint alleges FireEye operates a central cloud infrastructure that provides security updates to its customers' products. | ¶42 | col. 4:5-11 |
| transmitting, from the central station, the content detection data to be pushed to the group of content detection modules via an update station... | FireEye's Malware Protection Cloud allegedly shares real-time malware intelligence through its cloud infrastructure, which functions as the central and update station network. | ¶45 | col. 4:26-34 |
| wherein... the transmitting is performed not in response to a request from the content detection module. | The complaint alleges FireEye's systems update a content detection module in a manner described by the patent, which implies a "push" update mechanism. | ¶45 | col. 2:10-15 |
Identified Points of Contention
- Architectural Questions: A primary point of contention may be whether the FireEye Malware Protection Cloud operates as a "push" system as claimed ("not in response to a request"). The analysis will depend on whether FireEye's central systems initiate the update transmission or if customers' endpoint devices periodically poll the cloud for new intelligence, which could be characterized as a "pull" system.
- Scope Questions: The court may need to determine if FireEye's cloud infrastructure, which serves its customers, maps onto the claimed architecture of a "central station" and multiple "update stations" as recited in the claim.
8,204,933 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving a first packet of a session; | FireEye's systems are alleged to inspect network traffic on a packet-by-packet basis to identify and stop web-based attacks. | ¶58 | col. 3:27-29 |
| determining a potential state of classification for the first packet or for a session with which the first packet is associated, a determined potential classification indicating that at least one classification candidate has been ruled out; | The complaint alleges the FireEye systems determine a type of content as described in the patent, which requires a stateful analysis that eliminates potential content types as a session progresses. | ¶¶ 57, 58 | col. 5:46-56 |
| receiving a second packet of the session; | As part of inspecting session traffic, the accused systems necessarily receive subsequent packets. | ¶58 | col. 3:27-29 |
| determining a content type for the second packet based at least in part on the determined potential state of classification for the first packet of for the session. | The final content type determination is allegedly based on the cumulative, stateful analysis of the session's packets. | ¶¶ 57, 58 | col. 3:49-55 |
Identified Points of Contention
- Technical Questions: The central technical question will be whether the FireEye VX Engine's method for classifying traffic performs the specific logic claimed: establishing a "potential state of classification" and explicitly "ruling out" candidates. The complaint makes a conclusory allegation but does not describe the specific algorithm by which the accused systems are alleged to perform this function.
- Evidentiary Questions: The case may turn on evidence concerning the internal workings of FireEye's classification engine. Fortinet will need to substantiate its allegation that the accused systems do more than just identify content, but do so using the claimed iterative, state-based elimination method.
V. Key Claim Terms for Construction
For the ’135 Patent and related update patents (’483, ’205)
- The Term: "not in response to a request from the content detection module"
- Context and Importance: This phrase is the linchpin of the claimed "push" update model. Its construction will determine whether systems where endpoint devices periodically check for updates ("polling") fall within the claim scope, or if the claims are limited to systems where the central server initiates the entire update communication session unsolicited.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification contrasts the invention with a user having to "request for a download" ('483 Patent, col. 1:40-43). This could support a reading where any automated update not directly initiated by a contemporaneous user action is "not in response to a request."
- Evidence for a Narrower Interpretation: The specification describes the central station "push[ing] the latest security update data" ('483 Patent, col. 9:18-21). This language may support a narrower construction requiring the server, not the client, to initiate the data transfer session.
For the ’933 Patent and related classification patent (’974)
- The Term: "potential state of classification... indicating that at least one classification candidate has been ruled out"
- Context and Importance: This term defines the core logic of the claimed classification method. The infringement analysis will depend on whether this requires an explicit, deterministic process of eliminating possibilities from a defined set, or if it can read on more probabilistic or heuristic classification methods.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the initial state as "unknown" and notes that analysis of a packet may provide an "inconclusive result" ('974 Patent, col. 5:39-44). This could support a view where any step that narrows the range of possibilities, even probabilistically, establishes the claimed "potential state."
- Evidence for a Narrower Interpretation: Figure 4 of the ’974 Patent explicitly shows a state changing from "STATE UNKNOWN (T1, T2, T3)" to "STATE UNKNOWN (T1, T3)" after analyzing a packet, visually demonstrating a candidate (T2) being "ruled out." This provides strong support for a narrower construction requiring a system that maintains and eliminates discrete candidates.
VI. Other Allegations
Indirect Infringement
The complaint alleges inducement of infringement across all asserted patents. The basis for this allegation is that FireEye provides customers with products and encourages their use through "sales, licenses, partnerships, product demonstrations, partner training, customer support, [and] publishing of product information" (e.g., Compl. ¶¶ 44, 56). These actions are alleged to cause customers to operate the accused systems in an infringing manner.
Willful Infringement
The complaint alleges willful infringement based on both pre- and post-suit knowledge. Pre-suit knowledge is alleged based on FireEye's hiring of former Fortinet employees, including a Vice President of Product Management who allegedly had "intimate knowledge of Fortinet's patent portfolio" (e.g., Compl. ¶¶ 43, 55). Post-suit knowledge is alleged based on FireEye's awareness of the patents since at least the filing of the First Amended Complaint, with continued sales thereafter constituting willful conduct (e.g., Compl. ¶¶ 47, 59).
VII. Analyst’s Conclusion: Key Questions for the Case
This dispute will likely focus on the precise technical operation of FireEye's security platform compared to the specific methods claimed in Fortinet's patents. The resolution will depend on the answers to two central questions:
- A core issue will be one of architectural operation: does FireEye's cloud update system function as a "push" architecture ("not in response to a request"), as the update patents require, or is it a "pull" system where client devices initiate the update process, potentially placing it outside the claim scope?
- A second key issue will be one of algorithmic equivalence: does FireEye's traffic classification engine perform the specific, state-based, candidate-elimination process claimed in the classification patents, or does it employ a different, non-infringing algorithm to identify network content?