Corent Technology Inc v. Amazon Web Services Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Corent Technology, Inc. (Delaware)
  • Defendant: Amazon Web Services, Inc. (Washington)
  • Plaintiff’s Counsel: Reichman Jorgensen Lehman & Feldberg LLP
• Case Identification: 8:26-cv-00194, C.D. Cal., 01/27/2026
• Venue Allegations: Venue is based on Defendant AWS maintaining regular and established places of business within the Central District of California, including corporate and technology offices in Irvine, and having committed acts of infringement in the district.
• Core Dispute: Plaintiff alleges that Defendant’s cloud computing services—including its migration, container orchestration, application marketplace, and serverless platforms—infringe four patents related to automating cloud migration, workload orchestration, multi-tenant database connectivity, and usage metering.
• Technical Context: The technology at issue addresses foundational challenges in cloud computing: efficiently moving legacy software to the cloud and subsequently managing, orchestrating, and monetizing those applications in a scalable, multi-tenant environment.
• Key Procedural History: The complaint alleges a history between the parties, including meetings and product demonstrations involving the patented technology dating back to 2019. Plaintiff also alleges it provided Defendant with specific notice of infringement via a letter on December 22, 2025, approximately one month before filing suit.

Case Timeline

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

U.S. Patent No. 11,019,136 - “PARTITIONING AND MAPPING WORKLOADS FOR SCALABLE SAAS APPLICATIONS ON CLOUD” (Issued May 25, 2021)

The Invention Explained

• Problem Addressed: The patent’s background section describes the difficulty of migrating traditional, "non-tenant-aware" software applications to the cloud. Such applications are often "not well suited to a particular cloud environment" and may "run inefficiently," failing to take advantage of the cloud's resources (Compl. ¶65; ’136 Patent, col. 1:45-51).
• The Patented Solution: The invention proposes a method to automate and optimize this migration and orchestration process. The method involves systematically identifying an application's component "workloads," partitioning them based on their characteristics, grouping them into "sub-partitions," assigning them to specific cloud resources, and then constructing and ranking different potential "workload assignment maps" based on user-defined rules such as cost, efficiency, or scalability Compl. ¶¶64, 66 ’136 Patent, col. 2:67-3:2
• Technical Importance: This technology aims to transform the complex, often manual, process of cloud migration analysis into a structured, automated, and optimizable method.

Key Claims at a Glance

• The complaint asserts independent claim 1 Compl. ¶67
• Claim 1 is a method for configuring workloads, comprising the steps of:
  • Identifying workloads of a non-tenant-aware application and their characteristics.
  • Creating a partition of the workloads based on a specific characteristic.
  • Grouping the created partition into multiple workload sub-partitions based on a common characteristic.
  • Assigning each partition to a set of cloud resources.
  • Constructing multiple workload assignment maps for the workloads.
  • Ranking the assignment maps based on a set of rules.
• The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 10,320,893 - “PARTITIONING AND MAPPING WORKLOADS FOR SCALABLE SAAS APPLICATIONS ON CLOUD” (Issued June 11, 2019)

The Invention Explained

• Problem Addressed: The patent addresses the same technical problem as the ’136 Patent: the inefficient and complex process of migrating legacy applications to the cloud and orchestrating their workloads effectively post-migration (Compl. ¶72; ’893 Patent, col. 1:38-44).
• The Patented Solution: Rather than a method, this patent claims a system for configuring workloads. The system is composed of specific functional modules: a "scanning engine" to identify workloads, a "partitioning engine" to group them, a "mapping engine" to assign them to cloud resources based on administrator-defined rules, and a "rendering engine" to construct a final migration plan Compl. ¶74 ’893 Patent, col. 2:5-14 This provides a concrete architecture for implementing the migration analysis process.
• Technical Importance: The invention provides a defined system architecture for automating the analysis and planning of cloud migrations.

Key Claims at a Glance

• The complaint asserts independent claim 1 Compl. ¶74
• Claim 1 is a system for configuring workloads, comprising:
  • A scanning engine to identify workloads of a non-tenant-aware application using rules in a workload partitioner database.
  • A partitioning engine to group the workloads into partitions based on common characteristics, using rules in a partition mapper database.
  • A mapping engine to assign each partition to a discrete cloud resource based on partition and cloud resource characteristics.
  • A rendering engine to construct a migration plan based on the assignments from the mapping engine.
  • The engines comprise stored program instructions on a non-transitory computer readable storage medium executed by a processor.
• The complaint does not explicitly reserve the right to assert dependent claims.

U.S. Patent No. 9,495,372 - “MULTI-TENANT AGILE DATABASE CONNECTOR” (Issued Nov. 15, 2016)

Technology Synopsis

The ’372 Patent addresses the challenge of making a traditional single-tenant application work in a multi-tenant cloud environment without requiring significant reprogramming of the application itself Compl. ¶79 The patented solution is an "agile database connector," an interface module that sits between the application and the database, which transparently intercepts the application’s generic data requests and translates them into tenant-specific commands, thereby maintaining data isolation between tenants Compl. ¶¶78, 80 ’372 Patent, col. 2:29-34

Asserted Claims

Independent claim 1 is asserted Compl. ¶81

Accused Features

The complaint accuses AWS Serverless SaaS offerings of infringement, alleging they provide multi-tenant database architectures (e.g., database-per-tenant and sharded models) that embody the patented connector technology Compl. ¶¶113-119, 137

U.S. Patent No. 10,305,761 - “MULTI - APPLICATION SAAS METERING ENGINE” (Issued May 28, 2019)

Technology Synopsis

The ’761 Patent addresses the problem of accurately tracking and billing for cloud resource consumption in a multi-tenant SaaS environment on a per-user or per-tenant basis Compl. ¶86 The invention moves beyond simple "block billing" (e.g., fixed storage or time limits) by providing a system with a "metering engine" to monitor data streams, an "identity engine" to identify the specific user, and a "bucket aggregator" to aggregate that user's activity for precise, usage-based billing Compl. ¶¶85, 87 ’761 Patent, col. 3:56-63

Asserted Claims

Independent claim 1 is asserted Compl. ¶160

Accused Features

The complaint accuses AWS Marketplace and its associated billing and cost management services, alleging they provide metered usage capabilities that allow for tenant-specific identification, measurement, and comparison of usage, thereby infringing the patent Compl. ¶¶108-110, 137

III. The Accused Instrumentality

Product Identification

The complaint names a suite of Amazon Web Services products, collectively referred to as the "Accused Products" Compl. ¶89 The primary accused instrumentalities are AWS Migration Hub and AWS Transform (collectively "AWS Migration"), AWS EKS Managed Kubernetes Service ("EKS"), AWS Marketplace, and AWS Serverless SaaS Platform, along with their constituent components Compl. ¶89

Functionality and Market Context

• AWS Migration: These services are designed to help customers move on-premises applications to the AWS cloud. The complaint alleges they operate in phases: a "discover" phase to identify and inventory on-premises architecture, a "migrate" phase where workloads are grouped and mapped to AWS resources, and a "track" phase Compl. ¶¶94-97 A diagram in the complaint illustrates a workflow where a "Server Migration Connector" analyzes a data center and feeds information to the AWS Migration Hub, which then uses other AWS services to create templates and migrate the application Compl. p. 7
• EKS: This is a managed service for deploying and scaling containerized applications using Kubernetes Compl. ¶103 The complaint alleges that EKS, through its use of the Kubernetes scheduler, automatically assigns containerized workloads to cloud resources based on filtering, scoring, and mapping, which constitutes an infringing orchestration system Compl. ¶104 The complaint includes a diagram showing the Kubernetes architecture, highlighting the role of the scheduler in managing workloads across different nodes Compl. p. 29, ¶103
• AWS Marketplace / Serverless SaaS: These platforms allegedly enable the monetization and multi-tenant operation of applications on AWS. The complaint alleges AWS Marketplace provides metering services for charging customers based on usage, and that the Serverless SaaS platform provides architectures for running single-tenant applications for multiple tenants Compl. ¶¶108, 112-114 The complaint presents a screenshot comparing the free 90-day pricing for AWS's migration service against the paid tiers of Corent's competing service, which is also offered on the AWS Marketplace Compl. p. 28, ¶101

IV. Analysis of Infringement Allegations

The complaint references exemplary claim charts attached as exhibits, but these exhibits were not included in the provided documents. The infringement theory is therefore summarized from the complaint's narrative allegations.

’136 and ’893 Patents Infringement Allegations (AWS Migration and EKS)

The complaint alleges that AWS Migration and EKS directly infringe the claims of the workload partitioning and mapping patents. The narrative theory suggests that the "discover" phase of AWS Migration Hub performs the claimed step of "identifying workloads" Compl. ¶95 The "migrate" phase, which involves grouping servers and analyzing dependencies, is alleged to meet the limitations of "partitioning" workloads and "assigning" them to cloud resources Compl. ¶96 The system's analysis to find a "most favorable mapping" before migration is alleged to be the claimed "ranking" of "assignment maps" Compl. ¶97 Similarly, the complaint alleges that the Kubernetes architecture within EKS, which automatically assigns containerized workloads to resources via its scheduler, embodies the claimed system and performs the claimed method Compl. ¶¶103-104 The complaint includes a screenshot of the AWS Migration Hub user interface showing buttons for "Discover," "Migrate," and "Track," which Plaintiff aligns with its infringement theory Compl. p. 26, ¶95

Identified Points of Contention

• Scope Questions: A central question may be whether the analysis of "on-premises virtual machines" and "multi-tier applications" as conducted by AWS Migration Hub Compl. ¶93 falls within the scope of identifying "workloads of a non-tenant-aware application" as required by the claims. A similar question arises for EKS, where the dispute may center on whether a "container" or "pod" in Kubernetes constitutes a "workload" as contemplated by the patents.
• Technical Questions: The infringement case may turn on whether the accused products perform the specific two-level grouping structure required by claim 1 of the ’136 Patent ("creating a partition" and then "grouping the created partition into a plurality of workload sub-partitions"). The complaint's description of AWS "group[ing] servers as applications" Compl. ¶96, fn. to ¶95 raises the question of whether this single grouping action meets the multi-step limitation. For the ’893 Patent, a key question will be whether the functional components of AWS Migration Hub or EKS can be discretely mapped to the claimed "scanning engine," "partitioning engine," "mapping engine," and "rendering engine."

V. Key Claim Terms for Construction

The Term: "workload" (asserted in claims of the '136 and '893 Patents)

• Context and Importance: This term defines the fundamental unit being analyzed, partitioned, and mapped. The outcome of the case may depend on whether this term is construed broadly to cover modern computing units like containers and virtual machines, or more narrowly to the specific software modules described in the patent's embodiments. Practitioners may focus on this term because the accused EKS product primarily orchestrates containers, which may differ from the "workloads" envisioned when the patent was filed.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification of the related ’893 Patent defines a "workload" as "an independently executable software sub-unit on a computing hardware," which could support a broad reading that includes containers or VMs Compl. ¶33 ’893 Patent, col. 7:58-60
  • Evidence for a Narrower Interpretation: The detailed description focuses on "modules of a software application" (e.g., ’893 Patent, col. 6:20-22). A defendant may argue that this context limits "workload" to constituent parts of a monolithic application, not standalone, self-contained units like containers.

The Term: "creating a partition...; grouping the created partition... into a plurality of workload sub-partitions" (asserted in claim 1 of the '136 Patent)

• Context and Importance: This two-step limitation defines the core of the patented method. The infringement analysis will hinge on whether the accused products perform this specific hierarchical grouping.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: A plaintiff might argue that any logical grouping followed by a more granular sub-grouping satisfies this element, even if not explicitly labeled as "partition" and "sub-partition" in the accused product's documentation.
  • Evidence for a Narrower Interpretation: The claim language explicitly requires two distinct steps: first creating "a partition" (singular) and then grouping that partition into "a plurality of... sub-partitions" (plural). A defendant may argue that a process that creates multiple parallel groups simultaneously, such as the Kubernetes scheduler assigning pods to nodes, does not meet the sequential and hierarchical structure required by the claim's plain language.

VI. Other Allegations

Indirect Infringement

The complaint alleges both induced and contributory infringement for all four patents. The inducement claims are based on allegations that AWS provides extensive documentation, technical support, product manuals, and websites that instruct and encourage customers to use the Accused Products in an infringing manner Compl. ¶¶142, 148, 155, 162 The contributory infringement claims allege that AWS supplies a material part of the invention (e.g., the AWS Migration Hub software) with knowledge of the patents, and that this part is not a staple article of commerce and is incapable of substantial non-infringing use Compl. ¶¶143, 149, 156, 163

Willful Infringement

The complaint alleges willful infringement based on pre-suit knowledge. It asserts that AWS has been aware of Corent's patents since at least 2019 through direct business meetings, product demonstrations, and discussions with Corent's team Compl. ¶99 This was allegedly reinforced by a formal notice letter sent on December 22, 2025, which identified the patents-in-suit and the accused products Compl. ¶137 The complaint alleges that AWS continued its infringing conduct despite this knowledge Compl. ¶¶139, 144

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

This dispute appears to center on whether foundational, widely-adopted cloud services from a market leader perform the specific methods and embody the particular systems claimed in Plaintiff's patents. The key questions for the court will likely be:

1. A core issue will be one of technical mapping: does the operational logic of the accused AWS services—particularly the analysis performed by AWS Migration Hub and the container orchestration managed by the Kubernetes scheduler in EKS—align with the specific, multi-step claim limitations requiring hierarchical partitioning, mapping based on administrator-defined rules, and distinct functional "engines"?
2. A second key issue will be one of definitional scope: can claim terms like "workload" and "partition," which are rooted in the context of migrating and organizing software application modules, be construed to read on the more modern, abstracted computing units such as "containers," "pods," and "virtual machines" that are the primary objects of management in the accused EKS and Migration Hub services?
3. A significant evidentiary question will concern knowledge and intent: what was the extent of AWS's knowledge of the asserted patents from the alleged 2019 meetings, and how will the Plaintiff’s allegations of a predatory business model—using free migration tools to lock customers into a paid ecosystem—influence the judicial view on the issues of willfulness and damages?