Patent Drafting Analysis of Maplebear Inc.’s LLM-Based Item Replacement Generation | US 2024/0362696 A1
Patent Drafting Analysis of Maplebear Inc.'s LLM-Based Item Replacement Generation | US 2024/0362696 A1
A structural and strategic analysis of Maplebear's patent covering LLM-driven replacement item explanation in online concierge systems, examining claim architecture, drafting quality, §101 exposure, and prosecution positioning.
Spec Words
6,200
Across 7 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
4
System environment, architecture, process flowchart
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 51% of total words (~3,900 of ~7,550 estimated words), with the claims section representing a substantial 26%, reflecting a claim-heavy filing strategy appropriate for a software patent. The patent presents 20 claims across 3 independent claims — one method (Claim 1), one computer-readable medium (Claim 9), and one computer system (Claim 17) — yielding a 5.67:1 dependent-to-independent ratio. Figure coverage is limited to 4 sheets across 5 distinct figures (FIG. 1A, FIG. 1B, FIG. 2, FIG. 3), concentrating on high-level system architecture and a single process flowchart with no detailed component-level diagrams.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 4 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1A | Illustrates the distributed system environment showing Client Devices 100 and 110, Third-Party Computing System 120, Network 130, Online System 140, Model Serving System 150, and Interface System 160 as separate networked entities.Search in Eureka ↗ | System architecture |
| FIG. 1B | Illustrates an alternative system environment where Model Serving System 150 and Interface System 160 are embedded within Online System 140, rather than as separate external entities.Search in Eureka ↗ | System architecture |
| FIG. 2 | Illustrates the internal architecture of Online Concierge System 140 showing Data Collection Module 200, Content Presentation Module 210, Replacement Module 225, Machine-Learning Training Module 230, and Data Store 240.Search in Eureka ↗ | Key embodiment |
| FIG. 3 | Flowchart depicting the end-to-end process (steps 300–380) for determining item unavailability, evaluating replacement quality score against a threshold, generating an LLM prompt for poor replacements, receiving the explanation, and sending it to the client device.Search in Eureka ↗ | Flow diagram |
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 (method), Claim 9 (non-transitory computer-readable storage medium/CRM), and Claim 17 (computer system), providing tripartite enforcement coverage. The 17 dependent claims yield a 5.67:1 dependent-to-independent ratio, which is above the typical 4–5:1 norm for software/AI-heavy G06Q filings and reflects a deliberate strategy to create layered fallback positions. Notably, Claims 2–8 mirror Claims 10–16 and Claims 18–20 in parallel dependent structures across all three independent claim types, which maximises coverage but reduces the breadth of genuinely distinct fallback positions.
Core inventive concept: The claims address the problem of poor-quality item substitutions in online grocery/concierge systems by combining a threshold-based replacement score evaluation with LLM-generated natural language explanations — specifically, when a replacement item's score falls below a threshold value, a prompt is generated and provided to a machine learning based language model, which returns an explanation of why the second item has the replacement score below the threshold value, and that explanation is sent to a client device. This conditional LLM invocation tied to a replacement quality threshold — rather than always generating LLM explanations — is the specific mechanism claimed across all three independent claims.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method comprising: at a computer system comprising a processor and a computer-readable storage medium | comprising | receiving a request for a first item; identifying first item unavailability; identifying second item as replacement; identifying replacement score for second item; identifying score below threshold value indicating below-threshold quality; generating a prompt requesting explanation of reason score is below threshold; providing prompt to machine learning based language model; receiving response comprising explanation; sending response to client deviceSearch prior art ↗ |
| Claim 9 | A non-transitory computer readable storage medium, storing instructions that when executed by one or more computer processors cause the one or more computer processors to perform steps | comprising | receiving request for first item; identifying first item unavailability; identifying second item as replacement; identifying replacement score; identifying score below threshold indicating below-threshold quality; generating prompt requesting explanation; providing prompt to LLM; receiving response comprising explanation; sending response to client deviceSearch prior art ↗ |
| Claim 17 | A computer system comprising: one or more computer processors; and a non-transitory computer readable storage medium storing instructions that when executed by one or more computer processors cause the one or more computer processors to perform steps | comprising | receiving request for first item; identifying first item unavailability; identifying second item as replacement; identifying replacement score; identifying score below threshold; generating prompt requesting explanation; providing prompt to LLM; receiving response comprising explanation; sending response to client deviceSearch prior art ↗ |
Claim Dependency Tree
1 Method: computer system receives item request, identifies unavailability, scores replacement, generates LLM prompt if below threshold, sends explanation to clientSearch Claim 1 prior art ↗
2 Adds: receiving image of second item; using image to identify explanation of below-threshold replacement scoreSearch in Eureka ↗
3 Further: prompt sent to LLM comprises the image; LLM generates response based on information including imageSearch in Eureka ↗
4 Further: OCR performed on image to extract text; prompt comprises extracted text; LLM generates response based on text from imageSearch in Eureka ↗
5 Further: ML model processes image to obtain features of second item; prompt comprises features; LLM generates response based on featuresSearch in Eureka ↗
6 Adds: prompt is first prompt, response is first response; method further generates second prompt for possible replacement items, sends to LLM, extracts replacement items from second responseSearch in Eureka ↗
7 Adds: prompt is first prompt; method generates second prompt for evaluation of second item as replacement, determines if second item is good replacement based on second responseSearch in Eureka ↗
8 Adds: response is first response, replacement score is first replacement score; identifies third item as replacement, identifies second replacement score above threshold, sends second response to client indicating third itemSearch in Eureka ↗
9 CRM: non-transitory computer readable storage medium — same core steps as Claim 1 in CRM formatSearch Claim 9 prior art ↗
10 Adds: receiving image of second item; using image to identify explanation (parallel to Claim 2)Search in Eureka ↗
11 Further: prompt comprises image; LLM generates response based on image (parallel to Claim 3)Search in Eureka ↗
12 Further: OCR on image extracts text; prompt comprises text (parallel to Claim 4)Search in Eureka ↗
13 Further: ML model processes image to extract features; prompt comprises features (parallel to Claim 5)Search in Eureka ↗
14 Adds: prompt is first prompt; generates second prompt for possible replacements; extracts replacement items (parallel to Claim 6)Search in Eureka ↗
15 Adds: second prompt for evaluation; determines if second item is good replacement (parallel to Claim 7)Search in Eureka ↗
16 Adds: identifies third item with second replacement score above threshold; sends second response to client (parallel to Claim 8)Search in Eureka ↗
17 Computer system: one or more processors + CRM — same core steps as Claim 1 in system formatSearch Claim 17 prior art ↗
18 Adds: generates second prompt for possible replacement items; extracts items from second response (parallel to Claim 6/14)Search in Eureka ↗
19 Adds: second prompt for evaluation; determines if second item is good replacement (parallel to Claim 7/15)Search in Eureka ↗
20 Adds: identifies third item with second replacement score above threshold; sends second response to client (parallel to Claim 8/16)Search in Eureka ↗
| 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 tripartite independent claim structure (method/CRM/system) is a drafting strength that provides multi-format enforcement coverage, and the threshold-conditioned LLM invocation in Claims 1, 9, and 17 is a concrete technical limitation that aids §101 defense. However, the near-identical parallel mirroring of Claims 2–8 across all three independent claims (as Claims 10–16 and 18–20) means the dependent claim set adds limited genuinely distinct fallback — a significant drafting weakness that leaves the claim set vulnerable if the independent claims are invalidated.
✅
Antecedent Basis
Antecedent basis is consistently maintained throughout Claims 1–20. The claim elements follow proper introduction-then-reference patterns: "a first item" is introduced before "the first item," "a second item" before "the second item," and "a replacement score" before "the replacement score." No orphaned "the" references were identified across any of the 20 claims, including the parallel dependent structures in Claims 2–8, 10–16, and 18–20.
✅
Spec–Claim Consistency
The core independent claim limitations map directly to specific spec paragraphs and figures. FIG. 3 (steps 300–370) directly supports the sequence of steps in Claim 1: step 300 maps to "identifying first item unavailability," step 320 maps to "identifying replacement score," step 330 maps to the threshold comparison, steps 340–360 map to prompt generation and LLM interaction, and step 370 maps to "sending the response." Paragraphs [0058]–[0064] provide the written description support for these limitations, and FIG. 2 supports the system architecture recited in Claims 9 and 17.
✅
Transition Word Usage
All three independent claims use "comprising" as the transition word, which is the maximally broad open-ended transition and appropriate for software method and system claims of this type. The dependent claims also consistently use "further comprising" or "wherein," both open-ended and strategically correct. Paragraph [0076] expressly states that "comprises," "comprising," and variations are intended to cover a non-exclusive inclusion, providing prosecution history support for this interpretation.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in any of the 20 claims, avoiding mandatory §112(f) invocation. The functional language used — such as "identifying," "generating," "providing," "receiving," and "sending" — is method-step or processor-executed instruction language rather than means-plus-function format. Claims 9 and 17 are structured as CRM and system claims respectively with sufficient structural recitation (processor + non-transitory storage medium) to avoid §112(f) concerns.
⚠️
§101 Eligibility Risk
Claims 1, 9, and 17 carry substantial Alice/Mayo exposure because the core process — receiving a request, scoring a replacement, and querying an LLM if the score is below a threshold — is abstract at its core and maps readily to the abstract idea of "evaluating quality and providing an explanation." The §101 defense rests on the hardware tie-in in Claim 1 ("at a computer system comprising a processor and a computer-readable storage medium") and in Claims 9 and 17, but examiners in Art Unit 3689 (G06Q) routinely discount such generic hardware recitations. The specification's lack of any claim to a specifically trained model, a particular threshold-setting mechanism, or a novel prompt structure weakens the "something more" argument significantly.
⚠️
Dependent Claim Fallback Quality
The dependent claim structure suffers from heavy parallel mirroring: Claims 2–8 depend from Claim 1 and introduce image-processing, OCR, feature extraction, multi-prompt, and fallback-replacement scenarios; Claims 10–16 exactly mirror Claims 2–8 under Claim 9; and Claims 18–20 partially mirror under Claim 17. This means no genuinely new technical limitation is introduced in the CRM or system branches — if Claims 2–8 fall in inter partes review, their mirrors fall with them. Claims 6 and 14 (LLM-generated candidate replacements) and Claims 8/16/20 (identifying a third item above threshold) are the strongest distinct fallback positions; Claims 3/11 and 4/12 (image-in-prompt and OCR variants) add meaningful technical specificity for multi-modal scenarios.
⚠️
Abstract Quality
An examiner reading only the abstract may identify the general mechanism but will miss critical prosecution-relevant limitations. The abstract accurately describes the threshold-based LLM invocation trigger and the explanation-generation function, stating "if the online system determines that the replacement item has a replacement score below a threshold value... it uses a machine learning based language model... to generate an explanation." However, the abstract omits the multi-modal image processing embodiments (Claims 2–5, 10–13), the iterative multi-prompt replacement-finding embodiment (Claims 6/14/18), and the fallback third-item scenario (Claims 8/16/20), all of which represent distinct claim branches.
⚠️
Figure Support Quality
FIG. 3 supports the core method steps of Claims 1, 9, and 17, and FIG. 2 supports the modular system architecture referenced in Claims 9 and 17. However, the multi-modal image-processing limitations in Claims 2–5 and 10–13 — including OCR processing of camera images and CNN-based feature extraction — have no dedicated figure support, relying solely on paragraphs [0066]–[0070]. Similarly, the iterative multi-prompt replacement-finding scenario in Claims 6, 14, and 18 is described in [0059]–[0063] but lacks a flowchart branch in FIG. 3, creating a written-description risk if these claims are examined independently.
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
2.8
Spec–Claim Consistency
3.5
Dependent Claim Coverage
2.5
Claim Type Diversity
4.2
Figure Support Quality
2.8
Key observation: The highest-scoring dimension is Claim Type Diversity (4.2/5.0) — the tripartite method/CRM/system structure across Claims 1, 9, and 17 provides comprehensive enforcement format coverage that is well above average for a software-only filing in G06Q. The lowest-scoring dimension is Dependent Claim Fallback Quality (2.5/5.0) — the nearly wholesale mirroring of Claims 2–8 as Claims 10–16 and the partial mirror as Claims 18–20 means that each independent claim branch lacks its own unique dependent claim innovations, leaving the patent vulnerable if the independent claims fall at trial. Practitioners prosecuting continuations should prioritise introducing genuinely novel technical limitations in the dependent branches — such as a specific scoring algorithm structure, training data characteristics, or prompt engineering constraints — rather than replaying the same image/OCR/feature tree under each independent claim.
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 modular system architecture claim Threshold value left entirely undefined in claims Multi-modal image path lacks standalone CRM claim
Unlock Full Analysis — Free Frequently asked questions
US 2024/0362696 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