DCT
4:18-cv-00100
Akoloutheo LLC v. Apcon Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Akoloutheo, LLC (Texas)
- Defendant: Apcon, Inc. (d.b.a. APCON SOLUTIONS, INC.) (Oregon)
- Plaintiff’s Counsel: Ross IP Group, PLLC
- Case Identification: 4:18-cv-00100, E.D. Tex., 04/10/2018
- Venue Allegations: Venue is alleged to be proper in the Eastern District of Texas because the Plaintiff's principal place of business is within the district and the Defendant operates a "regular and established place of business," a regional center, in Plano, Texas, within the district.
- Core Dispute: Plaintiff alleges that Defendant’s network management software and hardware systems infringe a patent related to generalized and adaptive transaction processing between information services.
- Technical Context: The technology relates to frameworks for managing and integrating disparate information services across a network, a key challenge in enterprise network management and cloud computing.
- Key Procedural History: The operative complaint is a First Amended Complaint, filed as a matter of right. No other significant procedural events are mentioned in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2001-04-19 | '730 Patent Priority Date |
| 2008-09-16 | '730 Patent Issue Date |
| 2018-04-10 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,426,730 - "Method and System for Generalized and Adaptive Transaction Processing Between Uniform Information Services and Applications"
- Patent Identification: U.S. Patent No. 7,426,730, "Method and System for Generalized and Adaptive Transaction Processing Between Uniform Information Services and Applications," issued September 16, 2008.
The Invention Explained
- Problem Addressed: The patent describes the difficulty of integrating disparate online information services, which often requires custom, limited, and inefficient software solutions. It notes that a user cannot easily combine, for example, driving directions from one service with real-time traffic data from another, and that creating a scalable framework to manage such integrations is a significant challenge (’730 Patent, col. 2:5-26; col. 3:4-15).
- The Patented Solution: The invention proposes a system architecture centered on a "Transaction Processing Function" (TPF). This TPF acts as an intermediary that manages transactions between service consumers and various service providers. It uses a "transaction definition" (TD) and a "Uniform Specification Model" (USM) to classify services and resources in a standardized way. This allows the TPF to dynamically discover, select, and integrate services based on a transaction's context (e.g., user location or preferences) without the services needing explicit, pre-programmed knowledge of one another (’730 Patent, Abstract; col. 5:11-39).
- Technical Importance: The technology aims to provide a generalized and scalable framework that simplifies the complex task of integrating and managing service transactions at a large scale, moving beyond fixed, point-to-point integrations (’730 Patent, col. 2:49-56).
Key Claims at a Glance
- The complaint asserts independent claims 1, 15, 29, and 37 (Compl. ¶47).
- Independent Claim 1, a system claim, recites the following essential elements:
- A networked computer system with servers for providing a resource based on a transaction request.
- A "resource transaction processing module."
- A plurality of remotely located "resource providers" coupled to the module via a network.
- A "resource information registry" for storing information about the resources provided by the providers.
- Wherein the module responds to a request by: constructing a "transaction situation context"; dynamically selecting a resource; determining operations to perform; obtaining the selected resource; and processing it to generate a "resultant resource."
- The complaint reserves the right to assert various dependent claims (Compl. ¶47).
III. The Accused Instrumentality
Product Identification
- The accused instrumentality is the "Apcon System," which comprises "Apcon Software" (specifically WebXR and TitanXR Multi-Switch Management Software) and "Apcon Network Resources" (hardware including IntellaFlex XR Blades and Chassis, IntellaStore II, and EdgeSwitch devices) (Compl. ¶¶11, 12, 15).
Functionality and Market Context
- The Apcon System is alleged to provide centralized management and monitoring of network hardware across a distributed environment (Compl. ¶16). The TitanXR software is described as a "single, centralized point of switch management" that allows users to monitor and manipulate network resources through a web browser or mobile application interface (Compl. ¶¶13, 17, 18). The software and hardware are alleged to be designed for "exclusive compatibility and operation" with each other (Compl. ¶13). The complaint includes a diagram illustrating the TitanXR software managing a network comprised of a data center, branch office, and other remote locations. A diagram from the complaint shows the Apcon System architecture, with TitanXR software at the center managing various network locations like a "Big Data Center," "Branch Office," and "Co-Locations" (Compl. p. 6).
IV. Analysis of Infringement Allegations
U.S. Patent No. 7,426,730 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a networked computer system having a plurality of computer servers for providing a resultant resource according to a transaction request | The Apcon System comprises Apcon Software installed on a networked computer system with servers, coupled to a plurality of network resources. | ¶¶32, 35, 38 | col. 10:18-24 |
| a resource transaction processing module | The Apcon Software, including TitanXR and WebXR, allegedly performs transaction processing to provide information, monitoring, or control of network resources. | ¶¶11, 36 | col. 4:48-52 |
| a plurality of resource providers, each resource provider being remotely located ... and communicatively coupled | The "Apcon Network Resources" (e.g., switches, blades, taps) are the alleged resource providers, remotely located across a computer network and coupled to the Apcon Software. | ¶¶12, 38 | col. 4:18-20 |
| a resource information registry for storing information about the resources provided by the plurality of resource providers | The Apcon Software allegedly generates and maintains a listing of all network devices and resources, displaying this information in map or list views. A screenshot shows a "Map and List Views" interface in TitanXR listing network switches (Compl. p. 7). | ¶¶19, 40 | col. 5:5-8 |
| constructs a transaction situation context ... that provides additional information ... for dynamically selecting and processing at least one resource | Apcon Software allegedly generates "context specific data" such as "date, time, event type, IP address of network resource" to provide additional information for processing. A screenshot of an "Alerts" interface shows detailed event information including device, date, and time (Compl. p. 12). | ¶¶25, 43 | col. 4:56-62 |
| dynamically selects at least one resource to process, in conjunction with the transaction situation context | Apcon Software allegedly "determines which Apcon Network Resources may be responsive to the requested transaction" and "dynamically selects at least one Apcon Network Resource to process." | ¶¶22, 44 | col. 7:58-62 |
| determines one or more discrete operations to perform on the at least one selected resource to satisfy the transaction request | Apcon Software allegedly "determines one or more operations to perform on the Apcon Network Resource to obtain a result satisfying the requested transaction" such as retrieving status information. | ¶45 | col. 8:1-4 |
| obtains the at least one selected resource from the resource provider providing that resource | Apcon Software allegedly "obtains the result from the selected Apcon Network Resource." | ¶46 | col. 8:1-4 |
| processes the at least one selected resource ... to generate a resultant resource | Apcon Software allegedly processes the obtained result "to generate a desired output to the Apcon Software user interface." | ¶46 | col. 8:1-4 |
Identified Points of Contention
- Scope Questions: The patent describes a highly abstract framework for integrating any type of "information services" (e.g., GIS, traffic data, web portals) (’730 Patent, col. 10:21-36). The infringement analysis raises the question of whether the specific components of the accused network hardware management system can be read onto these generalized claim terms. For instance, can an "Apcon Network Resource" (a hardware switch) be considered a "resource provider" in the same manner as the patent's exemplary "GIS information" service?
- Technical Questions: Claim 1 requires the system to "construct a transaction situation context" and then "dynamically select" a resource based on that context. The complaint alleges this occurs (Compl. ¶¶43, 44). A central technical question is what evidence will show that the Apcon Software's selection process is truly "dynamic" and based on a constructed "context" as defined by the patent, rather than being a more direct, pre-configured operational logic for querying specific hardware in response to a user command.
V. Key Claim Terms for Construction
The Term: "resource information registry"
- Context and Importance: This term is critical because the patent's architecture relies on a central repository to classify and define available services, enabling the system's dynamic integration capabilities. The infringement case may depend on whether the accused system's listing of network devices (Compl. ¶¶19, 40) meets the definition of a "registry" as contemplated by the patent.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The plain meaning of "registry" suggests any list or record. The patent's specification refers to this element as a "Uniform Specification Repository (USR)" that "provides a means to store and access information" (’730 Patent, col. 5:5-8), which could be argued to encompass any system that stores information about available resources.
- Evidence for a Narrower Interpretation: The specification consistently describes the USR in the context of a "Uniform Specification Model (USM)" using a "standard taxonomic structure" (’730 Patent, Abstract; col. 5:18-22). An argument could be made that a mere list of devices does not meet this requirement for a structured, taxonomic classification model, thus narrowing the term's scope to systems with more formalized classification schemes.
The Term: "transaction situation context"
- Context and Importance: This term is central to the "adaptive" aspect of the invention, as it is the information used to "dynamically" select resources. The dispute may turn on whether the data used by the Apcon system (Compl. ¶25) qualifies as the "context" described in the patent.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification defines "context" broadly as a "quantifiable and describable element of information that is related to the nature of resources" (’730 Patent, col. 4:63-65). This could be interpreted to cover any data point related to a transaction, such as an IP address or timestamp.
- Evidence for a Narrower Interpretation: The patent provides specific examples of context elements like "Personalization Context," "Location," and "Historical Context" that enable sophisticated, situational processing (’730 Patent, FIG. 9; col. 3:23-34). An argument could be made that the term requires more than simple operational data (like an IP address) and implies a richer set of situational information that is actively constructed to adapt the transaction's processing.
VI. Other Allegations
Indirect Infringement
- The complaint contains allegations that may support a claim for induced infringement. It asserts that Apcon "exercises control and/or direction over the performance of every action performed on or by an Apcon System, including those that are initiated by an end user" and that there are "no substantially non-infringing uses for the Apcon Systems" (Compl. ¶¶51, 52).
Willful Infringement
- The complaint seeks enhanced damages for willful infringement, alleging knowledge of the patent "at least as early as the service date of this complaint" (Compl. p. 14, ¶d). This is an allegation of post-suit willfulness.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can the highly generalized terms of the patent, such as "resource provider" and "resource information registry", which are described in the context of a universal framework for disparate "information services" like GIS and traffic data, be construed to read on the specific, concrete components of the accused network hardware management system?
- A key evidentiary question will be one of technical function: does the evidence show that the accused Apcon Software performs a "dynamic" selection of resources based on a constructed "transaction situation context," as required by the patent's adaptive framework, or does it operate with a more direct, pre-configured logic inherent to its purpose as a specialized network management tool?