Patent Drafting Analysis of Adobe’s Generative AI Fine-Tuned Language Model Evaluation | US 2025/0124235 A1
Patent Drafting Analysis of Adobe's Generative AI Fine-Tuned Language Model Evaluation | US 2025/0124235 A1
A structural and strategic analysis of Adobe's patent covering claim architecture, drafting quality signals, critical gaps, and prosecution positioning for AI-driven language model evaluation methods.
Spec Words
6,800
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
6
System architecture, component diagrams, process flows
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 63% of total words (~4,200 of ~6,600 substantive words), with a well-structured Definitions subsection in paragraphs [0009]–[0015] that anchors key technical terms. The claim set comprises 20 total claims with 3 independent claims spanning method (Claim 1), computer-readable medium (Claim 9), and system (Claim 15) formats, yielding a 5.67:1 dependent-to-independent ratio. Six figure sheets cover the operating environment (FIG. 1), component architecture (FIG. 2), four-step process diagrams (FIGS. 3A–3D), method flow (FIG. 4), and computing device hardware (FIG. 5), providing adequate but not exhaustive structural support.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 6 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Depicts the operating environment 100 showing User Device 102, Network 104, Generative Language Model 106, Language Model 116, Training Data Source 112, and Language Model Fine-Tuning and Evaluation Manager 108 interconnected via network.Search in Eureka ↗ | System architecture |
| FIG. 2 | Shows an example configuration of the Language Model Fine-Tuning and Evaluation Manager 202, including Generative Language Model 204, Language Model 206, Fine-Tuning Component 208, Evaluation Component 210, Evaluation Metric 212, User Interface Component 214, Training Data 216, and Data Store 218.Search in Eureka ↗ | System architecture |
| FIG. 3A | Illustrates Step 1 — Generation of Training and Validation Sets, showing keyword-based query and top_document data 304 fed to Generator LLM 308A (e.g., Flan-UL2) via Prompt 306 to produce conversational queries 310.Search in Eureka ↗ | Flow diagram |
| FIG. 3B | Illustrates Step 2 — Fine-Tuning on Training and Validation Sets, showing LLM Fine-Tuning (e.g., Sentence-BERT) 314 using data 310 to produce fine-tuned embeddings 316.Search in Eureka ↗ | Claim support |
| FIG. 3C | Illustrates Step 3 — Generation of Independent Test Set, showing a different Generator LLM 308B and different Prompt 320 generating independent conversational queries 322 from the same keyword-document pairs 304.Search in Eureka ↗ | Flow diagram |
| FIG. 3D | Illustrates Step 4 — Robust Evaluation on the Independent Test Set, showing the independent test set 322 applied to fine-tuned embeddings 316 via Robust Evaluation 326 to yield more realistic measurements 328.Search in Eureka ↗ | Claim support |
| FIG. 4 | Process flow diagram 400 showing method steps 402–410: generate text snippets via generative LM, fine-tune language model, generate independent snippets, generate evaluation metric, and display evaluation metric.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Block diagram of example computing device 500 showing Bus 510 coupling Memory 512, Processor(s) 514, Presentation Component(s) 516, Radio(s) 524, I/O Port(s) 518, I/O Components 520, and Power Supply 522.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 (computer-implemented method), Claim 9 (non-transitory computer-readable medium), and Claim 15 (computing system) — providing tripartite claim type coverage across the primary enforcement formats. The 17:3 dependent-to-independent ratio of approximately 5.67:1 is slightly above the typical 4–5:1 norm for the G06F software/AI IPC class, suggesting moderately good fallback layering. The tripartite structure across method, CRM, and system claims (Claims 1, 9, and 15 respectively) provides enforcement flexibility, though the system claim's use of 'trigger-generating' functional language in Claim 15 creates a stylistic divergence from the more conventional apparatus claim format.
Core inventive concept: The claims address the problem of overfitting in fine-tuned language models when evaluated using the same query variations used for training — a problem that leads to inflated performance measurements. The solution, as expressed across Claims 1, 9, and 15, is to use a generative language model to produce a first set of natural language text snippets for training, and a second 'independent' set — where 'each independent natural language text snippet being different than each corresponding natural language text snippet' — as a separate test set for evaluation, thereby generating more realistic performance measurements.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A computer-implemented method | comprising | generating (via generative language model) set of NL text snippets based on corresponding set of data; fine-tuning (via language model fine-tuning component) language model using text snippets and data as training data; generating (via generative language model) set of independent NL text snippets where each independent snippet differs from corresponding training snippet; generating (via evaluation component) evaluation metric based on independent snippets and corresponding dataSearch prior art ↗ |
| Claim 9 | A non-transitory computer-readable medium storing executable instructions, which when executed by a processing device, cause the processing device to perform operations | comprising | prompting (via language model fine-tuning component) generative LM to generate set of NL text snippets based on keywords and corresponding documents; fine-tuning language model using text snippets and documents as training data; prompting generative LM to generate set of independent NL text snippets where each independent snippet differs from each training snippet; generating (via evaluation component) evaluation metric of fine-tuned LM based on independent snippets and corresponding documentsSearch prior art ↗ |
| Claim 15 | A computing system | comprising | a processor; a non-transitory computer-readable medium with stored instructions causing processor to: trigger-generate (via generative LM) set of NL queries based on keywords and corresponding documents; trigger-generate (via language model fine-tuning component) fine-tuned language model from language model using queries and documents as training data; trigger-generate (via generative LM) set of independent NL queries where each independent query differs from corresponding training query; trigger-generate (via evaluation component) evaluation metric; cause display of evaluation metricSearch prior art ↗ |
Claim Dependency Tree
1 Computer-implemented method: generate NL text snippets via generative LM, fine-tune LM, generate independent snippets differing from training snippets, generate evaluation metricSearch Claim 1 prior art ↗
2 Adds: corresponding data comprises set of documents; generating snippets comprises receiving keywords and corresponding documents, generating each snippet based on keywords and documentsSearch in Eureka ↗
3 Adds: generating set of NL text snippets further comprises receiving a prompt comprising a set of exemplars (keyword, document, NL query), generating each snippet based on the promptSearch in Eureka ↗
4 Adds: generating set of independent NL text snippets further comprises receiving a prompt different than initial prompt and generating each independent snippet based on the different promptSearch in Eureka ↗
5 Adds: each NL text snippet and each independent NL text snippet are natural language queriesSearch in Eureka ↗
6 Adds: fine-tuning uses Sentence Bidirectional Encoder Representations from Transformers (SBERT)Search in Eureka ↗
7 Adds: evaluation metric comprising at least one of accuracy, precision, recall, Hit@K, MRR, and NDCGSearch in Eureka ↗
8 Adds: the set of independent NL text snippets and corresponding set of data is a test set of dataSearch in Eureka ↗
9 Non-transitory CRM: prompt generative LM to generate NL text snippets from keywords/documents, fine-tune LM, prompt generative LM to generate independent snippets differing from training snippets, generate evaluation metricSearch Claim 9 prior art ↗
10 Adds: prompting to generate NL text snippets further comprises generating a prompt with exemplars (keyword, document, NL query) and prompting generative LM based on promptSearch in Eureka ↗
11 Adds: prompting to generate independent NL text snippets further comprises generating a prompt different from initial prompt and prompting generative LM based on that different promptSearch in Eureka ↗
12 Adds: each NL text snippet and each independent NL text snippet are natural language queriesSearch in Eureka ↗
13 Adds: fine-tuning uses Sentence Bidirectional Encoder Representations from Transformers (SBERT)Search in Eureka ↗
14 Adds: evaluation metric comprising at least one of accuracy, precision, recall, Hit@K, MRR, and NDCGSearch in Eureka ↗
15 Computing system: processor + CRM; trigger-generate NL queries via generative LM from keywords/documents; trigger-generate fine-tuned LM; trigger-generate independent NL queries differing from training queries; trigger-generate evaluation metric; cause display of metricSearch Claim 15 prior art ↗
16 Adds: trigger-generating set of NL queries further comprises receiving prompt with exemplars (keyword, document, NL query) and generating each NL query based on promptSearch in Eureka ↗
17 Adds: trigger-generating set of independent natural language queries further comprises receiving a prompt different from initial prompt and generating each independent query based on that different promptSearch in Eureka ↗
18 Adds: fine-tuned language model is generated using SBERTSearch in Eureka ↗
19 Adds: evaluation metric comprising at least one of accuracy, precision, recall, Hit@K, MRR, and NDCGSearch in Eureka ↗
20 Adds: the set of independent natural language queries and the corresponding set of documents is a test set of dataSearch in Eureka ↗
| Metric | This Application | Software / AI Industry 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 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 claims demonstrate solid structural consistency between the specification's four-step process (FIGS. 3A–3D) and the independent claim limitations, particularly in how Claim 1's 'generating independent text snippets' limitation maps directly to the Step 3 and Step 4 process described in paragraphs [0023]–[0024]. However, the heavy reliance on functional claiming language — particularly Claim 15's repeated use of 'trigger-generating' — creates non-trivial §112(f) and §101 Alice exposure risks that a prosecution examiner is likely to raise early in examination.
✅
Antecedent Basis
The claim language maintains clean antecedent basis throughout the 20-claim set. For example, Claim 1 introduces 'a set of natural language text snippets' and subsequently refers to 'the set of natural language text snippets' and 'the corresponding set of data' consistently. Claim 9's introduction of 'a set of keywords' and 'a corresponding set of documents' in the first limitation is correctly followed by 'the set of natural language text snippets' and 'the corresponding set of documents' in subsequent limitations. No orphaned 'the' references were found across dependent claims 2–8, 10–14, or 16–20.
✅
Spec–Claim Consistency
The specification directly supports all four primary limitations of independent Claim 1. FIG. 3A and paragraphs [0058]–[0059] support the 'generating...set of natural language text snippets' limitation; FIG. 3B and paragraphs [0037], [0075] support the 'fine-tuning...language model' limitation; FIG. 3C and paragraph [0077] support the 'generating...set of independent natural language text snippets...being different' limitation; and FIG. 3D and paragraphs [0024], [0055] support the 'generating...evaluation metric' limitation. The Definitions section (¶¶[0009]–[0015]) provides written description anchors for key terms used in the claims.
✅
Transition Word Usage
All three independent claims (Claims 1, 9, and 15) correctly use 'comprising' as the transition, preserving open-ended claim scope that permits additional, unstated elements in an accused embodiment. This is strategically optimal for a software/AI patent where the inventive process may be embedded within a larger pipeline including additional pre- and post-processing steps not enumerated in the claims. No 'consisting of' or 'consisting essentially of' language was found, which would have inappropriately narrowed the claims to only the enumerated steps.
⚠️
§112(f) Means-Plus-Function Risk
Claim 15's repeated use of 'trigger-generating, via a generative language model' and 'trigger-generating, via a language model fine-tuning component' introduces a borderline functional claiming issue. While no explicit 'means for' language is used, the nonce word 'trigger-generating' combined with a named component ('via a generative language model') could attract an examiner's argument that the functional description invokes §112(f) treatment, requiring disclosure of specific algorithms for 'trigger-generating' in the specification. The specification describes these components in ¶¶[0049]–[0051] but does not define 'trigger-generating' as a distinct structural operation, creating a potential prosecution vulnerability.
⚠️
§101 Eligibility Risk
This patent faces a significant Alice/Mayo §101 challenge because the claims at their highest level of abstraction describe the abstract idea of 'using one AI system to generate test data for evaluating another AI system' — a data processing concept with no hardware tie-in beyond generic processor/memory recitations in Claim 15. The §101 defense will rest on the argument that the claimed method provides an improvement to computer functionality (more efficient LM evaluation) as stated in ¶[0026], but examiners in AU 2160 routinely reject such efficiency arguments under Alice step two without concrete hardware anchoring. Claims 1 and 9 lack any hardware-specific element that would satisfy the 'practical application' prong of the USPTO's 2019 Revised Guidance.
✅
Dependent Claim Fallback Quality
The dependent claims add meaningfully distinct fallback positions across three dimensions. Claims 2/3 (method), 10 (CRM), and 16 (system) add the exemplar-based prompt structure — a structurally distinct and commercially important limitation. Claims 4/11/17 add the 'different prompt' mechanism for generating independent test queries — the core differentiator of the invention that should arguably have been in the independent claims. Claims 6/13/18 add the specific SBERT implementation, providing a technically concrete fallback. Claims 7/14/19 enumerate specific evaluation metrics (Hit@K, MRR, NDCG), creating useful prosecution history estoppel boundaries. The tripartite repetition of the same dependent claim themes across Claims 1, 9, and 15 is expected and appropriate.
⚠️
Abstract Quality
The abstract describes the system components accurately but fails to highlight the key inventive distinction: that the independent natural language text snippets used for evaluation are generated via a *different prompt* than those used for training — the mechanism that prevents evaluation contamination. An examiner reading only the abstract would understand the general system but would not identify this specific independence-ensuring mechanism as the novel contribution. The abstract states 'independent natural language text snippets are generated via the generative language model based on the corresponding data' without noting that a different prompt is used, which is the structural innovation that distinguishes this from prior art evaluation methods.
✅
Figure Support Quality
The six figures provide adequate structural support for the claim limitations. FIG. 2 maps to the component-level recitations in Claims 9 and 15 (language model fine-tuning component 208, evaluation component 210). FIGS. 3A–3D provide a four-step process flow that directly supports the four operative steps of independent Claim 1. FIG. 4 provides a higher-level method flow supporting Claims 1 and 9. However, there is no figure showing the internal architecture of the generative language model (GLM 204/106) or the fine-tuning mechanism in detail, meaning the SBERT-specific limitations in Claims 6/13/18 lack dedicated figure support and rely solely on paragraph descriptions at ¶¶[0022], [0038].
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
Spec–Claim Consistency
4
Dependent Claim Coverage
3.8
Claim Type Diversity
4.5
Figure Support Quality
3.5
Key observation: Claim Type Diversity (Score 4.5) is the strongest dimension — the tripartite method/CRM/system claim structure across Claims 1, 9, and 15 ensures enforcement coverage against direct infringers, contributory infringers, and system implementers alike, with no obvious claim type gap. Prosecution Defensibility (Score 3.0) is the weakest dimension — the §101 Alice exposure on Claims 1 and 9 (which lack any hardware tie-in beyond the abstract 'generative language model') combined with Claim 15's 'trigger-generating' functional language creates twin prosecution vulnerabilities that could require multiple office action responses. Practitioners should consider filing a continuation that anchors at least one independent claim to a specific technical implementation detail — such as the SBERT embedding architecture currently relegated to dependent Claims 6, 13, and 18.
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 hardware anchor for §101 defense Different-prompt mechanism only in dependents No claim on deployment decision output use case
Unlock Full Analysis — Free Frequently asked questions
US 2025/0124235 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