Patent Drafting Analysis of C3.ai’s Generative AI Enterprise Search System | US 2024/0202221 A1
Patent Drafting Analysis of C3.ai's Generative AI Enterprise Search System | US 2024/0202221 A1
A structural and strategic analysis of US 2024/0202221 A1, examining claim architecture, drafting quality, critical gaps, and prosecution positioning for C3.ai's access-controlled enterprise generative AI search platform.
Spec Words
12,400
Across 6 sections
Draft now ↗
Total Claims
29
3 independent · 26 dependent
Draft now ↗
Figure Sheets
13
System architecture, UI interfaces, flow diagrams
Draft now ↗
Published by PatSnap Insights Team · · 13 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates the specification at approximately 67% of total words (~8,300 of ~12,400), with 13 figures spanning system architecture, flow diagrams, and graphical user interface mockups that collectively provide broad visual coverage of the disclosed embodiments. The claim set comprises 29 claims total — 3 independent and 26 dependent — yielding a dependent-to-independent ratio of approximately 8.67:1, which is high for the software/AI IPC class and signals a deliberate layered fallback strategy. Figure coverage is robust across all major operational flows, with FIGs. 5, 6, 9, and 10 directly mapping to the independent method claims and FIG. 4 providing architectural support for the system claim in Claim 28.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 13 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Depicts the enterprise generative AI system architecture showing enterprise systems 104, external systems 106, domain models 108, connectors 110, LLMs 120, retrieval models 122, embedding models 124, vector stores 126, and enterprise access control layer 115.Search in Eureka ↗ | System architecture |
| FIG. 2A | Shows the enterprise generative AI query graphical user interface 200 with NLP layer 202, generative pre-trained transformer layer 204, query types (free text, SQL, NoSQL, image, video) 206, and enterprise datastores 208.Search in Eureka ↗ | UI/interface |
| FIG. 2B | Depicts the enterprise generative AI response GUI 250 showing query input 252, AI summary 260 with source data portions 268, source identifications 269, feedback elements 270, and interactive chat portion 256.Search in Eureka ↗ | UI/interface |
| FIG. 3 | Illustrates a network system 300 for enterprise generative AI search showing the enterprise generative AI system 302 connected via communication network 308 to enterprise systems 303-304-N and external systems 306-1 to 306-N.Search in Eureka ↗ | System architecture |
| FIG. 4 | Diagrams enterprise generative AI system 400 showing all modules: management 402, orchestrator 404, retrieval 406, agent 408, tool 410, enterprise comprehension 412, crawling 414, enterprise access control 416, AI traceability 418, extractor 420, parallelization 422, model generation 424, deployment 426, optimization 428, presentation 430, communication 432, and datastores 440/450/470.Search in Eureka ↗ | System architecture |
| FIG. 5 | Flowchart 500 depicting the enterprise generative AI method with steps: generating potential responses 502, determining validation data 504, selecting deterministic response 506, outputting with validation data 508, generating traceability analysis 510, and outputting traceability analysis 512.Search in Eureka ↗ | Claim support |
| FIG. 6 | Flowchart 600 showing enterprise generative AI method: receiving query 602, identifying enterprise datasets and AI applications 604, determining relevance scores 606, determining particular information via generative AI models and access controls 608, generating natural language output 610, facilitating presentation 612.Search in Eureka ↗ | Claim support |
| FIG. 7A | Depicts example enterprise generative AI response GUI 700 for an ESG query showing search bar 702, AI summary with off-track status 705, CO2 reduction plan visualization 714, interactive chat 706 with summary, and query formulation portion 710.Search in Eureka ↗ | UI/interface |
| FIG. 7B | Shows the ranked list of results 718 portion of the enterprise AI response GUI 700 with sources (C3.ai, Schneider Electric, Tableau, GHG Protocol, Sphera, Microsoft365) and types (Application, Webpage, CSV, PDF) with a regenerate answer button 720.Search in Eureka ↗ | UI/interface |
| FIG. 8 | Diagrams the iterative enterprise generative AI process 800 showing orchestrator 803, retrieval agent 804, enterprise comprehension module 806, LLM query and rationale generator 812, LLM answer generation 813, early-stop decision 807, user feedback loop 816-818, and historical rationale datastore 810.Search in Eureka ↗ | Flow diagram |
| FIG. 9 | Flowchart 900 depicting the enterprise generative AI method steps: processing query input 902, identifying AI applications and data models 904, analyzing query input 906, determining relevance score by machine learning model 908, generating query sets 910, composing response output 912.Search in Eureka ↗ | Claim support |
| FIG. 10 | Flowchart 1000 showing enterprise search method: receiving natural language enterprise search query 1002, retrieving data records via retriever models 1004, determining relevance scores 1006, selecting data records 1008, applying access control protocols 1010, determining access-controlled NL output via LLMs 1012, facilitating presentation 1014.Search in Eureka ↗ | Claim support |
| FIG. 11 | Diagrams computing device 1102 comprising processor 1104, memory 1106, storage 1108, input device 1110, communication network interface 1112, output device 1114, and communication channel 1116 connected to network 1118.Search in Eureka ↗ | System architecture |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent presents 3 independent claims — Claims 1, 11, and 28 — comprising two method claims and one system claim, with no explicit computer-readable medium (CRM) claim filed, leaving a significant coverage gap. The dependent-to-independent ratio of 8.67:1 is well above the software/AI norm of 4–6:1, indicating deliberate effort to build fallback positions, though the dependent claims are concentrated heavily under Claims 1 and 11 with only one dependent claim (Claim 29) under the system Claim 28. The bipartite method structure in Claims 1 and 11 reflects two distinct operational flows — a deterministic response selection flow and a query-based relevance scoring flow — providing layered enforcement coverage across different enterprise AI use cases.
Core inventive concept: The claims address the problem of unreliable, hallucination-prone, and access-uncontrolled generative AI responses in enterprise environments by generating a set of potential responses from multiple data domain models, scoring them against validation data, and selecting a "deterministic response" based on both validation scoring and access controls drawn from "view profile information associated with the prompt" — ensuring that different users with different access rights receive different, traceable, and non-hallucinated responses from the same enterprise data corpus.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method | comprising | generating set of potential responses using one or more data models from plurality of data domains of enterprise information environment with access controls; determining validation data from plurality of data domains; selecting deterministic response based on scoring of validation data and restricting based on access controls in view profile information associated with prompt; outputting selected deterministic response with corresponding validation dataSearch prior art ↗ |
| Claim 11 | A method | comprising | receiving a query; identifying based on query one or more enterprise data sets, AI applications, and data models from plurality of different data domains; determining plurality of relevance scores based on data models from different data domains; determining by one or more generative AI models based on relevance scores and enterprise access control protocols particular information from plurality of data domains; generating natural language output based on particular information; facilitating presentation of natural language outputSearch prior art ↗ |
| Claim 28 | A system | comprising | human computer interface capable of processing natural language requests; memory storing instructions causing system to perform: knowledge module curating data domains via orchestration module for embedding objects, retrieval AI modules analyzing received requests using multi-modal machine learning models to determine relevant objects from data domains, enterprise comprehension module discerning critical information from relevant data domains and generating new insight content, wherein human computer interface presents critical information with new insight content in response to received requestsSearch prior art ↗ |
Claim Dependency Tree
1 Method: generating potential responses via data models from enterprise data domains with access controls, selecting deterministic response based on validation scoring and view profile access controlsSearch Claim 1 prior art ↗
2 Adds: generating traceability analysis of validation data indicating documents, document segments, and insightsSearch in Eureka ↗
3 Adds: scoring validation data comprises determining relevance scores based on one or more data modelsSearch in Eureka ↗
4 Adds: data models comprise multiple models trained for different data domains, each representing relationships and attributes including data types, formats, and industry-specific informationSearch in Eureka ↗
5 Adds: data models include multimodal models wherein at least one is a large language modelSearch in Eureka ↗
6 Adds: access controls enforce restrictions including administrative policies, security policies, profile rights, and organizational controlsSearch in Eureka ↗
7 Adds: access controls cause a different deterministic response to be selected based on profiles with different access rightsSearch in Eureka ↗
8 Adds: access controls cause different validation data to be output based on profiles with different access rightsSearch in Eureka ↗
9 Adds: selected deterministic response comprises at least one of predictions, insights, or recommendations from an AI applicationSearch in Eureka ↗
10 Adds: output includes at least one of data visualization, automated control and instruction, report, and dynamically configured dashboardSearch in Eureka ↗
11 Method: receiving query; identifying enterprise datasets, AI applications, and data models; determining relevance scores; determining particular information via generative AI models and enterprise access control protocols; generating and presenting natural language outputSearch Claim 11 prior art ↗
12 Adds: query comprises a natural language query received through a graphical user interfaceSearch in Eureka ↗
13 Adds: enterprise data sets include documents, document segments, and insights generated by AI applicationsSearch in Eureka ↗
14 Further: each relevance score associated with respective portion of enterprise data sets, scores determined relative to other portionsSearch in Eureka ↗
15 Further: generating traceability analysis of natural language output indicating documents, segments, and insightsSearch in Eureka ↗
16 Adds: each data model of plurality corresponds to a different data domainSearch in Eureka ↗
17 Further: each data model represents relationships and attributes of corresponding data domainSearch in Eureka ↗
18 Further: relationships and attributes include data types, data formats, and industry-specific informationSearch in Eureka ↗
19 Further: natural language output comprises summary of at least one of the respective portions of enterprise data sets associated with a relevance scoreSearch in Eureka ↗
20 Adds: embedding respective objects in plurality of different data domains, wherein objects enable one or more enterprise access control protocolsSearch in Eureka ↗
21 Adds: enterprise access control protocols include user role-based enterprise access control protocolsSearch in Eureka ↗
22 Adds: access control protocols cause first user with first user role to be presented with different NL output relative to second user with second user roleSearch in Eureka ↗
23 Adds: access control protocols cause: preventing presentation of portion of NL output; preventing portion of particular information from being used to generate NL output; preventing, prior to identification, access to particular enterprise data sets, AI applications, data models, and data domainsSearch in Eureka ↗
24 Further: generative AI models are separated from enterprise data sets; separation includes not training generative AI models on enterprise dataSearch in Eureka ↗
25 Further: generative AI models trained on domain data from plurality of different data domains, wherein domain data does not include enterprise dataSearch in Eureka ↗
26 Further: natural language output comprises deterministic response caused at least in part by separation of generative AI models from enterprise data setsSearch in Eureka ↗
27 Further: separation of generative AI models from enterprise data reduces hallucination and information leakage relative to other generative AI models trained on other enterprise dataSearch in Eureka ↗
28 System: human computer interface processing natural language requests; memory with instructions for knowledge module curating data domains, retrieval AI modules using multi-modal ML models, enterprise comprehension module discerning critical information and generating insight contentSearch Claim 28 prior art ↗
29 Adds: single HCI usable by multiple users with different roles; retrieval AI models modulate critical information to enforce access, privacy, and security protocols based on user role or profileSearch in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 29 | 15 – 25 |
| Independent claim count | 3 | 1 – 3 |
| Dependent : Independent ratio | 8.67 : 1 | 4 – 6 : 1 |
| Method claims present? | Yes — Claims 1, 11 | Common |
| System / apparatus claims? | Yes — Claim 28 | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The patent's strongest drafting features are the deliberate separation of generative AI models from enterprise training data — a specific structural limitation in Claims 24–27 that directly addresses §101 eligibility by tying the invention to a concrete hardware-software integration — and the robust dependent claim fallback in Claims 6–10 and 20–27 that adds meaningful access control specificity. The principal drafting weakness is the absence of a computer-readable medium (CRM) claim, leaving the patent without a non-transitory storage medium vehicle that would be standard in this IPC class and is needed to capture infringement by software distributed without running servers.
✅
Antecedent Basis
The claim set is largely clean on antecedent basis. In Claim 1, "the set of potential responses" is properly anteceded by "a set of potential responses" in the generating step; "the validation data" properly refers back to "validation data" in the determining step; and "the selected deterministic response" refers back to "a deterministic response" in the selecting step. Claim 11 similarly introduces "a query" before using "the query," and "a plurality of relevance scores" before "the plurality of relevance scores." No orphaned "the" references were identified across the 29-claim set, which strengthens the application against §112(b) indefiniteness rejections.
✅
Spec–Claim Consistency
FIG. 5 (steps 502–512) and paragraphs [0103]–[0112] directly map to every limitation of Claim 1 in sequential order, providing excellent written description support. FIG. 6 (steps 602–616) and paragraphs [0113]–[0120] map step-by-step to Claim 11's independent limitations. The system Claim 28's three module elements (knowledge module, retrieval AI module, enterprise comprehension module) are individually described at length in paragraphs [0069]–[0083] with reference to FIG. 4. The access control limitations in Claims 6–8 and 21–23 are supported by enterprise access control module 416 described in paragraphs [0088]–[0092] and enterprise access control layer 115 in FIG. 1.
✅
Transition Word Usage
All independent claims (1, 11, 28) use "comprising," which is the broadest open-ended transition available and appropriate for a software/AI patent in the G06F class where functionality can be implemented with additional unrecited components. This preserves breadth against infringers who add modules not listed in the claims. The use of "comprising" is consistent throughout all 29 claims, including dependent claims — no claim uses "consisting of" or "consisting essentially of," which would unnecessarily narrow scope. The drafting team correctly avoided "including" as a transition, which has less settled legal meaning. No missed opportunity to use "wherein" clauses to add functional limitations without tightening the claim type was identified.
⚠️
§112(f) Means-Plus-Function Risk
Claim 28's system claim uses functional module language — "a knowledge module," "a retrieval AI modules" [sic], and "an enterprise comprehension module" — that may invoke §112(f) treatment if these are construed as nonce words substituting for "means for." While the specification provides detailed structural descriptions of these modules in FIG. 4 and paragraphs [0058]–[0083], the claims themselves provide only functional descriptions ("curates data domains," "analyze received requests," "discern critical information") without citing corresponding structure. An examiner applying MPEP 2181 could find these terms invoke §112(f), requiring the corresponding structure to be identified in the specification — and potentially narrowing the claim to only the specific architecture disclosed. A stronger filing would have added explicit structural language or recited "non-transitory memory storing instructions" instead of named modules.
⚠️
§101 Eligibility Risk
Claims 1 and 11 face meaningful Alice Step 1 exposure as they recite abstract ideas of information retrieval, filtering, and natural language output generation — activities courts have treated as mental processes or methods of organizing human activity. The best §101 defense available in the claim set is the "deterministic response" selection mechanism in Claim 1 (rooted in access controls tied to "view profile information") and the "separation of generative AI models from enterprise data" in Claim 24, both of which paragraph [0156] frames as "a claimed solution rooted in computer technology" that "overcomes problems specifically arising in the realm of computer technology." However, Claims 11 and 28 do not expressly incorporate the deterministic response limitation, leaving those claims more exposed. A continuation filing adding a CRM claim with the deterministic response limitation tied to specific hardware would strengthen the overall eligibility posture.
✅
Dependent Claim Fallback Quality
The dependent claim set adds genuinely distinct fallback positions across multiple dimensions. Claims 2 (traceability analysis), 3 (relevance scoring mechanics), 4 (multi-domain models), 5 (multimodal/LLM specificity), 6 (access control policy types), 7–8 (profile-differentiated responses and validation data), and 24–27 (AI model separation from enterprise data) each add independent technical limitations not captured elsewhere. Particularly strong is the Claims 23–27 chain under Claim 11, which progressively narrows the access control mechanism from preventing output presentation, to preventing data use in generation, to preventing pre-identification access, to the AI model separation architecture — creating a coherent design-around barrier. Weaker are Claims 9 and 10 under Claim 1, which merely enumerate output types (predictions, insights, recommendations; data visualization, reports) rather than adding structural limitations.
⚠️
Abstract Quality
The abstract accurately describes the overall system but buries the most novel limitation — the deterministic response selection based on simultaneous scoring of validation data and access controls from view profile information — in its third sentence after general statements about enterprise generative AI. An examiner reading only the abstract would likely classify the application as a general enterprise AI search system rather than identifying the specific technical contribution of deterministic, access-differentiated response selection from a candidate response set. The abstract states "A deterministic response is selected from the set of potential responses based on scoring of the validation data and restricting based on access controls in view profile information associated with the prompt" — this correctly appears but follows more generic language that reduces its salience for art-unit classification and prior art search purposes.
✅
Figure Support Quality
Figure support is strong across the independent claim limitations. The four flow-diagram figures (FIGs. 5, 6, 9, 10) directly map to the operational steps of Claims 1 and 11 in sequential block correspondence, and FIG. 4's module diagram provides explicit structural support for all three modules named in Claim 28. The enterprise access control layer 115 in FIG. 1 supports the access control limitations in Claims 6–8 and 21–23. The one notable gap is that no figure explicitly shows the "view profile information" as a discrete data structure tied to the prompt — while described in paragraphs [0105] and [0175], a dedicated figure illustrating the profile-to-access-control mapping would have strengthened written description support for this key limitation in Claim 1.
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Scorecard
Strategic Intent Scorecard
Multi-dimensional assessment of this application's patent strategy quality, based on claim structure, specification depth, and prosecution positioning.
Claim Breadth
3.5
Prosecution Defensibility
3.2
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3.8
Claim Type Diversity
2.5
Figure Support Quality
4
Key observation: The highest-scoring dimension is Spec–Claim Consistency (4.2/5.0) — every independent claim limitation maps directly to a numbered flowchart step in one of FIGs. 5, 6, 9, or 10, and to specific paragraphs in the detailed description, creating minimal §112(a) written description risk. The lowest-scoring dimension is Claim Type Diversity (2.5/5.0) — the absence of a non-transitory computer-readable medium (CRM) claim is the most significant structural gap, as it leaves C3.ai without a vehicle to capture infringement by parties who implement the method via distributed software rather than an operating system, and this gap cannot be cured post-filing without a continuation. Practitioners should note that Claim 28's functional module language creates a latent §112(f) risk that may require amendment during prosecution to explicitly recite processor-and-memory structure.
See how your own draft compares — Open Eureka IP Drafting →
Critical Gaps
3 Critical Gaps in This Claim Set
A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.
🔒
3 Critical Gaps in This Claim Set
See the full attorney-level analysis of what this application leaves unprotected — and how to draft it more defensively for your own filings.
No CRM claim filed System claim lacks access controls Traceability not in independent claims
Unlock Full Analysis — Free Frequently asked questions
US 2024/0202221 A1 — key questions answered
Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
Disclaimer: This analysis is generated by PatSnap Eureka AI based on publicly available patent data from the USPTO. It does not constitute legal advice and should not be relied upon as such. Patent data may be subject to change as prosecution progresses. Scores and assessments reflect automated analysis and may not capture all relevant legal or technical nuances. Always consult a qualified patent attorney for formal legal opinions on patentability, freedom to operate, or infringement.
Ask anything about this patent.
PatSnap Eureka searches patents and data to answer instantly.
PatSnap Eureka searches patents and data to answer instantly.
Powered by PatSnap Eureka
Link copied to clipboard