DCT
2:19-cv-00038
Implicit LLC v. Ca Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Implicit, LLC (Washington)
- Defendant: CA, Inc. (Delaware)
- Plaintiff’s Counsel: The Davis Firm, PC; Hosie Rice LLP
- Case Identification: 2:19-cv-00038, E.D. Tex., 03/19/2019
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant CA, Inc. maintains a regular and established place of business in Plano, Texas.
- Core Dispute: Plaintiff alleges that Defendant’s CA API Gateway product infringes nine U.S. patents related to server request management and dynamic data processing in computer networks.
- Technical Context: The technology at issue concerns methods for intelligently processing and routing data packets by dynamically identifying and applying a sequence of software routines based on packet characteristics.
- Key Procedural History: The filing is a First Amended Complaint. The allegations of willful infringement are predicated on Defendant's alleged knowledge of the patents following the filing of the Original Complaint in this action.
Case Timeline
| Date | Event |
|---|---|
| 1999-12-29 | Earliest Priority Date ('683', '790', '104', '780', '839', '378' Patents) |
| 2001-03-18 | Earliest Priority Date ('779', '740' Patents) |
| 2005-08-06 | Earliest Priority Date ('075' Patent) |
| 2011-11-08 | U.S. Patent No. 8,056,075 Issues |
| 2014-04-08 | U.S. Patent No. 8,694,683 Issues |
| 2014-10-07 | U.S. Patent No. 8,856,779 Issues |
| 2016-02-23 | U.S. Patent No. 9,270,790 Issues |
| 2016-04-26 | U.S. Patent No. 9,325,740 Issues |
| 2017-03-07 | U.S. Patent No. 9,591,104 Issues |
| 2018-07-17 | U.S. Patent No. 10,027,780 Issues |
| 2018-07-24 | U.S. Patent No. 10,033,839 Issues |
| 2019-03-05 | U.S. Patent No. 10,225,378 Issues |
| 2019-03-19 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 10,027,780 - “Method and System for Data Demultiplexing” (issued Jul. 17, 2018)
The Invention Explained
- Problem Addressed: The patent addresses the complexity and inefficiency of processing data streams that must be converted through numerous different formats between a source and a destination (e.g., bitmap to compressed, to encrypted, to TCP, to IP) (’780 Patent, col. 1:29-51). Statically pre-configuring every possible sequence of conversion routines is described as having "very high" overhead, and dynamically identifying the correct sequence of routines can be difficult (’780 Patent, col. 1:65-68, col. 2:6-12).
- The Patented Solution: The invention provides a system that dynamically identifies a correct sequence of "message handlers" (or conversion routines) to transform a data packet from a source format to a target format (’780 Patent, Abstract). This sequence, termed a "path," is then stored so that it can be quickly retrieved and applied to subsequent packets of the same message, avoiding the need to re-identify the sequence for each packet (’780 Patent, col. 2:62-68). Figure 1 illustrates a "DEMUX" component (103) identifying a path for an incoming message, which is then placed on a "QUEUE" (149) for processing by a dedicated "THREAD" (105) (’780 Patent, Fig. 1).
- Technical Importance: This approach allows for a flexible and scalable network processing framework capable of handling diverse and previously unknown data formats without manual pre-configuration for every possible conversion sequence (’780 Patent, col. 2:13-20).
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶ 78).
- Essential elements of Claim 1:
- receiving a packet of a message at a computing device;
- determining a key value for the packet based on one or more headers;
- using the key value to determine if a path was previously created and stored for that key;
- if no path is stored:
- identifying one or more routines for processing the packet, including a TCP routine for converting packets from a TCP format to another format;
- creating a path using the identified routines; and
- processing the packet using the created path.
- The complaint makes a general allegation of infringement without specifying assertion of dependent claims.
U.S. Patent No. 10,033,839 - “Method and System for Data Demultiplexing” (issued Jul. 24, 2018)
The Invention Explained
- Problem Addressed: This patent, from the same family as the ’780 Patent, addresses the same technical problem of efficiently managing data conversions in a complex, multi-format network environment (’839 Patent, col. 1:28-68).
- The Patented Solution: The solution is substantively identical to that of the ’780 Patent, proposing a system that dynamically creates and stores a "path" of software routines to process packets of a message (’839 Patent, Abstract; Fig. 1). The core distinction lies in the claims, which add specific requirements for the created path itself.
- Technical Importance: The technical importance is the same as described for the ’780 Patent.
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶ 84).
- Essential elements of Claim 1:
- receiving a packet of a message at a computing device;
- determining a key value for the packet based on one or more headers;
- using the key value to determine if a path was previously created and stored;
- if no path is stored:
- identifying one or more routines for processing the packet, including a TCP routine;
- creating a path using the identified routines, where the path itself stores state information for at least one routine and specifies an ordering for the routines; and
- processing the packet using the created path.
- The complaint makes a general allegation of infringement without specifying assertion of dependent claims.
U.S. Patent No. 8,056,075 - “Server Request Management” (issued Nov. 8, 2011)
- Technology Synopsis: This patent addresses the management of server requests in a networked environment. The invention appears to relate to an architecture for handling, routing, or transforming incoming client requests before they reach a backend server, potentially improving efficiency and security (Compl. ¶ 9).
- Asserted Claims: At least Claim 1 (Compl. ¶ 42).
- Accused Features: The complaint alleges that the accused product's "reverse-web proxy functionality" infringes the ’075 Patent (Compl. ¶ 45).
U.S. Patent Nos. 8,856,779 and 9,325,740 - both titled “Application Server for Delivering Applets to Client Computing Devices in a Distributed Environment” (issued Oct. 7, 2014 and Apr. 26, 2016)
- Technology Synopsis: These patents describe an application server architecture designed to deliver small applications, or "applets," to client devices. The technology appears to solve problems associated with delivering such applets in a distributed environment, such as by efficiently packaging, verifying, or transforming them to suit different client capabilities or security requirements (Compl. ¶¶ 12, 15).
- Asserted Claims: At least Claim 1 of each patent (Compl. ¶¶ 48, 54).
- Accused Features: The complaint alleges infringement by "Server Accused Components" within the accused product, but does not specify their function beyond this label (Compl. ¶¶ 51, 57).
U.S. Patent Nos. 8,694,683, 9,270,790, 9,591,104, and 10,225,378 - all titled “Method and System for Data Demultiplexing”
- Technology Synopsis: These patents are part of the same family as the lead patents analyzed above. They describe methods for processing data packets by dynamically identifying and applying a sequence of conversion or handling routines. The invention solves the problem of efficiently routing and transforming data streams with various formats in a network by creating and storing processing "paths" based on packet characteristics (Compl. ¶¶ 18, 21, 24, 33).
- Asserted Claims: At least Claim 1 of each patent (Compl. ¶¶ 60, 66, 72, 90).
- Accused Features: Infringement is alleged against "Demux Accused Components" that allegedly "implement flow-based processing and the ability to inspect application data on TCP traffic" (Compl. ¶¶ 63, 69, 75, 93).
III. The Accused Instrumentality
- Product Identification: The CA API Gateway (Compl. ¶ 36).
- Functionality and Market Context: The complaint alleges that the CA API Gateway infringes the asserted patents but provides limited technical detail on the product's operation. For certain patents, it is alleged to incorporate "reverse-web proxy functionality" (Compl. ¶ 45). For the data demultiplexing patents, it is alleged to include "Demux Accused Components" that "implement flow-based processing and the ability to inspect application data on TCP traffic" (Compl. ¶ 63). The complaint makes general allegations that Defendant makes, uses, and sells the accused products in the United States but provides no specific details regarding market context or commercial importance (Compl. ¶ 36).
- Visual Evidence: No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
The complaint does not provide an element-by-element mapping of the accused product's features to the claim limitations. The infringement theory is based on general allegations that the accused CA API Gateway is "covered by" the asserted claims.
’780 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving, at a computing device having a processing circuit, a packet of a message | The CA API Gateway allegedly receives data packets as part of its flow-based processing of TCP traffic. | ¶36, ¶63, ¶78 | col. 3:12-14 |
| determining, by the computing device, a key value for the packet, wherein the key value is determined based on one or more headers in the packet | The CA API Gateway allegedly inspects application data and headers on TCP traffic to determine how to process the packet. | ¶36, ¶63, ¶78 | col. 9:18-24 |
| using, by the computing device, the key value to determine whether the computing device is currently storing a previously created path for the key value | The CA API Gateway allegedly uses information from the packet to determine a processing path for the data flow. | ¶36, ¶63, ¶78 | col. 2:65-68 |
| in response to determining that no path is currently stored for the key value, the computing device: identifying, using the key value, one or more routines... | When a new data flow is received, the CA API Gateway allegedly identifies the appropriate sequence of processing routines. | ¶36, ¶63, ¶78 | col. 2:55-59 |
| ...including a routine that is used to execute a Transmission Control Protocol (TCP) to convert packets having a TCP format into a different format | The CA API Gateway allegedly includes routines for processing TCP traffic and converting or handling data within that traffic. | ¶36, ¶63, ¶78 | col. 1:40-45 |
| creating a path using the identified one or more routines | The CA API Gateway allegedly creates a processing path for the data flow based on the identified routines. | ¶36, ¶63, ¶78 | col. 3:19-21 |
| and processing the packet using the created path. | The CA API Gateway allegedly processes the received packet according to the determined path. | ¶36, ¶63, ¶78 | col. 3:22-30 |
’839 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| [Elements identical to ’780 Claim 1] | [Allegations identical to those for ’780 Patent] | ¶36, ¶63, ¶84 | [Citations as above] |
| creating a path using the identified one or more routines wherein the created path stores state information for at least one of the identified one or more routines... | The allegedly created path within the CA API Gateway stores state information for the data flow, such as session context. | ¶36, ¶63, ¶84 | col. 3:6-9 |
| ...and specifies an ordering in which the identified one or more routines are to be performed to process the packet | The allegedly created path within the CA API Gateway defines the specific sequence in which processing routines are applied to the packet. | ¶36, ¶63, ¶84 | col. 3:1-5 |
| and processing the packet using the created path. | The CA API Gateway allegedly processes the received packet according to the determined and ordered path. | ¶36, ¶63, ¶84 | col. 3:22-30 |
- Identified Points of Contention:
- Evidentiary Questions: The complaint's allegations are conclusory and lack specific facts mapping the CA API Gateway's functionality to the claimed steps. A central point of contention may be whether the accused product actually performs the claimed method of dynamically "identifying" a sequence of routines and "creating a path" as a distinct, stored data structure for reuse, as opposed to simply applying a static, pre-configured set of rules to route or process packets.
- Scope Questions: The patents describe a system for "demultiplexing" and converting data through various formats (e.g., Ethernet, IP, TCP). It may be disputed whether the functions of an "API Gateway," which typically involves application-layer routing, authentication, and policy enforcement for API calls, falls within the scope of the claimed invention.
V. Key Claim Terms for Construction
The Term: "path"
- Context and Importance: This term is the central feature of the claimed invention. The outcome of the case may depend on whether the accused product can be shown to "create a path." The scope of this term—whether it requires a specific, stored data structure as described in the specification or can read on any logical routing decision—will be a critical issue.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claims themselves do not explicitly define "path" as a specific data structure, which may support an argument for a broader functional definition covering any determined processing sequence.
- Evidence for a Narrower Interpretation: The specification consistently describes a "path" as a stored data structure, referring to it as a "sequence of sessions of conversion routines" that is saved "so that the conversion system does not need to search for the session and conversion routine when requested to demultiplex subsequent packets of the same message" (’780 Patent, col. 3:51-58). Figure 5 depicts a "PATH" data structure (501) comprising pointers to a message queue, a stack list, and a path address, suggesting a concrete implementation rather than a purely abstract concept (’780 Patent, Fig. 5).
The Term: "routine"
- Context and Importance: The claims require "identifying...one or more routines." The scope of this term will be important to determine what types of software modules in the accused product can satisfy this limitation. Practitioners may focus on this term because if it is construed narrowly to mean only format-conversion modules, it may not read on other types of processing functions like authentication or policy enforcement common in API gateways.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The term "routine" is a general software term and is not explicitly defined in the patent, which could support a broad interpretation covering any software function that processes a packet.
- Evidence for a Narrower Interpretation: The specification's background and detailed description consistently use "routine" in the context of "conversion routines" for changing data formats (’780 Patent, col. 1:49-54, col. 2:51-59, Abstract). This context may support a narrower construction limited to modules that perform data format transformation.
VI. Other Allegations
- Indirect Infringement: The complaint alleges both induced and contributory infringement for all asserted patents. Inducement is based on allegations that CA provides instructional materials (e.g., manuals, videos) that instruct users to operate the CA API Gateway in an infringing manner (Compl. ¶ 44). Contributory infringement is based on allegations that CA sells the product with "Demux Accused Components" or "Server Accused Components" that are especially made or adapted for practicing the invention and are not staple articles of commerce (Compl. ¶¶ 45, 63).
- Willful Infringement: The complaint alleges willful infringement for all asserted patents. The basis for willfulness is alleged knowledge of the patents obtained "at least by filing and serving the Original Complaint in this action" for eight of the patents, and by serving the First Amended Complaint for the ’378 patent (Compl. ¶¶ 39, 40, 46).
VII. Analyst’s Conclusion: Key Questions for the Case
- A key evidentiary question will be one of functional operation: does the accused CA API Gateway perform the specific claimed steps of dynamically "identifying" a sequence of "routines", "creating a path" as a distinct, stored data structure, and reusing that "path" for subsequent packets, or is there a fundamental mismatch between its technical architecture and the patented method?
- A central legal issue will be one of definitional scope: can the term "path," which is described in the patent specification as a stored sequence of data-format "conversion routines," be construed broadly enough to cover the rule-based policy enforcement and application-layer request routing functions of a modern API gateway?