Akoloutheo LLC v. Oracle Corp

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Akoloutheo, LLC (Texas)
  • Defendant: Oracle America, Inc. (Delaware)
  • Plaintiff’s Counsel: RWBurns & Co., PLLC
• Case Identification: 4:19-cv-00135, E.D. Tex., 02/25/2019
• Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant maintains a regular and established place of business in Frisco, Texas, within the district.
• Core Dispute: Plaintiff alleges that Defendant’s data analytics, cloud, and business intelligence platforms infringe a patent related to a generalized framework for processing transactions between disparate information services.
• Technical Context: The technology addresses methods for abstracting and managing data integration, allowing systems to dynamically combine information from diverse sources to generate unified results, a foundational capability for modern business intelligence and cloud platforms.
• Key Procedural History: The complaint does not mention any prior litigation, inter partes review proceedings, or licensing history related to the patent-in-suit.

Case Timeline

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

Issued September 16, 2008

The Invention Explained

• Problem Addressed: The patent describes the difficulty of integrating information from disparate online sources, such as combining map data with separate real-time traffic data. (U.S. Patent No. 7,426,730, col. 1:60-65). It notes that creating such composite services typically requires custom, inflexible software solutions that are difficult to scale or adapt. (U.S. Patent No. 7,426,730, col. 2:6-18).
• The Patented Solution: The invention proposes a generalized "transaction framework" that acts as an intermediary between information "consumers" and "providers." (’730 Patent, Abstract). This framework uses a central "Transaction Processing Function" (TPF) that interprets a standardized "Transaction Definition" (TD) to dynamically select, configure, and process data from various services. (’730 Patent, col. 5:11-24; Fig. 2). This allows for loose coupling, where the system can adapt to different data sources and user needs without being explicitly pre-programmed for every possible interaction.
• Technical Importance: This architectural approach of abstracting data sources behind a common transaction model aimed to simplify the integration and management of service transactions at a large scale, a key challenge as distributed computing and web services became more prevalent. (’730 Patent, col. 2:51-57).

Key Claims at a Glance

• The complaint asserts independent claims 1, 15, and 17. The analysis below focuses on system claim 1 and method claim 17. The complaint reserves the right to assert additional claims.
• Independent Claim 1 (System):
  • A "resource transaction processing module"
  • A plurality of remotely located and communicatively coupled "resource providers"
  • A "resource information registry" for storing information about the resources
  • Wherein the module, upon receiving a "transaction request", performs steps including:
    • constructing a "transaction situation context"
    • dynamically selecting at least one resource
    • determining discrete operations to perform
    • obtaining and processing the selected resource to generate a "resultant resource"
• Independent Claim 17 (Method):
  • Obtaining a "transaction request"
  • Constructing a "transaction situation context"
  • Analyzing the request and, based on the analysis:
    • "dynamically creating a set of one or more input resources"
    • "determining one or more operations" to be performed
    • "obtaining" the selected input resources
  • "executing" the operations to generate an "output resource"

III. The Accused Instrumentality

Product Identification

The complaint identifies the accused instrumentalities collectively as the "Oracle System." (Compl. ¶15). This system is composed of "Oracle Network Software" (including Oracle Analytics Cloud, Exadata Cloud, Database Cloud, Data Visualization, and Essbase) and "Oracle Network Devices" (including Exadata Database Machine, Database Appliance, and Big Data Appliance). (Compl. ¶¶11-12).

Functionality and Market Context

The complaint alleges the Oracle System functions as a cohesive platform for "managing, analyzing and interrogating networked resources." (Compl. ¶11). The system is depicted as ingesting data from diverse sources (e.g., Oracle, SAP, NetSuite), processing it through a "Data Foundation" layer, and delivering integrated results and visualizations to end-users through interfaces like Oracle Business Intelligence and Oracle Data Visualization. (Compl. ¶14). A diagram in the complaint illustrates this data flow from various "Sources" through "Data Ingestion" and "Data Foundation" to "Data Presentation" tools like "Analytics Cloud." (Compl. p. 4).

IV. Analysis of Infringement Allegations

’730 Patent Infringement Allegations (Claim 1 - System)

’730 Patent Infringement Allegations (Claim 17 - Method)

• Identified Points of Contention:
  • Architectural Questions: A potential issue for litigation is whether the integrated architecture of the accused "Oracle System" maps onto the patent’s model of a distinct "resource transaction processing module" mediating between separate "resource providers" and "consumers". The patent figures consistently depict a decoupled, intermediary component (e.g., TPF 201 in Fig. 2), which may raise questions about the structural correspondence with Oracle’s allegedly more monolithic platform.
  • Technical Questions: The complaint alleges that the Oracle System "dynamically selects" resources. A key question for the court may be what evidence supports that this selection occurs dynamically in response to a user transaction, as the claims may require, versus the system operating on data sources that have been pre-configured by an administrator.

V. Key Claim Terms for Construction

• The Term: "resource transaction processing module" (Claim 1) / "Transaction Processing Function" (TPF) (Specification)

  • Context and Importance: This is the core component of the claimed invention. Its construction will be critical to determining if the accused Oracle System, a large-scale business intelligence platform, contains a structure that meets this limitation. Practitioners may focus on whether this term requires a standalone middleware component or can read on a set of distributed functions within a larger, integrated software suite.
  • Intrinsic Evidence for a Broader Interpretation: The patent defines a TPF broadly as a "software component that manages transactions between one or more information services." (’730 Patent, col. 4:49-52). This language does not explicitly require a specific physical or logical separation from the services it manages.
  • Intrinsic Evidence for a Narrower Interpretation: The patent’s diagrams consistently depict the TPF as a distinct, intermediary block between "RSP" (Resource Service Provider) and "RSC" (Resource Service Consumer) entities, suggesting a specific architectural role rather than a generalized capability. (e.g., ’730 Patent, Fig. 2, element 201; Fig. 5, element 501).

• The Term: "transaction situation context" (Claim 1)

  • Context and Importance: The "adaptive" nature of the invention hinges on this term. The infringement dispute may turn on whether user-selected filters in a BI tool (e.g., "Customer Segment") constitute the specific type of "context" envisioned by the patent for dynamically adapting the transaction process itself.
  • Intrinsic Evidence for a Broader Interpretation: The specification defines "Context" as a "quantifiable and describable element of information that is related to the nature of resources manipulated by RSCs...and RSPs," which could be interpreted broadly to include any parameter that refines a transaction. (’730 Patent, col. 3:62-66).
  • Intrinsic Evidence for a Narrower Interpretation: The patent provides specific examples of context like "Physical Context" (e.g., location), "Personalization Context", and "Temporal Context" (e.g., schedule), suggesting the term may refer to environmental or user-state information rather than simple query filters. (’730 Patent, Fig. 9; col. 18:13-29).

VI. Other Allegations

• Indirect Infringement: The complaint alleges that Oracle infringes indirectly by exercising "exclusive control and direction" over the operation of the accused systems, requiring end-users to operate them in a manner that performs the claimed steps. (Compl. ¶¶27, 29). It further alleges that the systems infringe when used in their intended manner. (Compl. ¶30).
• Willful Infringement: Plaintiff seeks enhanced damages for willful infringement, alleging that Defendant's conduct will be knowing and deliberate "at least as early as the service date of this complaint." (Compl. Prayer for Relief ¶d). This is an allegation of post-filing willfulness.

VII. Analyst’s Conclusion: Key Questions for the Case

• A core issue will be one of architectural equivalence: Does the functionality of Oracle's highly integrated business intelligence platforms correspond to the patent's described architecture of a distinct "resource transaction processing module" that mediates transactions between otherwise separate information providers and consumers?
• Another key issue will be one of definitional scope: Can the claim term "transaction situation context", which the patent illustrates with environmental data like location and user personalization, be construed to cover the user-selected data filters and parameters common to the accused business intelligence software?
• A central evidentiary question will be one of operational proof: What evidence will demonstrate that the accused systems "dynamically select" resources in direct response to a transaction request, as required by the claims, rather than operating on data sources and connections that are pre-configured within the platform's environment?