Patent Drafting Analysis of C3.ai’s Enterprise Generative AI Anti-Hallucination Architecture | US 2024/0370709 A1
Patent Drafting Analysis of C3.ai's Enterprise Generative AI Anti-Hallucination Architecture | US 2024/0370709 A1
A structural and strategic analysis of C3.ai's anti-hallucination and attribution patent, examining claim architecture, drafting quality, §101 eligibility risks, dependent claim fallback depth, and prosecution positioning across all 20 claims.
Spec Words
12,400
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
20
System architectures, flowcharts, UI screens
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 74% of total words (~9,200 of ~12,400), providing extensive multi-embodiment coverage across enterprise generative AI system components, agent architectures, and anti-hallucination processing pipelines. The claim set is compact at 20 claims total — 3 independent (Claims 1, 9, and 17) and 17 dependent — yielding a 5.67:1 dependent-to-independent ratio, which sits within the software/AI industry norm. The 20 figure sheets provide broad architectural and flowchart coverage, spanning system block diagrams, UI mockups, and process flowcharts, with strong alignment to the claimed anti-hallucination and attribution pipeline.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 20 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Logical flow diagram of an enterprise generative AI system (100) with anti-hallucination and attribution module (110), showing pipeline from Query (102) through Retriever (104), Context Processor (106), GenAI Model (108), Response Parser (112), AHA Retriever (114), and Response Renderer (116) to Attributed Response (118).Search in Eureka ↗ | Key embodiment |
| FIG. 2 | Parsing and information graph generation process (200) showing extraction of text, code, tables, and images from data records, embedding into vector stores, and construction of an information graph (220) with text chunk nodes (230), code piece nodes (241), table nodes (243), and image nodes (245) linked to aggregator (250).Search in Eureka ↗ | Claim support |
| FIG. 3 | Flowchart (300) of an anti-hallucination and attribution process showing response segmentation based on citation format, source retrieval by similarity, source segmentation, pairwise similarity quantification, corroboration scoring (contradicts/supports/neutral/implies), and score summarization.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Structure diagram (400) of response segments showing the relationships among response segments (402), sources (404), relevancy scores (406), credibility scores (408), source segments (410), relevancy scores for source segments (412), and corroboration scores (414).Search in Eureka ↗ | Claim support |
| FIG. 5 | Enterprise generative AI system architecture diagram (500) showing enterprise systems (504), external systems (506), domain models (508) with connectors (510), data models (512), and persistence (514), embedding models datastore (524), vector stores (526), enterprise generative AI system (502) with large language models (520) and retrieval models (522), and enterprise access control layer (515).Search in Eureka ↗ | System architecture |
| FIG. 6A | Enterprise search graphical user interface (600) showing the underlying architecture layers (NLP component 602, generative pre-trained transformer 604, query layer 606) sitting atop enterprise datastores and applications (608) supporting free text, SQL, NoSQL, image, and video query types.Search in Eureka ↗ | UI/interface |
| FIG. 6B | Enterprise generative AI response graphical user interface (650) showing query input portion (652), AI summary response (654) with highlighted source data portions (668), source identifications (669), response feedback elements (670), and interactive chat portion (656) with follow-up query input (657).Search in Eureka ↗ | UI/interface |
| FIG. 7 | Layered architecture diagram (700) of an enterprise generative AI system showing input layer (702), supervisory layer (710) with language model (706), agent layer (720) with ML insight agent (722), information retrieving agent (724), dashboard agent (726), optimizer agent (728), agent and tool layer (730) with unstructured data retriever (740), structured data retriever (742), type system retriever (744), tools (752), tool and data model layer (750), and external layer (780).Search in Eureka ↗ | System architecture |
| FIG. 8 | Network system diagram (800) showing enterprise generative AI system (802) communicating via a communication network (808) with multiple enterprise systems (804-1 to 804-N) and external systems (806-1 to 806-N).Search in Eureka ↗ | System architecture |
| FIG. 9 | Detailed module diagram (900) of enterprise generative AI system (802) showing all component modules including management (902), orchestrator (904), multiple agent modules (906-1 to 906-10), tool modules (908-1 to 908-14), chunking module (910), embeddings generator (912), crawling module (914), comprehension module (916), enterprise access control (918), AI traceability (920), parallelization (922), model generation/deployment/optimization modules (924-928), interface (930), communication (932), anti-hallucination and attribution module (934), and datastores (940-970).Search in Eureka ↗ | Key embodiment |
| FIG. 10A | Flowchart (1000) of an iterative generative AI process using unstructured data, showing user query (1002) processed through retrieval model (1004) and vector store (1006), fed to large language model (1010), with iterative loop via updated prompts (1008) until query answered or stopping criteria satisfied, outputting answer with rationale (1014).Search in Eureka ↗ | Flow diagram |
| FIG. 10B | Flowchart (1030) of a non-iterative generative AI process showing query (1032) read from datastore (1034), parallel passage extraction (1036) by multiple LLMs (1038), combined extracts (1042) fed with query to final LLM (1044) producing a final response (1046).Search in Eureka ↗ | Flow diagram |
| FIG. 10C | Flowchart (1060) of a non-iterative generative AI process with query rewriting, showing query (1062) rewritten by LLM (1065) using past conversation context (1064) into rewritten query (1066), which drives parallel extract phase and feeds combined extracts with rewritten query to final LLM (1076) for final response (1078) along with rationale (1082).Search in Eureka ↗ | Flow diagram |
| FIG. 11 | Flowchart (1100) of an iterative generative AI process with comprehension module (1106), showing orchestrator (1103), retrieval agent (1104), LLM query and rationale generator (1112), early-stop decision (1107), LLM answer generation (1113), user feedback loop (1116/1118), and historical rationale store (1110).Search in Eureka ↗ | Flow diagram |
| FIG. 12 | Flowchart (1200) of an enterprise generative AI method showing sequential steps: displaying a GUI (1202), receiving a question (1204), retrieving from different enterprise systems (1206), generating an answer by a GenAI model (1208), and displaying the answer (1210).Search in Eureka ↗ | Flow diagram |
| FIG. 13 | Flowchart (1300) of an enterprise generative AI method using agent-orchestrator architecture, showing GUI display (1302), question receipt (1304), orchestrator management of agent programs (1306), retrieval by agent programs (1308), answer generation (1310), and answer display (1312).Search in Eureka ↗ | Flow diagram |
| FIG. 14 | Flowchart (1400) of the anti-hallucination and attribution method, showing receipt of GenAI output (1402), parsing into chunks (1404), retrieving source passages by similarity (1406), attributing passages to chunks based on similarity threshold (1408), combining chunks with attributed source passages (1410), and generating an attributed response with inline source identifiers (1412).Search in Eureka ↗ | Claim support |
| FIG. 15 | Flowchart (1500) of an information retrieval method showing identifying enterprise data sets, AI applications, and data models from different data domains (1502), determining relevance scores based on data models (1504), and determining information using GenAI models based on relevance scores and enterprise access control protocols (1506).Search in Eureka ↗ | Flow diagram |
| FIG. 16 | Flowchart (1600) of an orchestrator routing and validation method showing instructing agent programs (1602), receiving information from multiple data domains (1604), analyzing information to formulate answers with additional retrieval requests to satisfy context validation criteria (1606), and outputting a validated response (1608).Search in Eureka ↗ | Flow diagram |
| FIG. 17 | Computer system diagram (1700) of an example digital device (1702) comprising processor (1704), memory (1706), storage (1708), communicatively coupled via bus (1716) to input device (1710), communication network interface (1712), and output device (1714) connected to communication channel (1718).Search in Eureka ↗ | Other |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The claim set contains exactly 3 independent claims: Claim 1 (method), Claim 9 (system), and Claim 17 (non-transitory computer-readable medium), providing tripartite enforcement coverage across all major claim types. The 17 dependent claims yield a 5.67:1 ratio, which is at the lower bound of the typical software/AI industry norm of 5–8:1, suggesting moderate fallback depth. Notably, Claims 9 and 17 structurally mirror Claim 1 almost verbatim, meaning the dependent claim fallback positions built on Claims 2–8 are partially replicated in the system and CRM branches (Claims 10–16 and 18–20).
Core inventive concept: The claims address the technical problem of hallucination in enterprise generative AI outputs by implementing a post-generation attribution pipeline: Claim 1 recites "parsing the output from a generative model into chunks," then "retrieving the one or more source passages based on a similarity evaluation," then "attributing at least a portion" of source passages "based on a similarity threshold value," and finally "generating a response...including the output with inline source identifiers that identify the attributed source passages" — a verifiable, threshold-gated source-attribution mechanism that operates as a separate module addable to already-deployed AI systems.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method | comprising | receiving output from a generative AI model processing a prompt; parsing output into chunks to be attributed to source passages; retrieving source passages based on similarity evaluation between chunks and source passages; attributing at least a portion of source passages to chunks based on similarity threshold value; combining chunks with attributed source passages; generating a response including the output with inline source identifiers that identify the attributed source passagesSearch prior art ↗ |
| Claim 9 | A system | comprising | one or more processors; memory storing instructions that, when executed, cause the system to perform: receiving GenAI model output; parsing output into chunks; retrieving source passages by similarity evaluation; attributing source passages to chunks based on similarity threshold; combining chunks with attributed source passages; generating response with inline source identifiersSearch prior art ↗ |
| Claim 17 | A non-transitory computer readable medium | comprising | instructions that, when executed, cause one or more processors to perform: receiving GenAI model output; parsing output into chunks; retrieving source passages by similarity evaluation; attributing source passages to chunks based on similarity threshold; combining chunks with attributed source passages; generating response with inline source identifiersSearch prior art ↗ |
Claim Dependency Tree
1 Method: receive GenAI output → parse into chunks → retrieve source passages by similarity → attribute by threshold → combine → generate response with inline source IDsSearch Claim 1 prior art ↗
2 Adds: generative AI model type — adversarial network, variational autoencoder, autoregressive model, or recurrent neural networkSearch in Eureka ↗
3 Adds: output includes sentences and chunks include one or more of the sentencesSearch in Eureka ↗
4 Adds: similarity evaluation calculates similarity scores associated with chunks and source passagesSearch in Eureka ↗
5 Adds: response is generated by a generative AI modelSearch in Eureka ↗
6 Further: (dep. on Claim 4) filtering source passages based on similarity scoresSearch in Eureka ↗
7 Further: (dep. on Claim 6) generating an information graph for each data record, describing relationships between source passages and other classes including images, tables, source codeSearch in Eureka ↗
8 Further: (dep. on Claim 7) retrieving source passages based on the information graphSearch in Eureka ↗
9 System: one or more processors + memory instructions performing same core pipeline as Claim 1Search Claim 9 prior art ↗
10 Adds: GenAI model type (adversarial network, VAE, autoregressive, or recurrent)Search in Eureka ↗
11 Adds: output includes sentences and chunks include one or more sentencesSearch in Eureka ↗
12 Adds: similarity evaluation calculates similarity scores for chunks and source passagesSearch in Eureka ↗
13 Adds: response is generated by a generative AI modelSearch in Eureka ↗
14 Further: (dep. on Claim 12) filtering source passages based on similarity scoresSearch in Eureka ↗
15 Further: (dep. on Claim 14) generating an information graph per data recordSearch in Eureka ↗
16 Further: (dep. on Claim 15) retrieving source passages based on information graphSearch in Eureka ↗
17 Non-transitory CRM: instructions causing processor to perform same pipeline as Claim 1Search Claim 17 prior art ↗
18 Adds: GenAI model type (adversarial network, VAE, autoregressive, or recurrent)Search in Eureka ↗
19 Adds: output includes sentences and chunks include one or more sentencesSearch in Eureka ↗
20 Adds: similarity evaluation calculates similarity scores for chunks and source passagesSearch in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 20 | 15 – 25 |
| Independent claim count | 3 | 1 – 4 |
| Dependent : Independent ratio | 5.67 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| System / apparatus claims? | Yes — Claim 9 | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The anti-hallucination and attribution architecture benefits from strong tripartite claim coverage (method, system, CRM) and extensive figure support for all core pipeline steps (FIG. 1, FIG. 14) that directly map to Claim 1's limitations. However, the near-verbatim mirroring of Claim 1's body across independent Claims 9 and 17 means the dependent claim set provides mostly redundant fallback positions rather than genuinely differentiated technical alternatives, creating a structural vulnerability if Claim 1's body is narrowed during examination.
✅
Antecedent Basis
Antecedent basis is clean throughout the 20 claims. Claim 1 introduces "chunks" in the parsing step and properly refers to "the chunks" and "the one or more source passages" in all subsequent limitations. Dependent Claims 4, 6, 12, and 14 correctly refer back to "the similarity evaluation" and "the similarity scores" introduced by their parent claims. No orphaned definite article references were identified across the full claim set.
✅
Spec–Claim Consistency
FIG. 14 and paragraphs [0227]–[0233] provide direct, step-by-step written description support for every limitation of Claim 1: parsing output into chunks (¶[0228], step 1404), retrieving source passages by similarity (¶[0229], step 1406), attributing based on similarity threshold (¶[0231], step 1408), combining chunks with source passages (¶[0232], step 1410), and generating response with inline source identifiers (¶[0233], step 1412). The information graph limitation of Claims 7, 8, 15, 16 is supported by FIG. 2 and ¶[0048]–[0060].
✅
Transition Word Usage
All three independent claims (Claims 1, 9, 17) use "comprising," which is maximally open-ended and strategically appropriate — it allows the claims to read on implementations that include additional steps or components not recited. No "consisting of" or "consisting essentially of" language appears anywhere in the claim set, and none is needed given the open-ended nature of AI pipeline architectures. This transition word choice cannot be challenged for over-narrowing.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in any claim. The system claim (Claim 9) uses structural language — "one or more processors" and "memory storing instructions" — rather than means-plus-function formatting, which avoids §112(f) invocation. All functional language in the claims ("parsing," "retrieving," "attributing," "generating") is presented as active method steps or processor-executed instructions with corresponding structural disclosure, not as "means" elements requiring claim narrowing to the specification's disclosed structures.
⚠️
§101 Eligibility Risk
Claim 1 recites a method that is substantially abstract — receiving GenAI output, parsing, similarity retrieval, and attributing — all of which could be characterized under Alice Step 1 as abstract data manipulation. The §101 defense rests primarily on the system claim's hardware recitation ("one or more processors" and "memory" in Claim 9) and the CRM format of Claim 17, but the method Claim 1 itself lacks explicit hardware ties. The inline source identifier output and similarity threshold limitation provide some functional specificity, but an examiner may contend these are conventional computational steps applied to the abstract idea of attribution, and C3.ai would need to argue the technical solution framing of improving AI system reliability rather than performing a mental process.
⚠️
Dependent Claim Fallback Quality
The 17 dependent claims are structurally redundant across three independent claim tracks: Claims 2–8 mirror Claims 10–16 and Claims 18–20 almost identically, providing no genuinely new fallback positions per track. Claims 7, 8, 15, and 16 (information graph generation and graph-based retrieval) represent the strongest unique fallback positions, adding a substantive technical limitation absent from the independent claims. However, Claims 2, 10, 18 (GenAI model type alternatives) and Claims 3, 11, 19 (sentence-level chunking) are very minor and provide thin differentiation from the parent claims, offering limited prosecution or litigation fallback value.
⚠️
Abstract Quality
The abstract describes the anti-hallucination architecture as increasing "accuracy and reliability" of generative AI by "detecting, preventing, and mitigating hallucination" and notes it can be added as "a separate tool or module" to deployed systems — which accurately characterizes the commercial positioning but omits the specific technical mechanism that defines the claims: the similarity-threshold-gated post-generation chunk attribution pipeline with inline source identifiers. An examiner reading only the abstract would likely classify this under generic RAG-based AI improvement rather than the specific novel attribution verification mechanism, potentially leading to overly broad prior art citations in a first office action.
✅
Figure Support Quality
Figure support is comprehensive and well-aligned with the claimed pipeline. FIG. 14 maps directly and completely to Claim 1's six-step structure (steps 1402–1412 = each limitation). FIG. 2 supports the information graph limitation in Claims 7, 8, 15, 16. FIG. 4 supports the similarity score and credibility score structures referenced in the dependent claims. FIG. 17 supports the hardware recitations in Claim 9 (processor 1704, memory 1706, storage 1708). No claim limitation was identified that lacks corresponding figure support in the 20-sheet figure set.
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.5
Dependent Claim Coverage
2.8
Claim Type Diversity
4.8
Figure Support Quality
4.5
Key observation: Claim Type Diversity (Score 4.8/5.0) is the strongest dimension — the tripartite method/system/CRM structure across Claims 1, 9, and 17 provides enforcement coverage in all standard software patent formats, leaving no obvious claim-type design-around opportunity. The weakest dimension is Dependent Claim Coverage (Score 2.8/5.0), because the 17 dependent claims are structurally partitioned into three near-identical tracks mirroring Claims 1, 9, and 17 respectively — meaning 15 of 17 dependent claims add no limitations not already present in an identical form in another track, severely limiting independent fallback depth during prosecution. Practitioners should consider filing a continuation with substantively differentiated dependent claims adding unique technical elements — such as corroboration scoring (FIG. 3, FIG. 4) and enterprise access control integration (FIG. 5) — which are well-supported in the specification but absent from the claims.
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.
Corroboration scoring entirely unclaimed Access control integration missing from claims No multi-agent orchestrator attribution claim
Unlock Full Analysis — Free Frequently asked questions
US 2024/0370709 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