SAP America Inc v. Corent Technology Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: SAP America, Inc. (Delaware)
  • Defendant: Corent Technology, Inc. (Delaware)
  • Plaintiff's Counsel: Venable LLP
• Case Identification: 8:26-cv-00237, C.D. Cal., 01/30/2026
• Venue Allegations: Venue is asserted in the Central District of California because Defendant Corent Technology, Inc. maintains its principal place of business in Aliso Viejo, California, which is within the district.
• Core Dispute: Plaintiff SAP America, Inc. seeks a declaratory judgment that its cloud platforms and software services do not infringe six patents owned by Defendant Corent Technology, Inc. related to multi-tenant cloud computing, workload partitioning, and usage metering.
• Technical Context: The technology at issue addresses methods for adapting, managing, and monitoring software applications for multi-tenant cloud environments, which is a foundational aspect of modern Software-as-a-Service (SaaS) delivery models.
• Key Procedural History: This declaratory judgment action was filed in response to a December 23, 2025 notice letter from Corent accusing SAP of infringement and demanding a license. The complaint notes that Corent has engaged in a broader licensing campaign, having previously sued Microsoft and Amazon on some of the same patents and representing that Microsoft has taken a license.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 8,326,876 - "Multi-Tenant Agile Database Connector" (Issued Dec. 4, 2012)

The Invention Explained

• Problem Addressed: The patent addresses the challenge of running traditional, single-tenant software applications in a modern, multi-tenant cloud or SaaS environment Compl. ¶¶6, 28 Modifying such applications to make them "tenant-aware"-capable of separating data for different customers (tenants)-typically requires significant and costly software re-engineering '591 Patent, col. 2:32-36
• The Patented Solution: The invention proposes an intermediary software component, an "agile database connector," that sits between the non-tenant-aware application and the database '876 Patent, abstract This connector intercepts generic data access commands, infers which tenant is making the request by querying an external source (e.g., a user login session), and automatically translates the generic command into a tenant-specific command that accesses only that tenant's segregated data '591 Patent, col. 3:42-53
• Technical Importance: This technology offers a method to migrate legacy enterprise applications to more efficient, scalable multi-tenant architectures without altering the original application's source code.

Key Claims at a Glance

The complaint seeks a declaratory judgment of non-infringement of Claim 1 Compl. ¶43 Based on SAP's non-infringement arguments, the essential elements of this independent claim include:

• An interface module logically disposed between a non-tenant aware application and a data repository.
• A "handler" that receives a non-tenant-specific data access command and authorizes whether it should be translated.
• A "translator" that, upon receiving authorization from the handler, translates the non-tenant-specific command into a tenant-specific command.
• The tenant-specific command accesses a subset of data within the data repository associated with the specific tenant.

U.S. Patent No. 9,495,372 - "Multi-Tenant Agile Database Connector" (Issued Nov. 15, 2016)

The Invention Explained

• Problem Addressed: As a related patent to the '876 patent, the '372 patent addresses the same fundamental problem: enabling single-tenant applications to operate in a multi-tenant environment without extensive modification Compl. ¶30
• The Patented Solution: The solution is also an intermediary "agile database connector." The patent further elaborates on the logical positioning and function of the translator and handler components, which work together to infer tenant identity and rewrite database commands to ensure data segregation between tenants '972 Patent, abstract
• Technical Importance: This invention provides a refined architecture for a "plug-in" solution that imparts multi-tenancy capabilities to applications not originally designed for them.

Key Claims at a Glance

The complaint seeks a declaratory judgment of non-infringement of Claim 1 Compl. ¶47 Based on SAP's non-infringement arguments, the essential elements of this independent claim include:

• A "translator" that is logically disposed between the application and a non-tenant aware data repository.
• The translator is configured to translate non-tenant specific data access commands into tenant-specific commands using "inferred unique tenant identifiers."
• A "handler" that is separate from the non-application source and also logically disposed between the application and the data repository.
• The handler is configured to pass the tenant-specific data access commands to the data repository.

U.S. Patent No. 10,824,591 - "Automatic Transformation of Single-Tenant Software Applications to Multi-Tenant SaaS Systems" (Issued Nov. 3, 2020)

• Technology Synopsis: This patent, part of the same family as the '876 and '372 patents, describes a system for automatically transforming single-tenant applications for use in a multi-tenant SaaS model Compl. ¶31 It focuses on a "tenant-aware translator" that serves as an interface between the application and multiple tenant-aware data repositories, thereby enabling multi-tenancy without modifying the application itself '591 Patent, abstract
• Asserted Claims: Claim 1 is at issue Compl. ¶51
• Accused Features: SAP's cloud computing platform and Business Technology Platform are accused of infringement, which SAP denies Compl. ¶51

U.S. Patent No. 10,305,761 - "Multi-Application SaaS Metering Engine" (Issued May 28, 2019)

• Technology Synopsis: This patent discloses a monitoring and metering system for multi-tenant, multi-application SaaS environments Compl. ¶32 The system monitors data streams to identify tenants and the applications they are using, aggregates this usage data, and generates summaries for purposes such as subscription billing '761 Patent, abstract
• Asserted Claims: Claim 1 is at issue Compl. ¶55
• Accused Features: SAP denies that its cloud computing platform and Business Technology Platform infringe, specifically contesting that its services generate a "total activity aggregate of all instances that belong to a same zone" as required by the claims Compl. ¶55

U.S. Patent No. 10,320,893 - "Partitioning and Mapping Workloads for Scalable SaaS Applications on Cloud" (Issued Jun. 11, 2019)

• Technology Synopsis: This patent describes a system for optimizing the deployment of SaaS applications on cloud infrastructure Compl. ¶33 The invention involves scanning an application to identify its constituent workloads, partitioning those workloads into logical groups based on common characteristics, and mapping those partitions to discrete cloud resources '893 Patent, abstract '893 Patent, col. 2:4-8
• Asserted Claims: Claim 1 is at issue Compl. ¶59
• Accused Features: SAP denies that its cloud computing platform and Business Technology Platform provide a system for configuring workloads and assigning partitions to a "discrete cloud resource" as claimed Compl. ¶59

U.S. Patent No. 11,019,136 - "Partitioning and Mapping Workloads for Scalable SaaS Applications on Cloud" (Issued May 25, 2021)

• Technology Synopsis: As a continuation of the '893 patent, this patent covers a related method for deploying applications in the cloud Compl. ¶34 The claimed method includes partitioning workloads, constructing multiple "workload assignment maps" to assign workloads to cloud resources, and ranking those maps based on a set of rules to find an optimal deployment configuration '136 Patent, claim 1
• Asserted Claims: Claim 1 is at issue Compl. ¶63
• Accused Features: SAP denies that its cloud computing platform and Business Technology Platform perform the claimed method steps of constructing and ranking a plurality of workload assignment maps Compl. ¶63

III. The Accused Instrumentality

Product Identification

The complaint broadly identifies the "Accused Products" as SAP's "cloud platforms, software services, and related offerings" Compl. ¶3 More specific instrumentalities identified include SAP's Business Technology Platform (BTP) Billing Service, S/4 HANA Migration Cockpit, BTP - Kyma Runtime, and S/4 HANA on Kubernetes Compl. ¶12

Functionality and Market Context

The accused instrumentalities are components of SAP's enterprise cloud offerings, which enable customers to build, deploy, manage, and operate applications and data Compl. ¶5 The complaint points to SAP's online documentation for descriptions of the functionality of the BTP platform, its billing services, the Kyma runtime for Kubernetes-based applications, and the SAP HANA data platform Compl. ¶¶21-26 The complaint positions SAP as a "global leader in enterprise applications" and suggests Corent's infringement allegations are part of a broader licensing campaign targeting major cloud providers Compl. ¶2 Compl. ¶14

IV. Analysis of Infringement Allegations

No probative visual evidence provided in complaint.

The complaint is for a declaratory judgment of non-infringement. The following tables summarize SAP's stated reasons why its products do not meet the limitations of the asserted claims.

• '876 Patent Infringement Allegations

• '372 Patent Infringement Allegations

• Identified Points of Contention:
  • Architectural Mismatch: The central point of contention appears to be a fundamental architectural mismatch. SAP's non-infringement theory is that its products, likely designed as native multi-tenant systems, do not contain the specific, discrete "handler" and "translator" components described in the Corent patents, which are directed at retrofitting non-tenant-aware applications.
  • Scope Questions: A primary question for the court will be whether the terms "handler" and "translator," as used in the patents, can be construed broadly enough to read on functional aspects of SAP's integrated multi-tenant architecture, even if SAP does not use components with those specific names or that are structurally identical to the patents' embodiments.
  • Technical Questions: The dispute will raise the factual question of how SAP's BTP and related services actually implement multi-tenancy. The court will need to examine whether any part of SAP's system performs the distinct steps of (1) receiving a generic command, (2) performing a separate authorization check on whether to make it tenant-specific, and (3) translating the command based on that authorization, as required by the claims.

V. Key Claim Terms for Construction

• The Term: "handler"

  • Context and Importance: This term is central to the non-infringement arguments for the '876 and '372 patents Compl. ¶43 Compl. ¶47 SAP's position is that its products lack this claimed element. The case may turn on whether any part of SAP's authentication or data routing systems can be characterized as the claimed "handler."
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes the handler's role functionally, stating it "analyzes the non-tenant-specific data access command... and will then determine whether [it] should be translated" '591 Patent, col. 8:1-5 This functional language may support a broader construction covering any component that performs an authorization check.
    • Evidence for a Narrower Interpretation: The patent figures depict the "handler" as a distinct architectural block, separate from the "translator" '591 Patent, Fig. 2 The claims at issue also describe it as being "logically disposed between" the application and the data repository, suggesting a specific intermediary role that may support a narrower, structural interpretation Compl. ¶47

• The Term: "translator"

  • Context and Importance: Similar to "handler," SAP explicitly denies that its platforms provide the claimed "translator" Compl. ¶43 Compl. ¶47 The viability of Corent's infringement case will likely depend on construing this term to cover the way SAP's native multi-tenant systems direct data requests.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes the translator's function as translating a "non-tenant specific data access command into a tenant-specific data access command" '591 Patent, col. 8:6-9 This could be interpreted broadly to cover any process that modifies a data request to make it tenant-specific.
    • Evidence for a Narrower Interpretation: The claims require the translation to be performed "upon receipt of the authorization from the handler" and using "inferred unique tenant identifiers" from a "non-application source" Compl. ¶43 Compl. ¶47 These dependencies on other distinct components and external data sources could support a narrower construction requiring a multi-step process, not just an integrated data routing function.

VI. Other Allegations

• Indirect Infringement: SAP seeks a declaratory judgment that it has not infringed "directly or indirectly" Compl. ¶3 The complaint does not, however, provide specific factual allegations regarding the elements of inducement or contributory infringement, as the burden to prove these would fall on Corent in any subsequent counterclaim.
• Willful Infringement: This section is not applicable, as willfulness is an allegation made by a patent holder against an infringer. In this declaratory judgment action, SAP (the accused infringer) is the plaintiff.

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

This declaratory judgment action appears to be a preemptive measure by SAP in response to Corent's broader licensing and litigation campaign against major cloud providers. The resolution of the dispute will likely depend on the answers to two key questions.

• A core issue will be one of architectural equivalence: do SAP's modern, natively-built multi-tenant cloud platforms contain discrete or logically separable components that meet the limitations of the "handler" and "translator" architecture claimed in Corent's patents, which are directed at retrofitting legacy single-tenant applications? Or is there a fundamental mismatch between the patented solution and the accused systems?
• A dispositive legal question will be one of claim construction: can the terms "handler," "translator," and "discrete cloud resource" be construed functionally and broadly enough to read on the integrated systems of a modern cloud provider? Or will they be limited to the specific intermediary and partitioning architectures disclosed in the patents, potentially rendering them inapplicable to platforms not designed around retrofitting legacy software?