Patent Drafting Analysis of Glean Technologies’ Generative AI Search Summarization System | US 2024/0256582 A1
Patent Drafting Analysis of Glean Technologies' Generative AI Search Summarization System | US 2024/0256582 A1
A structural and strategic analysis of Glean Technologies' enterprise search patent covering claim architecture, latency-adaptive prompt engineering, §101 eligibility risk, dependent claim fallback quality, and prosecution positioning for AI-generated search summaries.
Spec Words
9,200
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
15
System architecture, UI mockups, process flowcharts
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 (~5,800 of ~9,200), providing extensive embodiment coverage for the generative AI summarization pipeline, latency management, and permissions-aware ranking. The claim set comprises 20 claims — 3 independent (system, method, CRM) — with a strong 5.67:1 dependent-to-independent ratio. Fifteen figure sheets cover networked system topology (FIG. 1), search architecture variants (FIGS. 2A–2D), mobile UI screenshots (FIGS. 3A–3G), and three distinct process flowcharts (FIGS. 4A–4C), providing broad visual support for the core embodiments.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 15 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Depicts a networked computing environment 100 showing data sources 140, search and knowledge management system 120, server 160, and computing device 154 connected via networks 180.Search in Eureka ↗ | System architecture |
| FIG. 2A | Shows one embodiment of search and knowledge management system 220 with search index 204, query and response path 246, ranking path 244, data ingestion path 242, and data sources 240 including documents 250 and messages 252.Search in Eureka ↗ | System architecture |
| FIG. 2B | Depicts a detailed embodiment of system 220 with knowledge assistant 214, query and response handler 216, ranking modification pipeline 222, document builder pipeline 206, indexer 208, content connector handlers 209, and identity connector handlers 211.Search in Eureka ↗ | System architecture |
| FIG. 2C | Illustrates the layered software and hardware architecture of system 220 including data ingestion path 242, ranking path 244, query and response path 246, answer generation controller 248, virtualization layer with virtual machine 273 and container engine 275, and hardware layer with processor 270, memory 271, and disk 272.Search in Eureka ↗ | System architecture |
| FIG. 2D | Shows another embodiment of system 220 featuring answer generation controller 248 with prompt generator 278, machine learning model trainer 281, machine learning models 282, training data generator 283, and training data 284 running on distributed machines 280 and 290.Search in Eureka ↗ | System architecture |
| FIG. 3A | Mobile device 302 UI screenshot showing search query "Gleanbot custom emoji" entered in search bar 312, displaying summary of search results 323 with result #1 (324) and result #2 (325) for user Mariel Hamm (314).Search in Eureka ↗ | UI/interface |
| FIG. 3B | Mobile device 302 UI depicting updated search results showing query phrase 322, summary 323, with pin icon 341 and star icon 340 for user feedback on result #2 (325), and downvote control 345.Search in Eureka ↗ | UI/interface |
| FIG. 3C | Mobile device 302 UI showing a disclosed prompt 327 used to generate the query phrase 321, prompt 328 used to generate summary 333 of search results, and a single result #1 (324), illustrating the prompt engineering pipeline.Search in Eureka ↗ | UI/interface |
| FIG. 3D | Mobile device 302 UI showing a different user (Jeremy Lin, 316) with changed prompt 329, and a different summary 334 based on the same search query, illustrating user-identity-dependent prompt variation.Search in Eureka ↗ | UI/interface |
| FIG. 3E | Mobile device 302 UI showing daily summaries screen with summary of chat channel conversation 362 and summary of emails 364 received within the past 12 hours for user Jeremy Lin.Search in Eureka ↗ | UI/interface |
| FIG. 3F | Mobile device 302 UI showing a word processing document being edited, with auto-generated summary of text 341 displayed in a sidebar panel and prompt 345 used for generating the text summary, triggered by cursor location 342.Search in Eureka ↗ | UI/interface |
| FIG. 3G | Mobile device 302 UI showing source code editing view with auto-generated code summary 351 and corresponding prompt 355 used for summarizing the code, illustrating AI-assisted code comprehension.Search in Eureka ↗ | UI/interface |
| FIG. 4A | Flowchart of process for generating and displaying a summary of search results (steps 402–422), covering query acquisition, user ID identification, natural language phrase generation, search result ranking, prompt determination, summary generation, consistency detection, display, and canonical summary storage.Search in Eureka ↗ | Flow diagram |
| FIG. 4B | Flowchart of process for generating a summary triggered by document editing context (steps 442–462), covering location detection within a document or chat channel, text identification, query phrase generation, search, ranking, prompt determination, summary generation, consistency detection, display, and canonical summary assignment.Search in Eureka ↗ | Flow diagram |
| FIG. 4C | Flowchart of latency-adaptive summary generation process (steps 472–490), covering search query identification, search result generation and ranking, threshold user detection, maximum latency determination, maximum snippet size calculation, subset selection, answer summary generation using subset and snippet size, and storage.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 claim set contains 3 independent claims — Claim 1 (system), Claim 18 (method), and Claim 20 (CRM/storage device) — yielding a 5.67:1 dependent-to-independent ratio, which is moderately above the software/cloud norm and provides reasonable prosecution fallback. The tripartite structure (system/method/CRM) provides standard enforcement coverage across apparatus, process, and storage medium formats. Notably, Claim 18's method independent claim is narrower than Claim 1's system claim because it requires the threshold-user triggering condition as a core limitation rather than an optional dependent element.
Core inventive concept: The claims address the problem of high-latency AI summary generation for enterprise search by requiring the processor to "determine a latency for generating the answer summary" and "identify a subset of the set of search results based on the latency" before generating the summary — dynamically constraining the input to a generative model to meet response time requirements. This latency-adaptive subset selection, combined with prompt-guided GPT-style summarization and canonical summary storage for reuse, forms the technical core across Claims 1, 18, and 20.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A system, | comprising: | a storage device configured to store a prompt; one or more processors configured to: identify a search query, generate a set of search results, detect that an answer summary should be generated, determine a latency for generating the answer summary, identify a subset of the set of search results based on the latency, generate the answer summary using the subset and the prompt, store the answer summarySearch prior art ↗ |
| Claim 18 | A method for operating a search system, | comprising: | identifying a search query; generating a set of search results; detecting that an answer summary should be generated in response to detection that at least a threshold number of users have submitted a semantically similar search query; determining a maximum latency for generating the answer summary; determining a subset of the set of search results based on the maximum latency; generating the answer summary using the subset; storing the answer summary using a non-volatile storage deviceSearch prior art ↗ |
| Claim 20 | One or more storage devices containing processor readable code for configuring one or more processors to perform a method for operating a search system, | wherein | the processor readable code configures the processors to: generate a set of search results for a search query; detect that an answer summary should be generated; determine an estimated amount of time to generate the answer summary; identify a subset of the set of search results based on the estimated amount of time; generate the answer summary using the subset of the set of search results; display the answer summarySearch prior art ↗ |
Claim Dependency Tree
1 System: storage device + processors to identify search query, detect summary need, determine latency, subset search results, generate summary via prompt, store summarySearch Claim 1 prior art ↗
2 Adds: answer summary generated using a generative AI model with the prompt and subsetSearch in Eureka ↗
3 Adds: generative AI model comprises a generative pre-trained transformer modelSearch in Eureka ↗
4 Adds: detect at least threshold number of users submitted semantically similar search query to trigger summary generationSearch in Eureka ↗
5 Adds: determine a location within a document and identify the search query based on the locationSearch in Eureka ↗
6 Adds: determine maximum snippet size for search results based on latency and determine subset based on maximum snippet sizeSearch in Eureka ↗
7 Adds: cause the answer summary to be displayedSearch in Eureka ↗
8 Adds: input the subset and a text directive to generate the answer summary to a generative AI modelSearch in Eureka ↗
9 Adds: input the subset and a text directive to reference one or more search results used to generate the answer summary to a generative AI modelSearch in Eureka ↗
10 Adds: each search result comprises an electronic document verified by a document ownerSearch in Eureka ↗
11 Adds: determine estimated latency and determine number of search results comprising the subset based on estimated latencySearch in Eureka ↗
12 Adds: determine amount of time to generate and determine number of search results comprising subset based on the amount of timeSearch in Eureka ↗
13 Adds: determine amount of time and determine total amount of text for the subset based on the amount of timeSearch in Eureka ↗
14 Adds: detect that amount of time to generate exceeds threshold and generate the answer summary in the background while subset is displayedSearch in Eureka ↗
15 Adds: detect that amount of time using generative AI model exceeds threshold and generate summary in background while subset is displayedSearch in Eureka ↗
16 Adds: detect triggering condition and perform search using user permissions based on number of end users who submitted semantically similar queriesSearch in Eureka ↗
17 Adds: generate answer summary using first set of documents and generate second answer summary in background using larger second set of documentsSearch in Eureka ↗
18 Method: identify search query, generate results, detect threshold-user trigger, determine maximum latency, determine subset, generate answer summary, store using non-volatile storageSearch Claim 18 prior art ↗
19 Adds: generating the answer summary includes inputting subset to a generative pre-trained transformer modelSearch in Eureka ↗
20 CRM: storage devices with processor readable code to generate search results, detect summary need, determine estimated time, identify subset based on time, generate summary using subset, display summarySearch 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 18 | 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 architectural coverage through the tripartite system/method/CRM structure (Claims 1, 18, 20) and meaningful fallback through latency-specific dependent Claims 11–15, but carries substantial §101 Alice exposure because the core operative limitations in Claim 1 are entirely functional and software-implemented without hardware-specific structural anchoring. The most notable drafting weakness is that Claim 18 is substantively narrower than Claim 1 because it embeds the threshold-user triggering condition as a required element rather than reserving it for dependent Claim 4, creating an asymmetric independent claim set.
✅
Antecedent Basis
The antecedent basis is generally clean across the 20 claims. Each instance of "the answer summary" in dependent Claims 2–17 correctly traces back to "an answer summary" first introduced in Claim 1. Similarly, "the set of search results" in dependent claims correctly refers to antecedent "a set of search results" in the independent claim. No orphaned "the" references were identified across the claim set.
✅
Spec–Claim Consistency
The key limitations of Claim 1 have robust specification support. The latency-adaptive subset selection limitation maps directly to ¶[0019]–[0020] and FIG. 4C (steps 482–486). The prompt storage and usage limitation maps to FIG. 2D (prompt generator 278) and ¶[0061]. The canonical summary storage maps to ¶[0021]–[0022] and FIGS. 4A (step 422) and 4B (step 462). The threshold-user trigger in Claim 4 is supported by ¶[0022] and FIG. 4C (step 478).
✅
Transition Word Usage
All independent and dependent claims use "comprising" as the transition word, which is strategically appropriate for a software/AI system claim because it leaves the door open for claim coverage of systems with additional components. No missed opportunities for "consisting essentially of" are identified because the open-ended "comprising" transition maximises claim breadth against infringers who add supplemental features.
⚠️
§112(f) Means-Plus-Function Risk
No explicit "means for" or "step for" language appears in any claim. However, Claim 1's processor limitations — particularly "detect that an answer summary for the set of search results should be generated" and "identify a subset of the set of search results based on the latency" — are purely functional without structural definition of the detection or selection algorithm. Under §112(f) scrutiny, courts may interpret these as functional claim limitations requiring the specification to define corresponding structure, limiting the claim to the specific embodiments described in ¶[0019]–[0022].
⚠️
§101 Eligibility Risk
Claim 1 faces significant Alice/Mayo exposure: the core concept — generating a text summary of search results using a stored prompt within a latency budget — is arguably an abstract idea (mental process of summarizing information) implemented on generic processor hardware. The hardware tie-in in Claim 1 recites only generic "storage device" and "one or more processors," which the USPTO and courts consistently hold insufficient to provide a meaningful §101 defense under step 2B. The strongest §101 arguments reside in dependent Claim 6 (latency-driven snippet size optimization) and Claims 14–15 (background generation while results are displayed), which add a more concrete technical improvement to computer performance, but these are not present in the independent claims.
✅
Dependent Claim Fallback Quality
The dependent claims provide genuinely layered fallback positions across multiple dimensions. Claims 11–13 add distinct latency-quantification mechanisms (estimated latency → subset count, time → subset count, time → total text amount), each representing a separate and non-obvious fallback. Claims 14–15 add the valuable background-generation-while-displaying limitation that provides a strong technical improvement argument. Claims 4 and 16 add the threshold-user triggering condition as a distinct triggering mechanism fallback. Weaker contributions are found in Claim 7 (merely adds "cause the answer summary to be displayed," a trivially obvious extension already implied by the core system).
⚠️
Abstract Quality
The abstract accurately describes the high-level function — using GPT-style generative AI to summarize search results in an enterprise knowledge management system — but omits the novel technical mechanism that distinguishes the invention: the latency-adaptive subset selection that dynamically constrains the input to the generative model based on response time requirements. An examiner reading only the abstract would likely classify this as a generic "AI search summary" application and miss the latency-budget-constrained prompt engineering mechanism central to Claims 1, 6, and 11–13.
✅
Figure Support Quality
The 15 figure sheets provide strong overall coverage. FIG. 4C directly maps to the latency-adaptive subset selection steps of Claim 1, FIG. 2D supports the prompt generator and machine learning model limitations, and FIGS. 3A–3G support the display and UI limitations. One minor gap: Claim 9's limitation — inputting a text directive to "reference one or more search results that were used to generate the answer summary" — lacks a dedicated figure showing the citation/referencing output, though FIG. 3C's prompt 328 partially addresses it.
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
4.1
Dependent Claim Coverage
3.8
Claim Type Diversity
4.5
Figure Support Quality
4
Key observation: Claim Type Diversity scores highest (4.5/5.0) because the filing deploys all three commercially critical claim formats — system (Claim 1), method (Claim 18), and CRM (Claim 20) — ensuring enforcement coverage across manufacturing, use, and distribution channels without gaps. Prosecution Defensibility scores lowest (2.8/5.0) because the independent claims lack the hardware-specific structural limitations or technical-problem-improvement framing needed to survive an Alice rejection at step 2B, and the most defensible §101 arguments (latency-constrained background generation in Claims 14–15) are buried in dependent claims. Practitioners filing continuations should consider elevating the latency-adaptive background generation mechanism of Claims 14–15 into an independent claim to create a stronger §101-defensible fallback 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.
Missing §101 technical improvement language Method claim narrower than system claim No claims on document-editing trigger embodiment
Unlock Full Analysis — Free Frequently asked questions
US 2024/0256582 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