Patent Drafting Analysis of Unlikely Artificial Intelligence Limited’s LLM Fact-Checking & Data Analysis Methods | US 12,073,180 B2
Patent Drafting Analysis of Unlikely Artificial Intelligence's LLM Fact-Checking & Universal Language Patent | US 12,073,180 B2
A structural and strategic analysis of US 12,073,180 B2, covering claim architecture, drafting quality signals, §101 eligibility risk, dependent claim fallback strength, and prosecution positioning for this AI/LLM data-processing patent.
Spec Words
52,000
Across 6 sections
Draft now ↗
Total Claims
30
1 independent · 29 dependent
Draft now ↗
Figure Sheets
11
UI screens, system architecture, flow diagrams, semantic graphs
Draft now ↗
Published by PatSnap Insights Team · · 14 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 87% of total words (~46,000 of ~52,000), reflecting an unusually broad disclosure strategy covering 13+ application domains (recruitment, health, voice assistants, accounting, and more). The claim set is architecturally narrow: only 1 independent claim (Claim 1) with 29 dependent claims, yielding a 29:1 dependent-to-independent ratio that concentrates all infringement risk on a single method claim. The 11 figure sheets span UI prototypes (FIGS. 1–7), system architecture diagrams (FIGS. 8–9), process flow (FIG. 10), and semantic graph representation (FIG. 11), providing moderate but not comprehensive structural claim support.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 11 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Mobile phone lock screen notification from the 'Jobe' recruitment application showing a push alert for a new candidate match for a Junior Engineer role.Search in Eureka ↗ | UI/interface |
| FIG. 2 | Mobile app screen from 'Jobe' showing a detailed candidate match profile with structured reasoning explaining how each job requirement is satisfied, including C++ experience, Portuguese fluency, and commuting distance.Search in Eureka ↗ | Key embodiment |
| FIG. 3 | Mobile chat interface showing a conversation with the 'Chea' health application where a user shares food photos and nutritional data is communicated and recorded.Search in Eureka ↗ | UI/interface |
| FIG. 4 | Mobile insights screen from the 'Chea' health app showing automatically generated insights about sulphite intolerance and improved sleep quality correlated with earlier eating times.Search in Eureka ↗ | Key embodiment |
| FIG. 5 | Calorie graph screen showing daily calories in versus calories out plotted weekly with error bars, demonstrating the horizontal health application's data visualization capability.Search in Eureka ↗ | UI/interface |
| FIG. 6 | Sleep quality graph showing correlation between estimated caffeine in the user's body at bedtime and sleep quality score, illustrating data-driven health insight generation.Search in Eureka ↗ | UI/interface |
| FIG. 7 | Two-panel figure showing (a) a simplified explanation and (b) a detailed step-by-step logical explanation for why a candidate's 7 years of C++ experience satisfies 'at least 5 years in an object-oriented language.'Search in Eureka ↗ | Claim support |
| FIG. 8 | Full system architecture diagram of the 'Brian' voice assistant product showing the UL Platform, Passage Stores (long-term memory, brain tenets, reasoning memory, knowledge), External Events Processing, Thinking, Decision, and Execution sub-components with data flow arrows.Search in Eureka ↗ | System architecture |
| FIG. 9 | Abstract contemplation loop diagram showing the core cycle of Events (UL), contemplation, short-term memory, tenets, long-term memory, and actions, as an alternative high-level representation of FIG. 8.Search in Eureka ↗ | Flow diagram |
| FIG. 10 | Three-step process flow diagram showing the core LLM-plus-processing-system pipeline: LLM generates continuation output, the output is provided to a structured machine-readable processing system, and the system analyzes it to produce an improved version for the user.Search in Eureka ↗ | Claim support |
| FIG. 11 | Intermediate representation semantic graph illustrating how the sentence 'Aurora graduated with a master's degree in engineering from Crescent School in Singapore' is parsed into a hierarchical UL/semantic graph structure with labeled nodes and edges.Search in Eureka ↗ | Claim support |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent contains exactly 1 independent claim (Claim 1, a computer-implemented method) and 29 dependent claims, yielding an exceptional 29:1 dependent-to-independent ratio, which is far above the software/AI norm of 4–8:1 and concentrates the entire patent's enforcement value on a single method pathway. This architecture is a deliberate strategy by Unlikely AI to build deep fallback layers around a core LLM fact-checking method rather than diversifying into apparatus or CRM claim types, leaving significant coverage gaps. The absence of a separate system claim or computer-readable medium claim is a notable strategic choice that creates design-around opportunities.
Core inventive concept: The patent solves the problem of LLM hallucination and factual inaccuracy by interposing a structured, machine-readable processing system — using semantic nodes and semantic links that are themselves semantic nodes — between the LLM's first output and the user, so that the processing system can 'fact-check' the LLM output using reasoning steps and computation units and generate a 'second output' that is a fact-checked, improved version of the first. Claim 1 requires specifically that the LLM's 'first output' is 'represented in the machine-readable language,' that 'reasoning steps are represented in the machine-readable language,' and that 'computation units are represented in the machine-readable language,' with the processing system generating a fact-checked 'second output to a user.'
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A computer-implemented method of fact-checking the output of a large language model (LLM) | including the steps of | (a) LLM processing first input data to generate first output; (b) processing system using structured machine-readable representation conforming to machine-readable language with semantic nodes including semantic links that are themselves semantic nodes, each node denoting one specific meaning, combination of nodes defines a semantic node, expressions nestable, first output represented in machine-readable language, reasoning steps represented in machine-readable language, computation units represented in machine-readable language; (c) providing first output to processing system; (d) processing system analyzing first output to fact-check using reasoning steps, computation units, and semantic nodes, generating fact-checked second output and providing it to a userSearch prior art ↗ |
Claim Dependency Tree
1 Computer-implemented method of fact-checking LLM output using a structured machine-readable processing system to generate a fact-checked second outputSearch Claim 1 prior art ↗
2 Adds: processing system translates one or more factual assertions in the first output into machine-readable language and fact-checks the translated assertionsSearch in Eureka ↗
3 Adds: fact-checking translated assertions by analysing for factual inaccuraciesSearch in Eureka ↗
4 Adds: fact-checking translated assertions by analysing for contradictionsSearch in Eureka ↗
5 Further: improved fact-checked version of first output provided to user by the processing systemSearch in Eureka ↗
6 Further: improved fact-checked version of first output provided to user by the LLMSearch in Eureka ↗
7 Further: improved fact-checked version provided to user by a combination of processing system and LLMSearch in Eureka ↗
8 Adds: classifier operates to identify when first input data is likely to result in output where accuracy is important and uses processing system accordinglySearch in Eureka ↗
9 Adds: processing system translates at least some of the first output into machine-readable representation to analyse the translated first outputSearch in Eureka ↗
10 Further: processing system analyses translated first output for factual inaccuracies, contradictions and scope, provides corrected output for generating continuation outputSearch in Eureka ↗
11 Adds: processing system analyses internal logical self-consistency of first output and provides self-consistent output as updated prompt to LLMSearch in Eureka ↗
12 Adds: processing system analyses correspondence of first output to how people understand the real world or reason, provides reasoned output as updated promptSearch in Eureka ↗
13 Adds: processing system analyses first output for bias and provides bias-free output as updated prompt to LLMSearch in Eureka ↗
14 Adds: processing system analyses first output for absence of relevant dynamic or real-time information and provides missing information as updated prompt to LLMSearch in Eureka ↗
15 Adds: processing system analyses first output for reasoned text and provides improved reasoned text as updated prompt to LLMSearch in Eureka ↗
16 Adds: LLM is answering a question and processing system analyses the answer to provide an improved answer as updated promptSearch in Eureka ↗
17 Adds: first output from LLM is a partial continuation (output made before LLM stopped or whilst still generating)Search in Eureka ↗
18 Adds: method improves one or more parameters of first output including accuracy, factual scope, logical self-consistency, correspondence to real world, bias, dynamic/real-time information, reasoned textSearch in Eureka ↗
19 Adds: method improves level of formality, brevity, suitability for text-to-speech, style language, certainty of first outputSearch in Eureka ↗
20 Adds: LLM is a generative AI based systemSearch in Eureka ↗
21 Adds: LLM is an autoregressive language modelSearch in Eureka ↗
22 Further: LLM is an autoregressive language model which is a Generative Pre-trained TransformerSearch in Eureka ↗
23 Adds: method used for program code generation, solving natural language-described problems, poetry/lyrics/creative writing, essays, knowledge summaries, question answering, internet searchSearch in Eureka ↗
24 Adds: identifying first output content that breaches predefined policies by translating into machine-readable language and checking against policies before displaying to userSearch in Eureka ↗
25 Adds: method of validating natural language for factual accuracy comprising extracting factual assertions, checking for accuracy, outputting resultsSearch in Eureka ↗
26 Further: checking factual assertions by providing reasoning system with symbolic world representation, translating assertions, identifying true or falseSearch in Eureka ↗
27 Further (from 26): reasoning system uses a universal languageSearch in Eureka ↗
28 Further (from 25): checking assertions comprises translating them to yes/no questions corresponding to truth of assertions and answering those questionsSearch in Eureka ↗
29 Further (from 25): sources of known knowledge used to validate a factual assertion as false are returned as part of the checking processSearch in Eureka ↗
30 Further (from 25): checking factual assertions comprises generating an explanationSearch in Eureka ↗
| Metric | This Application | Software / AI Industry Norm |
|---|---|---|
| Total claims | 30 | 15 – 25 |
| Independent claim count | 1 | 2 – 4 |
| Dependent : Independent ratio | 29.0 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Always |
| System / apparatus claims? | No | 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 quality is the depth and internal consistency of its semantic node language definition — the specification exhaustively defines UL (universal language), semantic nodes, passages, reasoning steps, and computation units in a manner that robustly supports the highly technical claim language in Claim 1's step (b). However, the patent's most serious drafting weakness is the complete absence of system/apparatus and computer-readable medium independent claims, leaving a large enforcement gap that a competitor could exploit by implementing the same fact-checking pipeline in a hardware device or software product without directly performing the claimed 'method.'
✅
Antecedent Basis
Claim 1's claim body establishes all necessary antecedents cleanly: 'first input data' is introduced in step (a) before 'the first input data' is referenced, 'first output' is established in step (a) before reuse in steps (b)–(d), and 'the processing system' introduced in step (b) is consistently referenced thereafter. Dependent Claims 2–30 all reference 'the processing system,' 'the first output,' and 'the LLM' with proper antecedent basis from Claim 1. No dangling 'the' references were found across the full 30-claim set.
✅
Spec–Claim Consistency
The highly specific language in Claim 1 step (b) — 'semantic links are themselves semantic nodes,' 'each semantic node denotes one specific meaning,' 'combination of semantic nodes defines a semantic node,' 'expressions in the machine-readable language are nestable' — maps directly to the Detailed Description's 'Semantic Nodes' section (pages 15–20 of the spec) and is visually supported by FIG. 11's semantic graph. FIG. 10 directly supports the step (d) 'analyzing the first output to fact-check' limitation. However, the 'computation units' limitation in step (b) is supported primarily by the written description (pages 22–24) with no dedicated figure, creating a minor but manageable gap.
✅
Transition Word Usage
Claim 1 uses 'including the steps of' as its transition, which functions identically to 'comprising' in U.S. patent practice and is open-ended, appropriately allowing for additional method steps not recited in the claim. All 29 dependent claims use language consistent with this open transition. There is no use of 'consisting of' or 'consisting essentially of' anywhere in the claim set, which is strategically correct for a software/AI method patent where competitors may add steps around the core pipeline. No transition word weaknesses were identified.
⚠️
§112(f) Means-Plus-Function Risk
A potential §112(f) exposure exists in Claim 1's step (b) recitation of 'computation units are represented in the machine-readable language' — 'computation units' is a coined functional term that could be construed as a nonce word invoking §112(f) if an examiner or court determines it lacks structural definition. The specification does define 'computation units' extensively (pages 22–24 of spec), providing Java location identifiers and lua script examples as corresponding structure, which is the best available defense. However, the absence of a definitional anchor in the claim itself ('computation units, wherein each computation unit comprises...') means the §112(f) argument remains available to a challenger in inter partes review.
⚠️
§101 Eligibility Risk
Claim 1 faces meaningful Alice exposure: at its broadest, the claim recites an abstract idea (fact-checking information using a system of rules and reasoning) implemented using a 'processing system' and 'machine-readable language.' The §101 defense rests on the structural specificity of step (b)'s semantic node architecture — particularly that 'semantic links are themselves semantic nodes' and that 'expressions in the machine-readable language are nestable' — which the specification argues produces a concrete technical effect (faster processing, simplified storage, reduced response times, pages 11–12 of spec). This technical-character argument is present but not bulletproof; an examiner in Art Unit 2100 may still characterize the core as an abstract mathematical/logical concept, and the hardware tie-in is functional rather than structural throughout the claims.
✅
Dependent Claim Fallback Quality
The 29 dependent claims provide genuinely layered and distinct fallback positions: Claims 2–4 add the translation-and-assertion-checking sub-mechanism; Claims 5–7 distinguish who delivers the improved output (processing system vs. LLM vs. combination); Claims 8 and 24 add classifier-based accuracy triggering and policy-compliance checking; Claims 11–16 each add distinct analysis dimensions (logical self-consistency, real-world correspondence, bias reduction, real-time information, reasoned text, Q&A mode). Claims 25–30 form a self-contained sub-cluster on natural language factual validation. The weakest fallbacks are Claims 20–22 (merely specifying LLM type: generative AI, autoregressive, GPT), which add minimal patentable distinction.
⚠️
Abstract Quality
An examiner reading only the abstract would accurately identify the general subject matter — interacting with an LLM using a structured, machine-readable universal language — but would miss the specific novel contribution of Claim 1: the fact-checking pipeline where LLM output is analyzed by a processing system whose semantic nodes, reasoning steps, and computation units are all represented in the same machine-readable language. The abstract describes 'continuation text output' and 'providing continuation data' (reflecting an earlier claim version) rather than 'fact-checking first output' (the granted claim), creating a mismatch that an examiner or adversary could use to argue the abstract does not describe what is actually claimed.
⚠️
Figure Support Quality
FIG. 10 provides direct process-flow support for the four-step Claim 1 method and FIG. 11 supports the semantic graph structure. However, several key Claim 1 limitations lack dedicated figure support: the 'reasoning steps represented in the machine-readable language' limitation (step (b)) has only textual description support; the 'computation units represented in the machine-readable language' limitation has only the Claim 1 label-level support; and no figure illustrates the 'semantic links are themselves semantic nodes' structural property that is the core differentiator of the UL language. FIGs. 8–9 support the system architecture context but are directed to the voice assistant embodiment, not the claimed LLM fact-checking method.
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.2
Prosecution Defensibility
3.5
Spec–Claim Consistency
3.8
Dependent Claim Coverage
4.1
Claim Type Diversity
1.5
Figure Support Quality
3
Key observation: The strongest dimension is Dependent Claim Coverage (4.1/5.0): the 29 dependent claims systematically and non-redundantly add distinct technical, functional, and application-domain fallback positions — from policy checking (Claim 24) to hallucination identification via beam search analysis (Claims embedded in spec) — making this one of the more carefully constructed dependent claim ladders in the AI/LLM space. The weakest dimension is Claim Type Diversity (1.5/5.0): the complete absence of system/apparatus claims and computer-readable medium claims means any competitor that builds the same LLM fact-checking pipeline as a standalone system or software product without performing it as a method step would have a colorable design-around argument; a stronger filing would have filed parallel apparatus and CRM claims mirroring Claim 1's limitations. Practitioners reading this patent should prioritize filing continuation claims to capture the system and CRM claim types before any terminal disclaimer or priority chain deadline passes.
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 system or apparatus claims filed Abstract mismatch with granted claim LLM training/fine-tuning not claimed
Unlock Full Analysis — Free Frequently asked questions
US 12,073,180 B2 — 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