Patent Drafting Analysis of Google LLC’s Stateful Chat Search with Generative AI | US 2024/0289407 A1
Patent Drafting Analysis of Google LLC's Stateful Chat Search with Generative AI | US 2024/0289407 A1
A structural and strategic analysis of Google's generative companion search patent, examining claim architecture, drafting quality, §101 eligibility risk, and prosecution positioning across method, system, and CRM claim formats.
Spec Words
9,800
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
11
System architecture, method flowcharts, UI mockups
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 65% of total words (~6,400 of ~9,800), reflecting deep multi-embodiment treatment of the generative companion architecture across nine distinct flowchart methods. The claim set comprises 20 claims in 3 independent claims (method, system, CRM) with 17 dependents, yielding a 5.67:1 dependent-to-independent ratio consistent with software/cloud norms. Figure coverage spans 11 sheets from the overview architecture (FIG. 1) through detailed UI mockups (FIGs. 7A–7B) and computing device hardware (FIG. 10), providing strong visual grounding for the principal claim limitations.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 11 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Block diagram of the example environment 100 showing client device 110, NL-based response system 120 (with SRD selection engine 122, LLM selection engine 132, LLM input engine 134, LLM response generation engine 136, response linkifying engine 138, response confidence engine 140, interaction engine 142, and chat engine 144), and search systems 160 with indices 172 and measures 174.Search in Eureka ↗ | System architecture |
| FIG. 2 | Flowchart of method 200 showing the full pipeline of receiving a query, selecting query-responsive, related-query-responsive, recent-query-responsive, and implied-query-responsive SRDs, generating an NL-based summary using an LLM from SRD content, and causing the summary to be rendered with links and confidence annotations.Search in Eureka ↗ | Flow diagram |
| FIG. 3 | Flowchart of method 300 illustrating the process of selectively linkifying portions of NL-based content with links to candidate documents that verify each portion, including the iterative verification loop across portions and documents (blocks 356–368) and final rendering at block 370.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Flowchart of method 400 depicting generation of a revised NL-based summary response in reaction to user interaction with search result documents, including the interaction monitoring loop (block 458), revised input generation (blocks 460–460B), and rendering of revised NL summary (block 462) to supplant the initial summary.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Flowchart of method 500 showing selection of none, one, or multiple generative models from candidate GMs to use in generating responses to a query, based on processing the query and/or responsive SRDs using classifiers and/or rules (sub-block 554A1).Search in Eureka ↗ | Flow diagram |
| FIG. 6 | Flowchart of method 600 illustrating user-familiarity-conditioned NL summary generation, where a profile-based familiarity determination (block 654) routes to either familiarity-aware LLM processing (block 658) or standard LLM processing (block 660) before rendering the output.Search in Eureka ↗ | Flow diagram |
| FIG. 7A | UI mockup of client device 710 rendering display 780 with a query input 782 ("Is it good to drink coffee"), an NL-based summary 784 with three linkified portions (S1–S3), a view-sources expansion element 786, and three example search result entries 788 below the summary.Search in Eureka ↗ | UI/interface |
| FIG. 7B | UI mockup showing the same client device 710 after user interaction with expansion element 786, revealing the source documents 787 (S1–S3 with URLs and supporting text excerpts) that verify the linkified portions of NL-based summary 784.Search in Eureka ↗ | UI/interface |
| FIG. 8 | System schematic of the generative companion architecture showing the interaction among current query 870, user state 871 (prior queries, SRDs, engagement, outputs, other signals), context engine 113, search systems 160, LLM selection engine 132, LLM input engine 134, LLM response generation engine 136 (with six specialized LLM types 872A–F), chat engine 144, and current output 874.Search in Eureka ↗ | System architecture |
| FIG. 9 | Flowchart of method 900 for implementing the generative companion, covering query receipt (952), contextual information retrieval (954), LLM output generation (956), synthetic query generation (958), SRD set selection (960), state data classification (962), downstream LLM selection (964), additional LLM output generation (966), NL rendering (968), and user state update feedback loop.Search in Eureka ↗ | Claim support |
| FIG. 10 | Block diagram of example computing device 1010 depicting processor(s) 1016, bus subsystem 1012, storage subsystem 1024 (memory subsystem 1025 with RAM 1030/ROM 1032, file storage subsystem 1026), user interface input devices 1022, user interface output devices 1020, and network interface 1016.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 3 independent claims — Claim 1 (method), Claim 17 (system), and Claim 20 (CRM) — providing tripartite enforcement coverage across the three primary claim-type formats. The 17:3 dependent-to-independent ratio of approximately 5.67:1 is within the software/cloud norm of 4–8:1, with the bulk of dependent claims (Claims 2–16) appended exclusively to Claim 1, creating a significant coverage asymmetry. The claim strategy deliberately mirrors the same core operational sequence across all three independent claims, ensuring that infringement of the method necessarily corresponds to infringement of the system and CRM variants.
Core inventive concept: The claims solve the problem of under-personalized, context-blind generative search responses by reciting a pipeline in which contextual information is retrieved and used alongside the query to generate LLM output, which is then used to generate synthetic queries; a set of search result documents is selected based on responsiveness to both the original query and the synthetic queries; and state data combining query, contextual information, synthetic queries, and the SRD set is processed to classify the query and select downstream generative models for targeted additional LLM output generation — all as recited in Claims 1, 17, and 20.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method implemented by one or more processors during a search session of a user | comprising | receiving a query from a client device; retrieving contextual information associated with the user or client device; generating GM output using an GM from query+contextual data; generating synthetic queries using GM output; selecting a set of SRDs including query-responsive SRDs responsive to both query and synthetic queries; processing state data (query, contextual info, synthetic queries, SRD set) to classify the query; selecting downstream GM(s) based on classification; generating additional GM outputs using downstream GMs and at least some state data; causing NL content to be rendered at client deviceSearch prior art ↗ |
| Claim 17 | A system comprising one or more processors and memory storing instructions | comprising | Processor-executable instructions to: receive a query; retrieve contextual information; generate GM output from query+contextual data; generate synthetic queries from GM output; select SRD set including query-responsive SRDs responsive to query and synthetic queries; process state data to classify query; select downstream GMs based on classification; generate additional GM outputs from downstream GMs and state data; cause NL content to be rendered at client deviceSearch prior art ↗ |
| Claim 20 | At least one non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to | comprising | Receive a query from a client device; retrieve contextual information; generate GM output from query+contextual data; generate synthetic queries from GM output; select SRD set with query-responsive SRDs responsive to query and synthetic queries; process state data to classify query; select downstream GMs; generate additional GM outputs from downstream GMs and state data; cause NL content to be rendered at client deviceSearch prior art ↗ |
Claim Dependency Tree
1 Method: stateful search session — retrieve context, generate GM output, generate synthetic queries, select SRDs, classify query via state data, select downstream GMs, generate additional GM outputs, render NLSearch Claim 1 prior art ↗
2 Adds: contextual information includes one or more prior queries issued during the search sessionSearch in Eureka ↗
3 Adds: contextual information includes data extracted from search results pages returned in response to prior queriesSearch in Eureka ↗
4 Adds: contextual information includes data extracted from prior-query-responsive search result documentsSearch in Eureka ↗
5 Adds: contextual information includes information about the schedule of the userSearch in Eureka ↗
6 Further: schedule information retrieved from electronic calendar, electronic correspondence of user, or another userSearch in Eureka ↗
7 Adds: contextual information includes position coordinates of the userSearch in Eureka ↗
8 Adds: state data comprises aggregate embedding generated from query, contextual information, synthetic queries, and SRD setSearch in Eureka ↗
9 Adds: state data comprises data extracted from search results pages returned in response to synthetic queriesSearch in Eureka ↗
10 Adds: state data comprises data indicative of one or more actions performed by the user subsequent to issuing the querySearch in Eureka ↗
11 Further: data indicative of actions includes data extracted from query-responsive SRDs accessed by userSearch in Eureka ↗
12 Adds: at least one downstream GM comprises a creative GM trained to generate creative natural language (NL)Search in Eureka ↗
13 Adds: at least one downstream GM comprises an ambient GM trained to generate a summary of a document accessed by user subsequent to issuing the querySearch in Eureka ↗
14 Adds: at least one downstream GM comprises a search results GM trained to generate summaries of search results pagesSearch in Eureka ↗
15 Adds: content responsive to the query is included in subsequent contextual information retrieved during one or more subsequent turns of the search sessionSearch in Eureka ↗
16 Adds: contextual information comprises prior content responsive to a prior query issued by user during the search sessionSearch in Eureka ↗
17 System: one or more processors and memory storing instructions to perform the same stateful search pipeline as Claim 1Search Claim 17 prior art ↗
18 Adds: contextual information includes one or more prior queries issued by user during the search sessionSearch in Eureka ↗
19 Adds: contextual information includes data extracted from search results pages returned in response to one or more prior queriesSearch in Eureka ↗
20 CRM: non-transitory computer-readable medium with instructions to perform the same stateful search pipeline as Claim 1Search Claim 20 prior art ↗
| 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 17 | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The claims demonstrate strong multi-modal coverage across Claim 1 (method), Claim 17 (system), and Claim 20 (CRM), ensuring enforcement flexibility; the core limitation of state-data-driven query classification tied to downstream GM selection provides a technically specific hook that differentiates the claims from simple LLM-augmented search. However, the 17 dependent claims appended almost entirely to Claim 1 — with Claims 17 and 20 receiving only 2 and 0 dependents respectively — creates a lopsided fallback architecture that leaves the system and CRM claims largely unsupported if Claim 1 is rejected or narrowed.
✅
Antecedent Basis
The claim set is largely clean on antecedent basis. Claim 1 introduces "a query," "contextual information," "GM output," "synthetic queries," "a set of search result documents," and "downstream GMs" with appropriate indefinite articles, then refers back to "the query," "the contextual information," "the GM output," "the one or more synthetic queries," "the set," and "the downstream GMs" consistently. No orphaned "the [element]" references were identified in Claims 1–20. Dependent Claims 2–16 all properly establish their added limitations before reference.
✅
Spec–Claim Consistency
The key independent claim limitations map directly to specific specification paragraphs and figures. The "retrieving contextual information" limitation of Claim 1 is supported by ¶[0004]–[0006] and FIG. 8 (context engine 113 and user state 871). The "generating synthetic queries using the GM output" limitation is supported by ¶[0007] and FIG. 9 (blocks 956–958). The state data classification and downstream GM selection steps are supported by ¶[0010]–[0011] and FIG. 9 (blocks 962–964). All principal limitations have written description support.
✅
Transition Word Usage
All three independent claims (Claims 1, 17, 20) use "comprising" as the transition, which is the broadest available and appropriate for open-ended software and system claims in this art unit. This preserves infringement coverage even when an accused system performs additional steps not recited. No "consisting of" or "consisting essentially of" transitions appear, eliminating the risk of inadvertent scope narrowing. The choice is strategically optimal for a cloud-based AI search platform where implementations will inevitably include ancillary processing steps.
⚠️
§112(f) Means-Plus-Function Risk
The independent claims avoid "means for" language, instead using functional verbs tied to processor steps ("receiving," "retrieving," "generating," "selecting," "processing," "causing"), which is standard software claim drafting. However, the system claim (Claim 17) recites "memory storing instructions that... cause the one or more processors to" perform the listed functions — a functional claiming pattern that, while accepted in software claims, could face scrutiny if the examiner argues that the processor-memory combination constitutes a functional element lacking corresponding structure beyond the specification's flowcharts. The spec's FIG. 1 and FIG. 8 provide named engines (LLM selection engine 132, context engine 113, etc.) as corresponding structure, mitigating but not eliminating this risk.
⚠️
§101 Eligibility Risk
The claims face meaningful Alice step-two risk because all three independent claims recite abstract mental-process analogues (receiving queries, generating outputs, classifying, selecting models) without explicitly tying these steps to novel hardware configurations. The §101 defense rests primarily on the combination of steps being applied in a specific technical context (real-time multi-turn search sessions, LLM-based state embedding) rather than on dedicated novel hardware. Claim 17's "system comprising one or more processors" provides some hardware tie-in, but examiners in Art Unit 2168 routinely reject structurally similar AI-search claims under Alice. The spec's disclosure of specific named LLM architectures (¶[0055], FIGs. 8) and the downstream-GM classification mechanism (¶[0010]–[0011]) provide the strongest §101 arguments but are not affirmatively recited in Claims 1 or 20.
⚠️
Dependent Claim Fallback Quality
The 17 dependent claims are almost entirely appended to Claim 1, leaving Claims 17 and 20 with minimal (2 and 0) dependent fallbacks respectively — a prosecution risk if Claim 1 requires amendment. Among the dependent claims, Claims 12–14 add genuine technical specificity by naming distinct downstream GM types (creative NL, ambient summarization, SRP summarization), providing meaningful fallback positions. Claims 2–4 add contextual information types (prior queries, SRP data, prior-SRD data) that are largely redundant with each other and offer limited differentiation. Claims 8 and 15 are the most strategically valuable: Claim 8 introduces aggregate embedding as state data representation, and Claim 15 adds the feedback-loop limitation that output becomes subsequent contextual information.
⚠️
Abstract Quality
An examiner reading only the abstract may struggle to identify the novel technical contribution: the abstract accurately describes the generative companion concept and references synthetic queries, state data, query classification, and downstream GMs, but the 120-word summary buries the novel classification-driven downstream GM selection mechanism — the feature that most distinguishes this invention from prior LLM-augmented search — in the final sentence. The abstract states: "State data indicative of: the query, contextual information, one or more of the synthetic queries, and the set of search result documents, may be processed to identify a classification of the query. Based on the classification, downstream GM(s) may be selected," which is accurate but compressed. A stronger abstract would lead with this mechanism as the point of novelty.
✅
Figure Support Quality
Figure coverage is comprehensive for the principal claim limitations. The SRD selection and synthetic query steps of Claim 1 are supported by FIG. 2 (blocks 254–259) and FIG. 9 (blocks 958–960). The state data classification and downstream GM selection steps are directly visualized in FIG. 9 (blocks 962–964) and FIG. 8 (LLM selection engine 132 with GMs 872A–F). The system architecture of Claim 17 maps to FIG. 1 and FIG. 8. The CRM embodiment of Claim 20 is supported by FIG. 10 (computing device 1010 with storage subsystem 1024). No independent claim limitation appears to lack figure support, though the aggregate embedding state data of Claim 8 is described only textually (¶[0021]) without a dedicated figure.
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
Claim Type Diversity
4.5
Figure Support Quality
4
Key observation: Claim Type Diversity scores highest (4.5/5.0) because the tripartite independent claim structure — method (Claim 1), system (Claim 17), and CRM (Claim 20) — covers all three primary enforcement formats without unnecessary limitations in any of the preambles. Prosecution Defensibility scores lowest (3.2/5.0) because the 17 dependent claims cluster almost entirely under Claim 1, leaving Claims 17 and 20 nearly unsupported: if Claim 1 is rejected or amended during prosecution, the system and CRM claims lose their fallback scaffolding entirely. Practitioners evaluating continuation strategy should prioritize adding dependent claim sets under Claims 17 and 20 that parallel the richest Claim 1 dependencies (Claims 8, 12–15) to address this asymmetry.
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 dependents under Claims 17 or 20 §101 Alice risk — no hardware anchoring Linkification and confidence features unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 2024/0289407 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