Patent Drafting Analysis of Cure AI, LLC’s AI Query Refinement and Vector Database Search System | US 11,971,914 B1
Patent Drafting Analysis of Cure AI, LLC's AI Query Refinement and Vector Database Search System | US 11,971,914 B1
A structural and strategic analysis of US 11,971,914 B1 examining claim architecture, drafting quality, §101 eligibility risk, dependent claim coverage, and prosecution positioning for Cure AI's LLM-based medical query system.
Spec Words
7,200
Across 5 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
17
System architecture, flow diagrams, prompt examples, performance data
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 54% of total words (~3,900 of ~7,200), with the claims section representing a substantial ~27%, indicating the drafters invested heavily in claim language relative to background disclosure. The patent fields 20 total claims — 3 independent and 17 dependent — providing a 5.67:1 dependent-to-independent ratio that offers moderate fallback layering across method, CRM, and search-method claim types. Seventeen drawing sheets cover the full system architecture, operational flowcharts, example prompt objects, and comparative performance data, providing broad — though architecturally high-level — visual support for the disclosed embodiments.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 17 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | System-level block diagram showing processor (120), CRSM program (200), database (130), vector database (140), data source (150), and user interface (160) of the AI network 100.Search in Eureka ↗ | System architecture |
| FIG. 2 | CRSM program 200 module decomposition showing data scraper (211), data processing (212), embedder (213), database generator (214), user interface (215), and query response (216) modules.Search in Eureka ↗ | Key embodiment |
| FIG. 3A | High-level operational schematic (operation 220) showing three sequential steps: get data from data sources (222), generate vector embeddings (224), and populate vector database (226).Search in Eureka ↗ | Flow diagram |
| FIG. 3B | Query-response operational schematic (operation 260) illustrating: receive user query (262), refine query (272), generate refined query embedding (274), apply to vector database (276), return top K vectors (278), apply prompts and generate answer (280), return response to user (282).Search in Eureka ↗ | Claim support |
| FIG. 4A | Example PubMed article 290 with Article ID 291 and its corresponding vector embedding 292 showing floating-point numerical representation with 1536 dimensions.Search in Eureka ↗ | Key embodiment |
| FIG. 4B | Example user query 293 and corresponding query refiner prompts — system prompt 295 and user prompt 296 — illustrating dual-prompt query refinement mechanism with placeholder {QUESTION}.Search in Eureka ↗ | Claim support |
| FIG. 4C | Cure AI identity system prompt 297 and Cure AI user prompt 298 with context placeholder 298A and query placeholder 294A, illustrating the static system prompt and dynamic user prompt structure.Search in Eureka ↗ | Claim support |
| FIG. 5 | Top-level routine overview showing two sub-routines: vector database generation (300) and query intake and response (400) as executed by the computer program of FIG. 2.Search in Eureka ↗ | Flow diagram |
| FIG. 6 | Detailed system data-flow diagram showing PubMed content (301) → embedding model (302) → vector embeddings (303) → vector database (305) and query application (401) → query (405) → vector database (305) → top K vectors (407) → response (409).Search in Eureka ↗ | System architecture |
| FIG. 7 | Vector database generation routine 300 flowchart showing: scrape data (310), process scraped data and save (330), generate embeddings and save (340), generate vector database (350), and end (390).Search in Eureka ↗ | Flow diagram |
| FIG. 8 | Detailed PubMed data scraping operation 310A showing: set up PubMed request (312), connect to external data source (314), parse XML response (316), error check (318), and acquire first XML element (320).Search in Eureka ↗ | Flow diagram |
| FIG. 9 | Article data processing operation 330A showing iterative fetch-and-parse loop using PubMed ID (331), XML parsing error check (333), parse article data (335), store in batch (337), last-article check (339), and store new article to CSV (341).Search in Eureka ↗ | Flow diagram |
| FIG. 10 | Embedding generation operation 350A showing: read CSV (352), process data frame in chunks (354), combine title and abstract (356), calculate tokens (358), token-limit check (360), skip article if over limit (362), generate embeddings (364), add to DB (366), chunk completion check (368), and save embeddings to CSV (369).Search in Eureka ↗ | Flow diagram |
| FIG. 11 | Vector database population operation 370A showing: connect to vector database (371), gather embedding pairs (373), segment pairs into chunks (375), upsert to vector database in batches (377), and end (390).Search in Eureka ↗ | Flow diagram |
| FIG. 12 | Query intake and response routine 400 showing: receive query and initiate session (410), refine user query (420), apply refined query and prompts (430), determine top K vectors (440), retrieve articles and generate comprehensive answer (450), return response with answer, query, and refined query (460), and end (470).Search in Eureka ↗ | Claim support |
| FIG. 13A | Performance comparison table showing Cure AI response 510 with PubMed-cited answer 515 for question 502 about ondansetron QT interval prolongation, demonstrating 100% verifiable reference rate.Search in Eureka ↗ | Other |
| FIG. 13B | Performance comparison showing ChatGPT response 520 with generic web-sourced references 525 for the same question 502, illustrating hallucination risk with unverifiable references (32% verifiable vs. 100% for Cure AI).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 patent presents 3 independent claims — Claim 1 (AI method), Claim 10 (non-transitory CRM), and Claim 18 (AI-based search method) — providing a tripartite enforcement structure covering method, storage medium, and search-method claim types. The 17 dependent claims against 3 independent claims yields a 5.67:1 ratio, which is near the lower end of the 4–8:1 norm typical for software/AI patents in the G06F classification, offering moderate but not exceptional fallback coverage. The claim strategy notably ties the response-generation limitation to a specific dual-refiner structure (system query refiner + user query refiner applied to a large language model), which focuses the inventive distinction but also creates design-around vectors through alternative query enrichment techniques.
Core inventive concept: The claims address the hallucination problem in large language model (LLM) responses by requiring a processor to perform dual-prompt query refinement — applying both a "system query refiner" and a "user query refiner" to the original query before generating a vector embedding — then identifying the top-K most similar vectors in a curated vector database and instructing the LLM to generate a response constrained exclusively to those retrieved documents. The response must comprise "a text document, generated by execution of the large language model, as a comprehensive answer to the original query," with the refined query including a persona, instruction set, and conditions limiting the LLM's output to verifiable source material.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | An artificial intelligence (AI) method | comprising | processor receiving original query on external database; processor generating embedding of original query; processor performing transformations via system query refiner and user query refiner applied to LLM to produce refined query; processor applying embedding to vector database via similarity routine to identify discrete vectors; collecting most similar vectors; instructing LLM to apply vectors, refined query, system prompt, and user prompt to external database to generate text-document response as comprehensive answerSearch prior art ↗ |
| Claim 10 | A non-transitory, computer-readable storage medium having encoded thereon machine instructions that when executed by a processor, cause the processor to | comprising | receive original query on external database; generate embedding of original query; perform transformations via system and user query refiners applied to LLM to produce refined query; apply embedding to vector database via similarity routine; collect most similar vectors; instruct LLM to apply vectors, refined query comprising original query, improved detailed system prompt, and refined detailed user prompt to external database to generate comprehensive text-document responseSearch prior art ↗ |
| Claim 18 | An artificial intelligence-based search method for searching content of a big data source storing text and image-based technical articles | comprising | processor generating searchable vector database comprising vector representations and paired unique identification numbers of data objects in big data source; executing search directed to specific technical subjects comprising: receiving original user query, generating refined query via system and user query refiners applied to LLM, generating embedding, applying embedding to vector database, determining similarity, returning top-K vector representations with paired unique IDs as index, generating query response instructing LLM to apply vectors, refined query, system prompt, and user prompt to big data sourceSearch prior art ↗ |
Claim Dependency Tree
1 AI method: processor receives query, generates embedding, applies dual-refiner to LLM, similarity-searches vector DB, instructs LLM to respondSearch Claim 1 prior art ↗
2 Adds: large language model is a ChatGPT modelSearch in Eureka ↗
3 Adds: processor identifies one or more top K vectors, wherein K is a parameter with a value determined by the processorSearch in Eureka ↗
4 Adds: refined detailed user prompt comprises a search contextSearch in Eureka ↗
5 Adds: instructing large language model not to make up informationSearch in Eureka ↗
6 Adds: similarity routine is a cosine similarity routineSearch in Eureka ↗
7 Adds: improved detailed system prompt is staticSearch in Eureka ↗
8 Adds: large language model is a chat bot modelSearch in Eureka ↗
9 Adds: refined query includes a persona/role for the LLM, set of instructions to return unique IDs, and conditions/limitations; each similar vector is paired to unique ID; LLM uses IDs as index to external database and retrieves documents for comprehensive answerSearch in Eureka ↗
10 CRM claim: machine instructions cause processor to perform full query-refinement, vector-similarity search, and LLM-constrained response generationSearch Claim 10 prior art ↗
11 Adds: large language model is a ChatGPT modelSearch in Eureka ↗
12 Adds: processor identifies one or more top K vectors, K is a parameter with value determined by the processorSearch in Eureka ↗
13 Adds: refined detailed user prompt is dynamic and comprises a search contextSearch in Eureka ↗
14 Adds: limitations instruct large language model not to make up informationSearch in Eureka ↗
15 Adds: similarity routine is a cosine similarity routineSearch in Eureka ↗
16 Adds: improved detailed system prompt is static and provides an identity and role for the large language modelSearch in Eureka ↗
17 Adds: each similar vector is paired to a unique ID; LLM uses IDs as index to external database and retrieves documents via index for comprehensive answerSearch in Eureka ↗
18 AI-based search method: processor generates searchable vector DB with paired unique IDs; executes search via dual-refiner, embedding, similarity, top-K retrieval, and LLM response generationSearch Claim 18 prior art ↗
19 Adds: refined detailed user prompt comprises search context constraining LLM to index-only documents; improved detailed system prompt provides a role/persona for the LLMSearch in Eureka ↗
20 Adds: role is stated as a persona for the LLM, with instruction set to return unique IDs of big data source objects, and conditions/limitations; each similar vector representation paired to unique ID; LLM uses IDs as index to big data source and retrieves documents for comprehensive answerSearch in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 20 | 15 – 25 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.67 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| System / apparatus claims? | Yes — Claim 10 | 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 feature is the deliberate structural limitation of the LLM's response generation to only retrieved vector-indexed documents — as recited in Claims 5, 9, 14, and 17 — creating a meaningful technical distinction from prior-art hallucination-prone LLM systems. However, the independent claims carry significant §101 Alice exposure because the preamble language of Claim 1 ('a processor receiving... a query') does not itself recite structurally novel hardware, and the claimed query-refinement steps could be characterised as abstract mental processes implemented on a generic processor.
✅
Antecedent Basis
The antecedent basis is generally clean throughout the 20 claims. Claim 1 introduces "a processor," "the processor" is consistently used thereafter. "The embedding," "the refined query," "the vector database," and "the one or more most similar vectors" all have clear antecedents from their first introduction in Claim 1. In Claim 10 (CRM), "the processor" has proper antecedent in the preamble "executed by a processor." No "the [element]" references appear without prior introduction in the reviewed claim set.
✅
Spec–Claim Consistency
The key independent claim limitations map well to disclosed figures and paragraphs. The dual-refiner structure (system query refiner + user query refiner) recited in Claim 1 is directly illustrated in FIG. 4B (query refiner system prompt 295, user prompt 296) and described in the detailed description referencing queryRefiner() function. The vector similarity search limitation maps to FIG. 3B (steps 276-278) and FIG. 6 (blocks 405-407). The "not make up information" constraint of dependent Claim 5 maps to FIG. 4C (prompt 298 instructions). No claim limitation was identified as lacking specification support.
✅
Transition Word Usage
All independent claims and dependent claims uniformly use "comprising" as the transition, which is the strategically appropriate open-ended choice for AI method and system claims — it avoids limiting the claims to only the recited steps and allows for additional method steps (e.g., logging, session management) without foreclosing coverage. No use of "consisting of" or "consisting essentially of" was observed, which is correct for this technology domain. No missed opportunities for "comprising" were identified; the dependent claims appropriately use "wherein" for limiting qualifications.
⚠️
§112(f) Means-Plus-Function Risk
No literal "means for" language appears in the claims. However, Claims 1 and 10 recite "a system query refiner" and "a user query refiner" as functional labels without structural definition in the claim body — these could be construed as nonce terms under §112(f) if a court finds that "refiner" has no understood structural meaning in the art. The specification provides some structural definition (a set of system instructions / a set of user instructions), but the claim language itself leaves the structural scope ambiguous. A stronger filing would have recited these explicitly as "a set of system instructions" and "a set of user instructions" directly in the independent claim, not merely in the dependent claims (Claims 9 and 17).
⚠️
§101 Eligibility Risk
Claim 1's Alice exposure is substantial: the preamble recites only "a processor receiving... a query on an external database" — a generic computing element — and all substantive limitations (generating an embedding, performing transformations, applying similarity routines) are framed as functional data-manipulation steps that an examiner could characterise as abstract ideas applied to a generic processor. The primary §101 defense is the specific vector-database similarity routine and the constrained LLM response mechanism (responses limited to retrieved documents only), which together constitute an improvement in AI system reliability. However, the lack of hardware-specific limitations in the preamble and the broadly functional claim language make a Step 2A, Prong 2 "significantly more" argument dependent on the examiner accepting that the dual-refiner architecture is itself a technical improvement — an argument that required the examiner's citation of the GPT-4 chatbot reference suggests was contested.
✅
Dependent Claim Fallback Quality
The dependent claims provide layered fallback positions of meaningfully varying specificity. Claims 5 and 14 ("instructing the large language model not to make up information") and Claims 9 and 17 (fully specifying the persona-role, unique-ID-return instruction set, and conditions on the LLM) represent the strongest fallback positions because they directly address the hallucination-prevention core of the invention. Claims 2 and 11 ("LLM is ChatGPT") are weak fallback positions that narrow to a commercial product and could be easily designed around. Claims 6 and 15 (cosine similarity) add a specific algorithmic limitation with clear prior-art differentiation value.
⚠️
Abstract Quality
An examiner reading only the abstract may correctly identify the core claim concept — the abstract accurately describes the query refinement, embedding generation, vector similarity search, and LLM application steps. However, the abstract omits the hallucination-prevention mechanism that constitutes the key inventive distinction: it does not state that the LLM's response is constrained exclusively to retrieved documents. The abstract describes "comprehensive response" generation but does not explain that the response is constrained to only verifiable, indexed material — the critical technical improvement over prior ChatGPT systems that drove grant.
✅
Figure Support Quality
Figure coverage is comprehensive for the major claim limitations. FIG. 4B directly supports the dual system/user refiner limitation in Claims 1, 10, and 18. FIG. 3B and FIG. 12 support the query-receive, refine, embed, similarity-search, and response-return method steps. FIG. 6 provides an integrated data-flow diagram supporting the vector database generation and query-response interplay. The one area of weaker figure support is the "unique identification number" pairing of Claims 9, 17, and 20 — while FIG. 4A shows a PubMed article and its embedding, no figure explicitly shows the vector-to-PMID pairing structure relied upon by these claims.
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
2.8
Prosecution Defensibility
3
Spec–Claim Consistency
3.8
Dependent Claim Coverage
3.5
Claim Type Diversity
4
Figure Support Quality
3.5
Key observation: Claim Type Diversity scores highest (4.0/5.0) because the three independent claims span method (Claim 1), CRM (Claim 10), and AI-based search method (Claim 18) — a structurally complete coverage set that forecloses the most obvious design-around routes. Claim Breadth scores lowest (2.8/5.0) because Claims 1 and 10 require both a "system query refiner" and a "user query refiner" as separate named elements in the same claim, meaning any competitor who applies only a single unified prompt-refinement step would fall outside the literal scope, creating a readily exploitable design-around path. Practitioners should consider whether a continuation filing with a single-refiner independent claim, supported by the same specification, would capture the broader inventive concept.
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.
Dual-refiner requirement limits breadth No system apparatus claim filed External database undefined in claim scope
Unlock Full Analysis — Free Frequently asked questions
US 11,971,914 B1 — 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