DCT

1:25-cv-01586

Altr Solutions Inc v. Immuta Inc

Log In
Key Events
Amended Complaint
complaint Intelligence

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:25-cv-01586, D. Del., 05/14/2026
  • Venue Allegations: Venue is asserted based on Defendant Immuta Inc. being a Delaware corporation, thus residing in the District of Delaware.
  • Core Dispute: Plaintiff alleges that Defendant's Immuta Platform, a data security and governance product, infringes five U.S. patents related to dynamically controlling access to sensitive data within databases.
  • Technical Context: The lawsuit concerns the data governance and security market, a field focused on managing and protecting sensitive data like PII, PCI, and PHI across complex cloud and on-premises database environments.
  • Key Procedural History: The complaint alleges that Defendant's CEO contacted Plaintiff's CEO on March 22, 2025, to discuss a potential acquisition, demonstrating, according to the complaint, detailed knowledge of Plaintiff's technology. Plaintiff also alleges pre-suit knowledge of the patents-in-suit through this communication, Defendant's review of third-party industry reports, and Plaintiff's public patent marking webpage.

Case Timeline

Date Event
2014-09-08 Defendant Immuta Inc. incorporated
2015-06-02 Priority Date for '330, '820, and '878 Patents
2018-06-05 Priority Date for '783 Patent
2020-01-07 Priority Date for '466 Patent
2021-10-05 '330 Patent Issued
2022-05-31 '878 Patent Issued
2025-03-22 Immuta CEO allegedly contacts ALTR CEO to propose acquisition
2025-04-22 '466 Patent Issued
2025-11-18 '820 Patent Issued
2026-04-14 '783 Patent Issued
2026-05-01 Plaintiff alleges Immuta gained knowledge of '783 Patent
2026-05-14 Complaint Filed

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

U.S. Patent No. 11,138,330 - "FRAGMENTING DATA FOR THE PURPOSES OF PERSISTENT STORAGE ACROSS MULTIPLE IMMUTABLE DATA STRUCTURES"

  • Patent Identification: U.S. Patent No. 11,138,330, "FRAGMENTING DATA FOR THE PURPOSES OF PERSISTENT STORAGE ACROSS MULTIPLE IMMUTABLE DATA STRUCTURES," issued October 5, 2021.

The Invention Explained

  • Problem Addressed: The patent describes the inadequacy of traditional datastore security, noting that attackers who penetrate a network can often modify or exfiltrate records and mask their activity by deleting access logs '330 Patent, col. 1:50-67
  • The Patented Solution: The invention introduces a "security driver" that intercepts database requests between an application and the database '330 Patent, Fig. 1 The driver classifies data into higher- and lower-security values '330 Patent, col. 10:4-5 It stores lower-security values in a conventional "lower-trust" database, but fragments higher-security values and stores these fragments across multiple separate, immutable data structures, like blockchains '330 Patent, col. 2:7-39 Pointers to these fragments are stored in the lower-trust database. Upon a read request, the driver retrieves the fragments using the pointers and reassembles the original data for the application, making the process transparent to the end-user application '330 Patent, col. 11:1-col. 12:28
  • Technical Importance: This data fragmentation and distribution architecture enhances security by physically and logically separating sensitive data from the primary database, making unauthorized access and tampering more difficult and more easily detectable.

Key Claims at a Glance

  • The complaint asserts at least independent Claim 1 Compl. ¶37
  • Claim 1, a system claim for a machine-readable medium, includes instructions for operations comprising the following essential elements:
    • obtaining a security driver that interfaces with a database driver, which in turn has an API for read/write requests;
    • registering the security driver to receive database requests from an application;
    • receiving those database requests in the API schema;
    • obtaining a policy to control data access;
    • modifying, based on the policy, a subset of data associated with a read request by identifying the subset and changing values within it to generate a modified subset; and
    • returning a response to the application that includes the modified subset of data in place of the original subset.

U.S. Patent No. 12,282,466 - "COMMUNICATING FINE-GRAINED APPLICATION DATABASE ACCESS TO A THIRD PARTY AGENT"

  • Patent Identification: U.S. Patent No. 12,282,466, "COMMUNICATING FINE-GRAINED APPLICATION DATABASE ACCESS TO A THIRD PARTY AGENT," issued April 22, 2025.

The Invention Explained

  • Problem Addressed: Traditional database systems often lack visibility into the specific application-level end-user initiating a query, treating all requests as coming from a single application user, which prevents fine-grained, user-specific access control and auditing '466 Patent, col. 1:44-59
  • The Patented Solution: The patent describes a driver that intercepts database requests and is configured to "obtain application-level user information delimited in the request" '466 Patent, abstract Using this user information, the driver consults a policy to apply user-specific rules, allowing it to "allow, mask, or disallow respective subsets of data" before returning a response to the application '466 Patent, abstract This process, illustrated in the patent's flowcharts, enables fine-grained access control based on the identity of the end-user, not just the application service account '466 Patent, Fig. 14
  • Technical Importance: This technology allows organizations to layer granular, user-aware security and governance on top of existing database systems that are not natively capable of such fine-grained control.

Key Claims at a Glance

  • The complaint asserts at least independent Claims 1 and 18 Compl. ¶48
  • Claim 1, a system claim, and Claim 18, a corresponding method claim, include the following essential steps/operations:
    • obtaining a database request from an application on a client;
    • detecting a value indicative of the user or client that generated the request;
    • obtaining policy information conveying permissions;
    • determining if the request implicates restricted information for that user;
    • obtaining the records from the database arrangement;
    • identifying the portion of restricted information within the obtained records;
    • modifying the restricted portion while leaving the unrestricted portion intact; and
    • providing a response to the application that includes the unrestricted information and reflects the modification of the restricted portion.

Multi-Patent Capsules

  • U.S. Patent No. 12,476,820

    • Patent Identification: U.S. Patent No. 12,476,820, "USING A TREE STRUCTURE TO SEGMENT AND DISTRIBUTE RECORDS ACROSS ONE OR MORE DECENTRALIZED, ACYCLIC GRAPHS OF CRYPTOGRAPHIC HASH POINTERS," issued November 18, 2025.
    • Technology Synopsis: This patent appears to build on the data fragmentation concept by describing the use of tree structures to segment and distribute records. This structure is used in conjunction with decentralized, acyclic graphs of cryptographic hash pointers, likely to enhance the security and efficiency of storing and retrieving fragmented data.
    • Asserted Claims: 1, 17-19, and 35-36 Compl. ¶59
    • Accused Features: The complaint alleges infringement based on Immuta's system for monitoring user query activity, applying access policies to obfuscate data fields based on user identity and other conditions, and evaluating user activity against configured thresholds Compl. ¶¶62-68

  • U.S. Patent No. 11,347,878

    • Patent Identification: U.S. Patent No. 11,347,878, "REPLACING DISTINCT DATA IN A RELATIONAL DATABASE WITH A DISTINCT REFERENCE TO THAT DATA AND DISTINCT DE-REFERENCING OF DATABASE DATA," issued May 31, 2022.
    • Technology Synopsis: This invention focuses on maintaining referential integrity in a database when sensitive data is replaced with a distinct reference (or pointer). It describes a system for replacing instances of a specific data value with a consistent reference and later de-referencing it, ensuring that database relationships (like foreign key joins) remain functional after the data is externalized for security.
    • Asserted Claims: 52-53 and 69-70 Compl. ¶70
    • Accused Features: The complaint targets Immuta's policy control plane, which governs access to data by receiving requests, selecting fields for replacement with non-revealing placeholders based on policy, and returning modified records to the application Compl. ¶¶78-98

  • U.S. Patent No. 12,603,783

    • Patent Identification: U.S. Patent No. 12,603,783, "DECENTRALIZED DATABASE OPTIMIZATIONS," issued April 14, 2026.
    • Technology Synopsis: This patent describes techniques for optimizing database operations in a decentralized or multi-tenant cloud environment. The invention involves obtaining a security policy and configuring the platform to rewrite queries according to that policy, returning a mix of cryptographically obfuscated and un-obfuscated data based on the permissions of the user making the request.
    • Asserted Claims: 22 and 29 Compl. ¶81
    • Accused Features: The complaint alleges infringement by Immuta's system for applying security policies in multi-tenant cloud platforms, rewriting queries, and returning results that mix obfuscated and un-obfuscated data based on user-specific permissions, particularly highlighting the use of salted cryptographic hash functions Compl. ¶¶101-111

III. The Accused Instrumentality

  • Product Identification: The accused product is the "Immuta Platform," also referred to as the "Immuta System" Compl. ¶17
  • Functionality and Market Context: The Immuta Platform is a data security and governance solution that acts as an intermediary, or proxy, between client applications and backend database systems Compl. ¶19 A core component is the "Immuta System Query Engine," which can be deployed in a cloud-based SaaS environment or as customer-managed software Compl. ¶19 The complaint alleges the platform intercepts database queries, modifies them and/or their results based on centrally managed governance policies, and returns policy-compliant data to the user Compl. ¶19 The platform is marketed as a "centralized hub" for controlling data access Compl. ¶18 and, according to the complaint, has achieved significant commercial traction, having raised over $267 million in funding Compl. ¶20 A product diagram in the complaint illustrates the platform architecture, showing a policy engine sitting between data sources and consumption applications Compl. ¶11

IV. Analysis of Infringement Allegations

11,138,330 Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
A tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors effectuate operations comprising: The Immuta System components are stored on tangible, non-transitory media and, when executed, perform query interception, transformation, and masking/unmasking operations. ¶37 col. 1:40-47
obtaining a security driver configured to interface with a database driver and applications compatible with the database driver, wherein: The Immuta System includes the Immuta Query Engine, a proxy that sits between client applications and backend data sources. The complaint provides a product architecture diagram showing this relationship Compl. ¶11 ¶37 col. 10:35-44
[wherein:] the database driver includes an application programming interface (API) configured to receive database requests in a schema of the API by which applications request to write data to or read data from a database, The Immuta System interfaces with ODBC drivers, which include an API to receive read and write requests from applications. ¶37 col. 10:25-34
[wherein:] the database driver reads data from the database responsive to a read request in the schema of the API, and The Immuta System's ODBC driver reads data from the underlying database in response to a transformed read request (e.g., a SQL SELECT statement), as depicted in a data flow diagram (Compl. ¶14). ¶37 col. 12:7-12
[wherein:] the database driver writes data to the database responsive to a write request in the schema of the API; The Immuta System forwards write requests to the underlying database via a database driver after rewriting and transforming the request based on applicable policies. ¶37 col. 11:49-54
registering the security driver to receive database requests in the schema of the API from an application compatible with the database driver; When a user authenticates to the Immuta Query Engine, the system establishes a session and registers the Query Engine (as the security driver) to receive subsequent requests from the user. ¶37 col. 10:1-3
receiving the database requests in the schema of the API from the application, at least some of the database requests being passed to the database driver in the schema of the API; The Immuta System receives database requests (e.g., SQL SELECT statements) in its PostgreSQL-compatible API and passes them on to the underlying database driver for execution. ¶37 col. 10:35-51
obtaining a policy by which access to at least some data within the database is controlled; The Immuta System obtains policy information at runtime by querying the Immuta policy service to determine which rows should be filtered or columns masked. ¶37 col. 10:5-6
modifying, in association with a received read request... a subset of data associated with the records responsive to applying the policy... The Immuta Query Engine intercepts and rewrites the query based on policy decisions (e.g., column masking, row filtering), which modifies the subset of data associated with the selected records. ¶37 col. 11:1-12
returning, to the application, responsive to the read request, a response including the modified subset of data in place of the subset of data within the records. The Immuta System returns the policy-modified query results to the requesting application, such that values in masked columns are replaced with hashed values, constants, or nulls. ¶37 col. 10:22-23
  • Identified Points of Contention:
    • Scope Question: A potential dispute may arise over whether the term "security driver" as taught in the patent is limited to a client-side software component that "wraps" a database driver, or if it can be read more broadly to cover a network proxy like the accused "Immuta Query Engine."
    • Technical Question: The patent's specification heavily emphasizes fragmenting data and storing it in separate immutable data structures. The complaint's allegations focus on Immuta's data masking and query rewriting. A central question will be whether the accused functionality of "modifying... a subset of data" through masking is technically equivalent to the patent's described solution of de-referencing pointers to retrieve fragmented data from secure storage.

12,282,466 Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
...obtaining, by a driver of a client executing an application, a database request generated by the application executing on the client; The Immuta Query Engine, or its Databricks Spark plugin, acts as a driver for the client application and obtains the database request (e.g., an SQL query) generated by the client tool. ¶48 col. 2:1-4
detecting, by the driver, at least one value indicative of a user of the application or the client executing the application that generated the database request; The Immuta Query Engine detects the user by requiring user-specific SQL credentials for connection. The Databricks integration detects the "current Spark user" and maps it to an Immuta identity. ¶48 col. 2:5-9
obtaining, by the driver, policy information conveying permissions to access information in at least some records... The Immuta Query Engine or its integration plugins obtain policy information from the Immuta service at runtime, defining permissions for different users based on attributes and groups. ¶48 col. 2:32-35
determining, by the driver, based on the permissions and the detected value, whether the user... is requesting access to a portion of restricted information... The system determines if the request implicates restricted data by applying the user's specific policy controls to the objects being queried, such as through row-level policies that compare data values with user metadata. ¶48 col. 2:10-18
obtaining, by the driver, information of records in the set of records implicated by the database request by conveying one or more requests for the information to the database arrangement; The Immuta driver (Query Engine or plugin) conveys a request to the underlying database arrangement to obtain the records implicated by the user's query. ¶48 col. 2:36-41
identifying, by the driver, based on the permissions, the portion of restricted information from the one or more records... The system identifies the restricted portion of the data by applying masking and redaction policies, which operate on specific columns, cells, or rows within the set of records returned from the database. ¶48 col. 2:52-59
modifying, by the driver, the portion of restricted information identified... without modifying at least some other portion of the obtained information...; The driver modifies only the restricted data, for example by applying masking functions that "hide values in data" (e.g., replacing with a hash or null) while leaving unrestricted columns and rows intact. ¶48 col. 2:52-59
providing, by the driver, to the application responsive to the database request, a database response including the at least some other portion of the obtained information. The driver provides the modified database response, containing a mix of unrestricted and modified data, back to the requesting application over the same SQL connection. ¶48 col. 2:60-64
  • Identified Points of Contention:
    • Scope Question: The claim requires "detecting... at least one value indicative of a user... that generated the database request." A key question for the court will be whether this requires the user identifier to be embedded within the request string itself (e.g., as a comment), or if it can be satisfied by associating the request with a user identity established at the connection or session level.
    • Technical Question: The complaint provides several infringement theories, including through a direct SQL connection to the Query Engine and through a Databricks Spark plugin Compl. ¶¶22-24 The evidence for how user context is "detected" may differ between these scenarios, raising a factual question for the court about whether each accused mode of operation meets the claim limitation in the same way. The complaint includes a sequence diagram illustrating how the Spark plugin "intercepts Spark calls to the Metastore" to enforce policies Compl. ¶24

V. Key Claim Terms for Construction

For U.S. Patent No. 11,138,330:

  • The Term: "security driver"
  • Context and Importance: This term defines the central component of the claimed invention. The infringement analysis for Claim 1 hinges on whether Defendant's "Immuta Query Engine" falls within the scope of this term. Practitioners may focus on this term because its construction could determine whether Immuta's proxy-based architecture is equivalent to the driver-centric model described in the patent.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification describes the security driver as a component that "interfaces between the application 28 and the database driver 32" ('330 Patent, col. 10:35-37). This language could support an interpretation that includes any software component, such as a network proxy, that sits logically between the application and the database driver.
    • Evidence for a Narrower Interpretation: The patent's figures and detailed description depict the security driver 30 as a component on the "client computing device" 12 that "wraps an application program interface of the database driver 32" ('330 Patent, Fig. 1; '330 Patent, col. 10:45-51). This could support a narrower construction requiring a specific client-side implementation, potentially distinct from a standalone proxy server.

For U.S. Patent No. 12,282,466:

  • The Term: "detecting... a value indicative of a user... that generated the database request"
  • Context and Importance: This phrase is critical as it defines how the system becomes aware of the application-level user in order to apply fine-grained policies. Whether Immuta's system "detects" a user value in the manner required by the claim is a core infringement question.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The patent abstract broadly describes obtaining "application-level user information delimited in the request" '466 Patent, abstract This could be argued to cover any method where user context is made available to the driver for a given request, including context established at the session or connection level.
    • Evidence for a Narrower Interpretation: The claim language "detecting... a value... that generated the database request" suggests the value is part of the request object itself. The patent's detailed description provides examples like user information in a comment field or as a bound parameter ('466 Patent, col. 67:35-43; '466 Patent, col. 69:1-12), which could support a narrower construction requiring the user identifier to be explicitly passed with each query.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges both induced and contributory infringement for all five patents-in-suit. Inducement is primarily based on allegations that Immuta knowingly provides its customers with instructions, documentation, "how-to guides," and customer support that encourage use of the Immuta Platform in an infringing manner Compl. ¶38 Compl. ¶49 Compl. ¶60 Compl. ¶71 Compl. ¶82 Contributory infringement is alleged on the basis that the Immuta Platform is a material part of the patented inventions, is not a staple article of commerce, and is especially made or adapted for infringing use Compl. ¶39 Compl. ¶50 Compl. ¶61 Compl. ¶72 Compl.g. ¶83
  • Willful Infringement: Willfulness is alleged for all five patents and is grounded in alleged pre-suit knowledge. The complaint asserts that Immuta's CEO contacted ALTR's CEO via LinkedIn on March 22, 2025, to discuss an acquisition, and that this communication demonstrated a detailed familiarity with ALTR's technology Compl. ¶22 The willfulness claim is further supported by allegations that Immuta had access to ALTR's public patent marking webpage and was aware of ALTR through third-party industry comparisons Compl. ¶¶25-29 For the '783 Patent specifically, knowledge is alleged as of May 1, 2026, through communications with counsel Compl. ¶30

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

  • A core issue will be one of functional and architectural equivalence: does the Immuta Platform, which operates as a proxy query engine, function in the same way as the claimed "security driver" that intercepts and modifies database requests and responses? The court will need to determine if Immuta's methods for data masking and policy enforcement are technically equivalent to the patent's descriptions of data fragmentation ('330 patent) and in-request user detection ('466 patent).
  • A second central question will be one of claim scope: can the term "security driver" ('330 Patent) be construed to cover a network proxy, and can "detecting... a value indicative of a user" ('466 Patent) be construed to cover user context established at the session level rather than being embedded in each query? The outcome of these claim construction disputes will likely be dispositive for infringement.
  • Finally, a key evidentiary question for willfulness will be the nature of pre-suit knowledge: what level of specific knowledge did the alleged March 2025 communication between the parties' CEOs establish? The court will examine whether this and other evidence shows that Immuta had knowledge of the specific patented inventions, as opposed to a general awareness of ALTR's products in the marketplace.
Loading Amended Complaint