Patent Drafting Analysis of Pure Storage’s AI Acceleration Storage and Compute System | US 10,467,527 B1
Patent Drafting Analysis of Pure Storage's AI Acceleration Storage and Compute System | US 10,467,527 B1
A structural and strategic analysis of Pure Storage's granted patent covering distributed key value stores for AI inference acceleration. Examines claim architecture, drafting quality, critical gaps, and prosecution positioning across apparatus, method, and CRM claim types.
Spec Words
13,200
Across 6 sections
Draft now ↗
Total Claims
19
3 independent · 16 dependent
Draft now ↗
Figure Sheets
17
Storage architecture, AI pipeline, flow diagrams
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 83% of total spec words (~10,920 words), reflecting a heavyweight infrastructure disclosure that covers storage arrays, cluster architecture, authority-based metadata management, and AI pipeline design. The patent presents 19 claims across 3 independent claims (apparatus, method, and CRM), yielding a 5.33:1 dependent-to-independent ratio that sits at the lower end for software/storage patents. The 17 drawing sheets provide comprehensive hardware and flow diagram coverage, anchoring both the storage cluster embodiments and the AI-specific inference and vector search operations.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 17 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1A | First example system for data storage showing dual storage arrays (102A, 102B) with controllers (110A–110D), storage drives (171A–171F), SAN 158, LAN 160, and computing devices (164A, 164B).Search in Eureka ↗ | System architecture |
| FIG. 1B | Internal block diagram of storage array controller 101 showing processing device 104, RAM 111 with OS 112 and instructions 113, host bus adapters 103A–103C, switch 116, and expander 115.Search in Eureka ↗ | System architecture |
| FIG. 1C | Third example storage system 117 showing dual PCI flash storage device 118 with storage device controller 119, flash memory devices 120a–120n, RAM 121, and stored energy device 122.Search in Eureka ↗ | Key embodiment |
| FIG. 1D | Fourth example storage system 124 with dual storage controllers 125a, 125b each connected to dual PCI storage devices 119a–119d and host computers 127a–127n via storage network 130.Search in Eureka ↗ | System architecture |
| FIG. 2A | Perspective view of storage cluster 161 showing chassis 138 with multiple blade slots 142, storage nodes 150, switch fabric 146, and fans 144 providing network-attached storage.Search in Eureka ↗ | Key embodiment |
| FIG. 2B | Block diagram of communications interconnect 171 and power distribution bus 172 coupling multiple storage nodes 150, showing authorities 168, external ports 174 and 176, and external power port 178.Search in Eureka ↗ | System architecture |
| FIG. 2C | Multi-level block diagram of storage node 150 and non-volatile solid state storage 152 showing CPU 156, NIC 202, NVRAM 204, flash memory 206, PLD 208 with I/O 210, controller 212, DMA 214, DRAM 216, energy reserve 218, flash dies 222, 16KB pages 224.Search in Eureka ↗ | Key embodiment |
| FIG. 2D | Storage server environment showing hierarchical controller structure with host controller 242, mid-tier controller 244, and dual storage units 152 each with SU controller 246, NVRAM 204, and flash 206.Search in Eureka ↗ | System architecture |
| FIG. 2E | Blade hardware block diagram showing control plane 254, compute plane 256, storage plane 258, authorities 168, flash 206, NVRAM 204, and partitions 260 across multiple blades 252 in storage cluster 161.Search in Eureka ↗ | Claim support |
| FIG. 2F | Elasticity software layers in blades 252 showing symmetric three-layer structure: compute modules 270, storage manager 274, endpoints 272, and authorities 168 interacting across fabric switch 146.Search in Eureka ↗ | Key embodiment |
| FIG. 2G | Authorities 168 and storage resources across blades 252 showing NVRAM writes triple-mirrored and RAID stripes spanning blades, with flash 206 and NVRAM 204 per blade.Search in Eureka ↗ | Claim support |
| FIG. 3A | High-level diagram of storage system 306 coupled for data communications with cloud services provider 302 via data communications link 304.Search in Eureka ↗ | Other |
| FIG. 3B | Storage system 306 internal components diagram showing storage resources 308, communications resources 310, processing resources 312, and software resources 314 as four discrete layers.Search in Eureka ↗ | System architecture |
| FIG. 4 | Storage cluster 161 with distributed metadata indexes 402 showing authorities 168, distributed key value store 404 for authorities and data, distributed key value store 406 for vectors, and unstructured data 408 — directly supporting Claim 1's core elements.Search in Eureka ↗ | Claim support |
| FIG. 5 | Further distributed resources in storage cluster 161 showing distributed compute resources 502, distributed inference engine 504, distributed delete 506, and RDMA 508 layers across blades 252.Search in Eureka ↗ | Claim support |
| FIG. 6 | AI search 608 flow through vectors showing example 602, vector 618, hash function 604, hash value 606, vector index 610, full vectors 612, data index 614, authorities 168, and unstructured data 408 with examples 616.Search in Eureka ↗ | Claim support |
| FIG. 7 | Search 714 through vectors 706 forming bucket views 708 with links 710 to examples 616 in unstructured data 408, showing similarity predicate 712, metadata 704, and bucket(s) 702.Search in Eureka ↗ | Claim support |
| FIG. 8 | Tag search showing tags 802 processed through tag index 804 via search 806 to produce list of examples 808 satisfying a predicate.Search in Eureka ↗ | Claim support |
| FIG. 9 | Four-step flow diagram of AI acceleration method: action 902 (establish first KV store for authority metadata), 904 (establish second KV store for vectors), 906 (search vectors), 908 (access examples through authorities).Search in Eureka ↗ | Flow diagram |
| FIG. 10 | Seven-step AI process flow diagram: actions 1002 (access data via authorities), 1004 (run deep learning inference), 1006 (generate vectors), 1008 (store vectors in KV store), 1010 (receive object/file), 1012 (run similarity search), 1014 (output response and bucket view).Search in Eureka ↗ | Flow diagram |
| FIG. 11 | Exemplary general-purpose computing device diagram showing CPU 1101, memory 1103, bus 1105, mass storage 1107, input/output device 1109, and display 1111.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 presents 3 independent claims covering apparatus (Claim 1), method (Claim 8), and computer-readable media/CRM (Claim 14), providing full tripartite enforcement coverage. The 16 dependent claims yield a 5.33:1 ratio, which is moderate for the distributed storage/AI software IPC class and below the ideal 7–9:1 ratio that would provide stronger prosecution fallback laddering. A notable strategic feature is that all three independent claims share nearly identical body elements, creating parallel enforcement vectors but also reducing the additive fallback value of the dependent chain.
Core inventive concept: The patent addresses the bottleneck of data movement in AI pipelines by integrating deep learning inference directly within a distributed storage and compute system — specifically, distributed compute resources that can "access, through a plurality of authorities, data in the solid-state memory, run inference with a deep learning model, generate vectors for the data and store the vectors in the key value store" (Claim 1), eliminating the need to move data externally. The dual key value store architecture — one for authority metadata and one for generated vectors — is the structural mechanism enabling locality-preserving vector search and bucket view generation without data egress.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | An apparatus for artificial intelligence acceleration | comprising | storage and compute system with distributed redundant key value store for metadata; distributed compute resources configurable to access data through plurality of authorities in solid-state memory; run inference with deep learning model; generate vectors; store vectors in key value store; store metadata for buckets; create bucket views with links to objects in solid-state memorySearch prior art ↗ |
| Claim 8 | A method for artificial intelligence acceleration, performed by a storage and compute system | comprising | accessing data through plurality of authorities; performing inference with deep learning model; generating vectors for data; storing vectors in key value store; storing metadata for buckets containing examples in unstructured data; generating bucket views containing links to examplesSearch prior art ↗ |
| Claim 14 | A tangible, non-transitory, computer-readable media having instructions thereupon which, when executed by a processor, cause the processor to perform a method | comprising | accessing data through plurality of authorities; performing inference with deep learning model; generating vectors for data based on performing; storing vectors in key value store; storing metadata for buckets containing examples in unstructured data; generating bucket views containing links to examplesSearch prior art ↗ |
Claim Dependency Tree
1 Apparatus: storage and compute system with distributed KV store, distributed compute resources for inference, vector generation, and bucket view creationSearch Claim 1 prior art ↗
2 Adds: network port for receiving object/file, running inference on it, outputting responseSearch in Eureka ↗
3 Adds: storage capacity sufficient to hold all data for inference throughout entire data pipelineSearch in Eureka ↗
4 Adds: authorities configurable for distributed file deletion per data identifiers owned by each authoritySearch in Eureka ↗
5 Adds: links satisfy similarity predicate based on vectors in key value storeSearch in Eureka ↗
6 Adds: compute resources for computing vector of object, performing hash, searching KV store within specified distance, retrieving full vectors using locality-preserving hashSearch in Eureka ↗
7 Adds: compute resources for receiving tags and generating list/count of data entities satisfying a predicateSearch in Eureka ↗
8 Method: accessing data through authorities; inference with deep learning model; generating and storing vectors; storing bucket metadata; generating bucket views with linksSearch Claim 8 prior art ↗
9 Adds: receiving object or file; performing inference for object/file based on vectors in KV storeSearch in Eureka ↗
10 Adds: outputting response based on inferenceSearch in Eureka ↗
11 Adds: system configurable to write and receive unstructured data into solid state memorySearch in Eureka ↗
12 Adds: key value store is distributed across storage nodes of the systemSearch in Eureka ↗
13 Further: (depends on Claim 9) links to examples satisfy similarity predicate based on search of vectorsSearch in Eureka ↗
14 CRM: tangible non-transitory media for method of accessing data through authorities; inference; vector generation and storage; bucket metadata; bucket views with linksSearch Claim 14 prior art ↗
15 Adds: receiving object/file; performing inference based on vectors in KV storeSearch in Eureka ↗
16 Adds: outputting response based on inferenceSearch in Eureka ↗
17 Adds: system configurable to write and receive unstructured data into solid state memorySearch in Eureka ↗
18 Adds: key value store is distributed across storage nodes of the systemSearch in Eureka ↗
19 Adds: links to examples satisfy similarity predicate based on search of vectorsSearch in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 19 | 15 – 25 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.33 : 1 | 5 – 9 : 1 |
| Method claims present? | Yes — Claim 8 | 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 patent demonstrates strong structural coverage through its tripartite independent claim format and extensive figure support for the AI inference pipeline (FIGs. 4–10 map directly to Claim 1 limitations), but exhibits notable weaknesses in dependent claim differentiation — Claims 10/16 and 11/17 are near-identical mirror pairs across the method and CRM tracks, adding minimal fallback value. The absence of specific hardware quantification in Claim 1's preamble is a double-edged choice: broad but potentially vulnerable to §101 challenge given the functional nature of the "configurable to" language.
✅
Antecedent Basis
Antecedent basis is generally clean across the 19 claims. Claim 2 correctly references "the storage and compute system" introduced in Claim 1, and Claims 9 and 15 correctly reference "the deep learning model" and "the key value store" from their parent independent claims. Claim 13's reference to "the links to the examples" traces back properly through Claim 9 to Claim 8's "bucket views containing links to the examples." No orphaned "the [element]" references were identified in the claim set.
✅
Spec–Claim Consistency
FIG. 4 and the corresponding specification text at column 37–38 map directly to Claim 1's dual key value store limitation (stores 402/404 for authorities and 406 for vectors). FIG. 5 supports the "distributed compute resources" and "distributed inference engine" elements in Claims 1 and 8. FIGs. 6 and 7 support the vector search and bucket view limitations in Claims 6 and 5. FIG. 9 (steps 902–908) maps precisely to Claim 8's method steps. The written description provides sufficient support for all independent claim limitations.
✅
Transition Word Usage
All three independent claims use "comprising," the broadest open-ended transition, which is strategically appropriate for a platform patent of this scope — it prevents competitors from designing around by adding an element. The dependent claims uniformly use "further comprising" and "wherein," which are correctly chosen to add limitations without narrowing the base claim beyond what is required. No instances of "consisting of" or "consisting essentially of" were used, which is correct given the broad system architecture being claimed.
⚠️
§112(f) Means-Plus-Function Risk
While the patent expressly disclaims §112(f) invocation through the "configured to" / "configurable to" language — and the spec at column 43 explicitly states these phrases are "expressly intended not to invoke 35 U.S.C. 112, sixth paragraph" — the functional recitation of "distributed compute resources configurable to" perform a long sequence of AI operations in Claim 1 may still attract examiner scrutiny. The risk is that without specific structural identification of what hardware constitutes "distributed compute resources," a challenger could argue insufficient structural disclosure for the inference and vector generation functions. The specification does identify CPUs, FPGAs, GPUs, and custom ASICs as potential compute resources (col. 38), which provides reasonable support but the claim language itself is purely functional.
⚠️
§101 Eligibility Risk
Claim 1's apparatus claim provides the strongest §101 defense — it recites a "storage and compute system" with solid-state memory, distributed key value stores, and a plurality of authorities, tying the abstract AI concept to specific hardware infrastructure. However, Claims 8 and 14 are more vulnerable: the method and CRM claims recite software-performed steps (inference, vector generation, bucket view generation) without mandatory hardware tie-ins within the independent claim body. Under Alice/Mayo step two, an examiner could argue that storing vectors and generating bucket views are abstract data manipulation steps, and the hardware elements appear only in dependent Claims 11/17 and 12/18, not in the independent claims themselves. A stronger filing would have incorporated at least one hardware recitation (e.g., "by distributed compute resources of the storage system") into Claims 8 and 14.
⚠️
Dependent Claim Fallback Quality
The dependent claim structure suffers from systematic mirroring: Claims 9/15 are near-identical (both add receiving object/file and running inference), Claims 10/16 both add only "outputting a response," Claims 11/17 both add solid-state memory writability, and Claims 12/18 both add the distributed nature of the KV store. This mirroring means 8 of 16 dependent claims add no unique technical limitations beyond what their parallel independent claim already covers elsewhere. Claims 6 and 7 (under Claim 1) are the strongest dependent claims — Claim 6 adds the locality-preserving hash vector search mechanism and Claim 7 adds tag-based predicate filtering, both providing genuinely distinct fallback positions.
⚠️
Abstract Quality
The abstract accurately describes the apparatus embodiment — "The apparatus includes a storage and compute system having a distributed, redundant key value store for metadata" — and mentions running inference, generating vectors, and storing vectors in the key value store. However, the abstract omits the bucket view and bucket metadata limitation that constitutes a key distinguishing feature of Claim 1 over prior distributed storage systems. An examiner reading only the abstract would correctly identify the key value store and inference elements but might miss the bucket view mechanism, potentially leading to an inadequate prior art search scope in the vector search and object-linking aspects of the claimed invention.
✅
Figure Support Quality
The 17-figure set provides excellent structural coverage. FIG. 4 specifically names and illustrates the "Distributed Key Value Store for Authorities, Data" (402) and "Distributed Key Value Store for Vectors" (404/406) from Claim 1's preamble. FIG. 5 illustrates the "distributed compute resources" (502) and "distributed inference engine" (504) from the body of Claim 1. FIGs. 6 and 7 directly support Claims 5 and 6 (similarity predicate and locality-preserving hash search). The only notable gap is that no figure specifically illustrates the training of a new deep learning model using bucket view content, which is mentioned as an optional method step in the specification but not captured in the figures.
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.8
Prosecution Defensibility
3.2
Spec–Claim Consistency
4.3
Dependent Claim Coverage
2.8
Claim Type Diversity
4.5
Figure Support Quality
4.2
Key observation: This patent scores highest on Claim Type Diversity (4.5/5.0) — the tripartite apparatus/method/CRM structure provides comprehensive enforcement coverage across all deployment modalities, which is particularly valuable for a platform patent in the cloud storage AI acceleration space. The weakest dimension is Dependent Claim Coverage (2.8/5.0), caused by the systematic mirroring of Claims 9–12 under Claim 8 with near-identical counterparts 15–18 under Claim 14, leaving only Claims 4–7 under Claim 1 as genuinely differentiated fallback positions. Practitioners should note that in any inter partes review proceeding, the mirrored dependent claims would not provide independent validity lifelines if the corresponding independent claim limitation is challenged.
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.
Method/CRM claims lack hardware anchor No claims on distributed inference engine Locality-preserving hash in single dependent only
Unlock Full Analysis — Free Frequently asked questions
US 10,467,527 B1 — 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