Patent Drafting Analysis of Google LLC’s Privacy-Preserving Personalized LLM Technology | US 2024/0403564 A1
Patent Drafting Analysis of Google LLC's Privacy-Preserving Personalized LLM Technology | US 2024/0403564 A1
A structural and strategic analysis of Google's personalized LLM patent, examining claim architecture, drafting quality, §101 exposure, critical gaps in claim coverage, and prosecution positioning across 28 claims.
Spec Words
6,200
Across 6 sections
Draft now ↗
Total Claims
28
2 independent · 26 dependent
Draft now ↗
Figure Sheets
8
System architecture, UI flows, training processes, flowchart, computing hardware
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 52% of total specification words (~3,200 of ~6,200), providing strong narrative support for the claimed personalization and training mechanisms. The claim set comprises 28 claims across 2 independent claims — one method (Claim 1) and one system (Claim 15) — with 26 dependent claims yielding an exceptionally high dependent-to-independent ratio of 13:1, reflecting Google's layered prosecution strategy. Figure coverage spans 8 sheets covering user-facing UI scenarios, system architecture, training processes, and computing hardware, though no dedicated figure exists for the embedding model inference pipeline in isolation.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 8 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1A | Example system 100a showing user device 10 connected to remote system 60 via network 40, with language model system 200 generating personalized shoe-recommendation response 252 in GUI 20.Search in Eureka ↗ | System architecture |
| FIG. 1B | Example system 100b showing user feedback UI element 116 asking "Where these results what you were looking for?" with Yes/No selection for reinforcement learning of user prompt embeddings.Search in Eureka ↗ | UI/interface |
| FIG. 1C | Example system 100c showing privacy consent UI element 122 requesting access to user's data store, with Approve/Deny options before the LLM 240 accesses personal tax return data.Search in Eureka ↗ | UI/interface |
| FIG. 2 | Schematic of language model system 200 showing embedding identifier 210, embedding data store 220, embedding model 230, large language model 240, and response generator 250 with data flows from user features 204 and textual prompt 202.Search in Eureka ↗ | System architecture |
| FIG. 3A | Training process 300a for clustered embedding fine-tuning showing training data store 310, training tasks 330, loss module 340, and fine-tuning of fine-tuned user prompt embeddings 222 with LLM 240 parameters fixed.Search in Eureka ↗ | Claim support |
| FIG. 3B | Training process 300b for user prompt embedding model 230 showing sampling from training data store 310, loss module 340, and tuning of soft user prompt embeddings 232 with LLM 240 parameters fixed.Search in Eureka ↗ | Claim support |
| FIG. 4 | Flowchart of method 400 with operations 402–410 covering receiving textual prompt, obtaining user features, determining user prompt embedding, processing LLM conditioned on embedding, and providing personalized response.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Computing device 500 hardware schematic showing processor 510, memory 520, storage 530, high-speed controller 540, expansion ports 550, low-speed controller 560, display 580, and low-speed expansion port 590 in server, laptop, and rack form factors.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 contains 2 independent claims: Claim 1 (computer-implemented method) and Claim 15 (system), with 26 dependent claims yielding a 13:1 dependent-to-independent ratio, substantially above the Software/Cloud norm of 4–8:1, reflecting a deliberate strategy to maximize fallback positions across training methodologies, embedding types, and local context augmentation. Notably absent is a computer-readable medium (CRM) independent claim, leaving a significant claim-type gap that a competitor could exploit by practicing the invention solely in software form. The dependent claims are organized into two near-parallel branches off Claims 1 and 15, covering user feature types (Claim 2/16), soft prompt embeddings (Claim 3/17), clustered category-based embedding (Claims 4–7/18–21), soft prompt embedding models (Claims 8–10/22–24), and local context augmentation with personal data access (Claims 11–14/25–28).
Core inventive concept: The claims solve the computational infeasibility of retraining LLMs per-user by introducing a user prompt embedding — a "soft prompt" vector derived from a set of user features (location, age, gender) — that conditions an otherwise fixed LLM to generate personalized responses without modifying LLM parameters. Specifically, Claim 1 requires "processing, using the LLM, the textual prompt conditioned on the user prompt embedding for the user to generate a personalized response," while keeping LLM weights frozen, achieving personalization through embedding-space conditioning rather than fine-tuning.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A computer-implemented method that when executed on data processing hardware causes the data processing hardware to perform operations | comprising | receiving a textual prompt specifying a task for an LLM; obtaining a set of user features associated with the user; determining a user prompt embedding using the user features; processing the LLM conditioned on the user prompt embedding to generate a personalized response; providing the personalized response for output from a user deviceSearch prior art ↗ |
| Claim 15 | A system | comprising | data processing hardware; memory hardware storing instructions that cause the data processing hardware to perform operations: receiving a textual prompt specifying a task for an LLM; obtaining user features; determining a user prompt embedding; processing the LLM conditioned on the user prompt embedding to generate a personalized response; providing the personalized response for output from a user deviceSearch prior art ↗ |
Claim Dependency Tree
1 Computer-implemented method: receiving textual prompt, obtaining user features, determining user prompt embedding, processing LLM conditioned on embedding to generate personalized responseSearch Claim 1 prior art ↗
2 Adds: user features comprise at least one of location, age, or gender of userSearch in Eureka ↗
3 Adds: user prompt embedding comprises a soft prompt configured to guide LLM while LLM parameters are held fixedSearch in Eureka ↗
4 Adds: determining user prompt embedding by identifying a corresponding user category from plurality of user categories each associated with fine-tuned user prompt embeddingSearch in Eureka ↗
5 Adds: fine-tuned user prompt embedding for user category comprises a soft prompt embedding configured to guide LLM while parameters held fixedSearch in Eureka ↗
6 Adds: soft prompt embedding for each user category guides LLM to provide different personalized response to same textual promptSearch in Eureka ↗
7 Adds: fine-tuned user prompt embedding learned during clustered embedding fine-tuning process with detailed training dataset structureSearch in Eureka ↗
8 Adds: determining user prompt embedding by using user prompt embedding model to predict respective soft user prompt embedding for userSearch in Eureka ↗
9 Adds: user features comprise personal information specific to user; soft user prompt embedding predicted for user is encryptedSearch in Eureka ↗
10 Adds: user prompt embedding model trained to predict soft user prompt embeddings during user embedding model training process with sampled usersSearch in Eureka ↗
11 Adds: operations further include receiving local context and augmenting textual prompt by concatenating with local context and user prompt embeddingSearch in Eureka ↗
12 Adds: local context concatenated in plain text with textual prompt and user prompt embeddingSearch in Eureka ↗
13 Adds: local context comprises at least one of activity history, private corpus documents, user history information, or personalized resultsSearch in Eureka ↗
14 Adds: operations include determining personal repository access is required, generating LLM search query with special token, requesting personal data from repositorySearch in Eureka ↗
15 System comprising data processing hardware and memory hardware storing instructions to perform same operations as Claim 1Search Claim 15 prior art ↗
16 Adds: user features comprise at least one of location, age, or gender (system analog of Claim 2)Search in Eureka ↗
17 Adds: user prompt embedding comprises soft prompt configured to guide LLM while parameters held fixed (system analog of Claim 3)Search in Eureka ↗
18 Adds: determining user prompt embedding by identifying user category with associated fine-tuned user prompt embedding (system analog of Claim 4)Search in Eureka ↗
19 Adds: fine-tuned embedding for user category comprises soft prompt for personalized responses while LLM parameters held fixed (system analog of Claim 5)Search in Eureka ↗
20 Adds: soft prompt for each user category guides LLM to provide different personalized response to same prompt (system analog of Claim 6)Search in Eureka ↗
21 Adds: fine-tuned embedding learned during clustered embedding fine-tuning process (system analog of Claim 7)Search in Eureka ↗
22 Adds: determining user prompt embedding using user prompt embedding model to predict soft user prompt embedding (system analog of Claim 8)Search in Eureka ↗
23 Adds: user features comprise personal information; soft user prompt embedding is encrypted (system analog of Claim 9)Search in Eureka ↗
24 Adds: user prompt embedding model trained to predict soft embeddings using sampled users training process (system analog of Claim 10)Search in Eureka ↗
25 Adds: operations include receiving local context and augmenting textual prompt by concatenating with local context and user prompt embedding (system analog of Claim 11)Search in Eureka ↗
26 Adds: local context concatenated in plain text with textual prompt and user prompt embedding (system analog of Claim 12)Search in Eureka ↗
27 Adds: local context comprises at least one of activity history, private corpus documents, user history, or personalized results (system analog of Claim 13)Search in Eureka ↗
28 Adds: operations include determining personal repository access requirement, generating LLM search query with special token, requesting personal data (system analog of Claim 14)Search in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 28 | 15 – 25 |
| Independent claim count | 2 | 2 – 4 |
| Dependent : Independent ratio | 13.0 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| System / apparatus claims? | Yes — Claim 15 | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The claim set demonstrates disciplined structural parallelism between the method (Claim 1) and system (Claim 15) branches, and the soft prompt / encrypted embedding limitations in Claims 9 and 23 provide meaningful privacy-specific fallback positions. However, the complete absence of a CRM independent claim and the heavy mirroring of dependent claims across both branches creates a design-around opportunity and weakens the overall claim type diversity, particularly given that the technology is primarily software-implemented on cloud infrastructure.
✅
Antecedent Basis
The claim set maintains clean antecedent basis throughout: "a set of user features" is introduced in Claim 1's second limitation and correctly referenced as "the set of user features" in the third and fourth limitations. Similarly, "a user prompt embedding" is introduced and then referenced as "the user prompt embedding" in the processing step. Claims 4 and 8 introduce "a corresponding user category" and "a user prompt embedding model" with proper first-mention articles, and their dependent claims (5, 6, 7, 9, 10) correctly use definite articles thereafter.
✅
Spec–Claim Consistency
The five core operations of Claim 1 map precisely to FIG. 4 operations 402–410 and are described in ¶[0041]–¶[0042]. The fine-tuned embedding approach of Claims 4–7 is supported by FIG. 3A and ¶[0034]–¶[0035]. The soft prompt embedding model of Claims 8–10 is supported by FIG. 3B and ¶[0032] and ¶[0035]. The local context augmentation of Claims 11–14 maps to FIG. 2 (local context 206) and ¶[0037]–¶[0040]. All major claim limitations have corresponding figure and paragraph support.
✅
Transition Word Usage
Both independent Claims 1 and 15 use "comprising" — the broadest open-ended transition — which is strategically optimal for software claims in this art unit, as it allows the claimed invention to encompass systems that perform additional operations beyond those recited. No narrowing transitions such as "consisting of" or "consisting essentially of" appear in the independent claims. The method claim's use of "comprising" also ensures that an implementation adding additional pre- or post-processing steps does not escape the claim scope.
⚠️
§112(f) Means-Plus-Function Risk
No traditional "means for" language appears in the claims; however, Claim 1's functional recitation of "determining, using the set of user features associated with the user, a user prompt embedding for the user" uses a purely functional description without structural definition of the mechanism performing determination. While this avoids the literal §112(f) trigger, an examiner could argue the "determining" step is indefinite absent algorithmic detail in the claim itself. The spec provides adequate algorithmic support in ¶[0030]–¶[0032] and FIGs. 3A–3B, but a stronger filing would have included at least one dependent claim reciting the specific embedding lookup or model inference steps as structural alternatives.
⚠️
§101 Eligibility Risk
Claims 1 and 15 face moderate Alice exposure: the core concept of personalizing LLM responses using user-context vectors could be characterized as an abstract idea of "customizing information based on user profile." The hardware tie-in is present — Claim 1 specifies "data processing hardware" and Claim 15 explicitly recites data processing and memory hardware — but the "particular machine" argument is weakened because Claim 1's preamble is functional ("when executed on data processing hardware") rather than structural. The encrypted soft embedding of Claims 9/23 and the specific concatenation mechanism of Claims 11–14 provide stronger technical character arguments, but the broadest claims may require amendment during prosecution to survive Alice analysis at the USPTO's software art units (2100 series).
✅
Dependent Claim Fallback Quality
The dependent claims add genuinely distinct fallback positions: Claims 4–7 (category-based fine-tuned embeddings) and Claims 8–10 (per-user soft prompt embedding model) represent two architecturally distinct implementation paths that cannot be simultaneously invalidated by a single prior art reference. Claims 9/23 (encrypted soft embeddings) add a privacy-specific technical limitation that strengthens the technical character argument for §101. Weaker fallback positions include Claims 2/16 (user features limited to location/age/gender), which add only exemplary limitations that are also disclosed in the spec background and could be found in prior art personalization systems.
⚠️
Abstract Quality
An examiner reading only the abstract would correctly identify the receiving/obtaining/determining/processing/providing structure but would not distinguish this from generic prompt engineering or RAG-based personalization systems — the abstract describes the method accurately but omits the key distinguishing mechanism: that the user prompt embedding is a soft prompt that conditions the LLM while its parameters are held fixed. The phrase "user prompt embedding" appears in the abstract but is not defined, meaning the abstract fails to communicate the core technical contribution (parameter-efficient personalization via embedding-space conditioning) that differentiates this patent from prior art personalization systems.
✅
Figure Support Quality
Figure coverage is strong for the main claim elements: FIG. 4 directly maps to all five operations of Claim 1, FIG. 2 illustrates the system components of Claim 15 including the embedding identifier 210 and embedding data store 220, and FIGs. 3A–3B support the two alternative training approaches of Claims 7/10/21/24. The personal data repository access mechanism of Claims 14/28 is described in ¶[0039]–¶[0040] and illustrated indirectly through FIG. 1C's consent UI, but no dedicated architectural figure shows the special-token search query mechanism, creating a minor figure support gap for Claims 14/28.
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.5
Spec–Claim Consistency
4.5
Dependent Claim Coverage
4
Claim Type Diversity
2.5
Figure Support Quality
4
Key observation: Spec–Claim Consistency scores highest (4.5/5) because every independent claim limitation maps precisely to a named figure and numbered paragraph — FIG. 4 and ¶[0041]–¶[0042] directly recite the five Claim 1 operations, and both training approaches of Claims 7/10 are separately illustrated in FIGs. 3A and 3B. Claim Type Diversity scores lowest (2.5/5) because only method and system claim types are filed — the complete absence of a computer-readable medium (CRM) independent claim leaves a third enforcement vector unprotected, allowing a competitor to argue that a software product distributed on tangible media falls outside the claim scope. Practitioners should consider filing a continuation with at least one CRM independent claim to close this design-around gap before the application is examined.
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.
Missing CRM independent claim Fixed-LLM parameter limitation absent from independent claims RL feedback loop disclosed but not claimed
Unlock Full Analysis — Free Frequently asked questions
US 2024/0403564 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