Patent Drafting Analysis of Google LLC’s Delayed Responses by Computational Assistant | US 12,141,672 B2
Patent Drafting Analysis of Google LLC's Delayed Responses by Computational Assistant | US 12,141,672 B2
A structural and strategic analysis of US 12,141,672 B2 covering claim architecture, drafting quality signals, §101 eligibility positioning, critical gaps, and prosecution defensibility for Google's virtual assistant delay-notification technology.
Spec Words
7,200
Across 5 sections
Draft now ↗
Total Claims
19
3 independent · 16 dependent
Draft now ↗
Figure Sheets
4
System architecture, computing device, flowchart, server system
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 60% of total words (~4,350 words), with the claims section representing a substantial ~30% share (~2,175 words), reflecting a claims-heavy continuation strategy typical of Google's assistant patent family. The claim architecture comprises 19 claims across 3 independent claims (system Claim 1, method Claim 10, and CRM Claim 19), with 16 dependent claims providing layered fallback. The 4 drawing sheets cover system topology (FIG. 1), computing device hardware (FIG. 2), the core operational flowchart (FIG. 3), and the server-side assistant architecture (FIG. 4), providing adequate but lean figure coverage for the disclosed embodiments.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 4 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Conceptual diagram of system 100 showing computing device 110, digital assistant system 160, and search server system 180 communicating via network 130, with local and remote assistant modules 122A/122B.Search in Eureka ↗ | System architecture |
| FIG. 2 | Block diagram of computing device 210 detailing processors 240, user interface device 212, communication units 242, input/output components 244/246, and storage devices 248 containing assistant module 222, UI module 220, context module 230, and search module 282.Search in Eureka ↗ | System architecture |
| FIG. 3 | Flowchart illustrating operations 302–310: receive audio data representing spoken utterance, identify task, determine if complete performance exceeds threshold time, output synthesized voice data informing user of delay, and perform the task.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Block diagram of assistant server system 460 showing processors 440, communication units 442, storage devices 448 containing assistant module 422, search module 482, context module 430, and user information data store 424.Search in Eureka ↗ | System architecture |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent contains 3 independent claims: Claim 1 (system/apparatus), Claim 10 (method), and Claim 19 (non-transitory computer-readable storage medium — CRM), providing tripartite enforcement coverage. The dependent:independent ratio of approximately 5.33:1 is slightly below the Software/AI norm of 6–8:1, suggesting some coverage gaps in fallback positions. Notably, the claim strategy in this continuation narrows the threshold-detection trigger specifically to 'extensive machine learning models,' a deliberate prosecution distinction over the parent patents that used broader 'threshold amount of time' language.
Core inventive concept: The claims address the user experience problem of uncertainty when a computational assistant cannot immediately complete a task — specifically when the delay is caused by the task requiring 'extensive machine learning models' (Claim 1 body element). The solution mechanism is a proactive synthesized voice output that informs the user completion will not be immediate (triggering condition), followed by a second synthesized voice output confirming task completion once the extensive computation finishes.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A system comprising: | comprising | at least one processor; memory storing instructions; receive utterance representation directed to computing device; identify task for computational assistant; determine whether task involves extensive machine learning models; in response, cause synthesized voice data output informing user completion will not be immediate; subsequent to performing extensive computation, cause additional synthesized voice data output informing user task is completedSearch prior art ↗ |
| Claim 10 | A method implemented by one or more processors, the method comprising: | comprising | receiving input directed to computing device; identifying task for computational assistant at computing device; determining whether task involves extensive machine learning models; in response, causing data output at computing device informing user completion will not be immediate; subsequent to performing extensive computation, causing additional data output informing user task is completedSearch prior art ↗ |
| Claim 19 | A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform operations, the operations comprising: | comprising | receiving utterance representation directed to computing device; identifying task for computational assistant at computing device; determining whether task involves extensive machine learning models; in response, causing synthesized voice data output informing user completion will not be immediate; subsequent to extensive computation, causing additional synthesized voice data informing user task performance is completedSearch prior art ↗ |
Claim Dependency Tree
1 System: processor + memory; identify task; determine if extensive ML models involved; output delay notice; output completion noticeSearch Claim 1 prior art ↗
2 Adds: determine estimated amount of time for extensive computation; include estimated time in delay-notice voice dataSearch in Eureka ↗
3 Further: estimated time determined from historical times for tasks of same typeSearch in Eureka ↗
4 Adds: first utterance triggers delay notice; second utterance at later time requests status update; output status update voice dataSearch in Eureka ↗
5 Further: third utterance at later time requests halt/quit before computation completesSearch in Eureka ↗
6 Adds: task includes parameters; receive second utterance to modify parameters; modify computation based on modified parametersSearch in Eureka ↗
7 Adds: delay notice output at first time; second utterance at later time requests halt/quitSearch in Eureka ↗
8 Adds: determine context associated with computing device; task identification further based on contextSearch in Eureka ↗
9 Adds: extensive ML models hosted at server in communication with computing device; extensive computation performed at serverSearch in Eureka ↗
10 Method: receive input; identify task; determine if extensive ML models; output delay data; output completion dataSearch Claim 10 prior art ↗
11 Adds: determine estimated time for extensive computation; include estimated time in delay noticeSearch in Eureka ↗
12 Further: estimated time determined from historical times for same-type tasksSearch in Eureka ↗
13 Adds: delay notice output at first time; second time input requests status update; output status update dataSearch in Eureka ↗
14 Further: third time input requests halt/quit before computation completesSearch in Eureka ↗
15 Adds: task includes parameters; receive additional input to modify parameters; modify computation based on modified parametersSearch in Eureka ↗
16 Adds: delay notice output at first time; second time input requests halt/quit before computation completesSearch in Eureka ↗
17 Adds: determine context associated with computing device; task identification further based on contextSearch in Eureka ↗
18 Adds: extensive ML models hosted at server in communication with computing device; extensive computation performed at serverSearch in Eureka ↗
19 CRM: receive utterance; identify task; determine if extensive ML models; output delay voice data; output completion voice dataSearch Claim 19 prior art ↗
| Metric | This Application | Software / AI Industry Norm |
|---|---|---|
| Total claims | 19 | 15 – 25 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.33 : 1 | 5 – 8 : 1 |
| Method claims present? | Yes — Claim 10 | Common |
| System / apparatus claims? | Yes — Claim 1 | 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 strong tripartite coverage (Claims 1, 10, 19) and a well-supported specification that ties the core delay-notification mechanism to FIG. 3's operational flowchart and the detailed description at pages 7–19. The principal weakness is the narrow 'extensive machine learning models' trigger limitation in all three independent claims — a prosecution-driven narrowing over parent patents that creates a meaningful design-around corridor for competitors using rule-based or threshold-time-only approaches.
✅
Antecedent Basis
The claim set maintains clean antecedent basis throughout the 19 claims. In Claim 1, 'the at least one processor' and 'the computing device' are properly introduced in the preamble/body before being referenced with 'the' in subsequent limitations. Claim 4's reference to 'a second time' and 'the first time' correctly uses indefinite then definite article sequencing. No orphaned 'the [element]' references were identified across the dependent claims chain.
✅
Spec–Claim Consistency
The three independent claim limitations map cleanly to specific spec passages. The 'extensive machine learning models' limitation is supported at spec pages 7–8 (discussing tasks not eligible for immediate performance, including those requiring extensive computation/machine learning). FIG. 3 (operations 302–310) directly tracks the sequential steps of Claims 10 and 19. The 'subsequent to the computational assistant performing the extensive computation' completion-notice limitation maps to operation 310 and the detailed description at page 18, col. 2.
✅
Transition Word Usage
All independent claims use 'comprising' as the transition, which is appropriate for software/AI claims because it leaves open the possibility of additional steps or components not recited. This is strategically optimal for Claims 1, 10, and 19, as competitors cannot avoid infringement by adding further notification steps. No claim uses 'consisting of' or 'consisting essentially of,' which would have unnecessarily narrowed scope. The choice is well-calibrated for the enforcement context.
⚠️
§112(f) Means-Plus-Function Risk
Claim 18 in the specification examples (not a numbered claim but an 'Example 18' in the detailed description) uses 'means for performing the method' language — however, this is in the example section, not the formal claims. In the formal claims, no 'means for' language appears. The functional language 'cause the at least one processor to perform operations' in Claim 19 is standard CRM drafting and is not a §112(f) trigger under current USPTO practice because it is directed to a processor, not a 'means.' No §112(f) exposure identified in the formal claims.
⚠️
§101 Eligibility Risk
The claims carry moderate Alice/Mayo exposure because the core inventive concept — detecting task complexity and outputting a notification — could be framed as an abstract idea (mental process/organizing human behavior). The hardware tie-in is present but modest: Claim 1 recites 'at least one processor' and 'memory,' and the output is via 'speakers operably connected to the computing device.' The 'extensive machine learning models' trigger provides the strongest §101 defense by tethering the claim to a specific computational process, but an examiner could still argue the ML models are not structurally defined. Claims 9 and 18 (server-hosted ML models) add the most concrete hardware specificity as fallback positions.
✅
Dependent Claim Fallback Quality
The dependent claims add genuinely distinct limitations across four functional axes: time-estimation (Claims 2–3, 11–12), status-update interaction (Claims 4–5, 13–14), task-modification mid-execution (Claims 6, 15), and context-awareness (Claims 8, 17). Claims 9 and 18, adding the server-hosted ML model limitation, are particularly valuable as they provide a narrower fallback that also strengthens §101 positioning. The parallel structure between Claims 1–9 and Claims 10–18 creates redundancy rather than unique fallback for the method claims, which slightly diminishes overall fallback quality.
⚠️
Abstract Quality
The abstract accurately describes the method-claim embodiment but omits the novel 'extensive machine learning models' trigger — the key prosecution distinction over parent patents. An examiner reading only the abstract would characterize the invention as a generic 'virtual assistant delay notification' system, missing the specific ML-computation trigger that distinguishes this continuation from US 11,521,037 and US 11,790,207. The abstract states 'responsive to determining...that complete performance of the task will take more than a threshold amount of time,' which reflects the parent claim language rather than the narrowed continuation claim language.
✅
Figure Support Quality
FIG. 3 directly supports the core sequential claim limitations in Claims 10 and 19 (operations 302–310: receive audio, identify task, threshold check, output delay voice, perform task). FIG. 1 supports the 'computing device' and 'speakers operably connected' limitations in all independent claims. FIG. 2 supports the 'at least one processor' and 'memory' elements of Claim 1. The 'extensive machine learning models' trigger limitation is described in the specification but has no dedicated figure illustrating the ML model architecture — a minor gap that does not create §112(a) risk but would strengthen the disclosure.
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.8
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3.5
Claim Type Diversity
4.5
Figure Support Quality
3.6
Key observation: Claim Type Diversity scores highest (4.5/5.0) because the tripartite system/method/CRM structure of Claims 1, 10, and 19 provides comprehensive enforcement coverage across all deployment formats for AI assistant technology. Claim Breadth scores lowest (3.2/5.0) because the 'extensive machine learning models' trigger — a continuation narrowing over parent US 11,790,207 — excludes rule-based and threshold-time-only assistant implementations, creating a clear design-around path for competitors. Practitioners analyzing this patent for FTO should note that the parent patents (US 11,521,037, US 11,790,207, US 11,048,995) may present a stronger claim set for licensing scenarios.
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 broader delay-trigger claim scope Missing dedicated assistant hardware claims Indefinite 'extensive' ML model threshold term
Unlock Full Analysis — Free Frequently asked questions
US 12,141,672 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