Patent Drafting Analysis of IBM’s Privacy-Preserving Federated Learning | US 12,160,504 B2
Patent Drafting Analysis of IBM's Privacy-Preserving Federated Learning | US 12,160,504 B2
A structural and strategic analysis of IBM's granted patent on functional-encryption-based federated learning, covering claim architecture, drafting quality, critical gaps, and prosecution positioning across 20 claims.
Spec Words
7,200
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
8
System architecture, workflows, hardware block diagrams, 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 54% of total specification words (~3,900 of ~7,200), with the claims section forming a substantial 24% share at ~1,750 words — reflecting the intricate multi-clause dependent claim structure. The patent presents 20 claims (3 independent, 17 dependent) structured as a method claim (Claim 1), a CRM claim (Claim 8), and a system claim (Claim 15), providing tripartite coverage. Figure support spans 8 sheets covering system-level architecture, protocol workflows, and individual hardware block diagrams for each of the three major components (aggregator, key server, participant).
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 8 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | High-level system architecture showing the Key Server 105, Aggregator 110 with Aggregate Model 115, and multiple Participants 120A–120N each holding a Local Model 125, with bidirectional communication links.Search in Eureka ↗ | System architecture |
| FIG. 2 | Sequence diagram (workflow 200) illustrating the encryption key provisioning process: Key Server defines parameters and quorum, generates unique public keys, and distributes them to Participants 120A and 120N who receive and store them.Search in Eureka ↗ | Flow diagram |
| FIG. 3 | Sequence diagram (workflow 300) showing the secure federated learning round: Aggregator requests model updates, Participants train and encrypt parameters, Aggregator generates and transmits aggregation vector, Key Server validates and returns private key, Aggregator decrypts aggregate parameters.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Block diagram of the Aggregator 110 showing Processor 410, Memory 415 (containing Aggregation Application 435 with Setup Component 440, Request Component 445, Decryption Component 450, Model Component 455), Storage 420 with Aggregate Model 115, Network Interface 425, and I/O Interfaces 430.Search in Eureka ↗ | System architecture |
| FIG. 5 | Block diagram of the Key Server 105 showing Processor 510, Memory 515 (containing Provisioning Application 535 with Key Component 540, Distribution Component 545, Validation Component 550), Storage 520 with Master Keys 555 and Unique Keys 560, and Network Interface 525.Search in Eureka ↗ | System architecture |
| FIG. 6 | Block diagram of the Participant 120 showing Processor 610, Memory 615 (containing Model Application 635 with Training Component 640 and Encryption Component 645), Storage 620 with Training Data 650, Unique Key 655, and Local Model 125, plus Network Interface 625.Search in Eureka ↗ | System architecture |
| FIG. 7 | Flowchart (method 700) illustrating the Key Server's private and efficient federated learning method: determine provisioning parameters and threshold quorum, generate and transmit unique public keys per participant, validate weight vector against predefined criteria, and conditionally generate and return the private key or issue a warning.Search in Eureka ↗ | Flow diagram |
| FIG. 8 | Flowchart (method 800) illustrating the Aggregator's secure federated learning method: facilitate distribution of public encryption keys (step 805), receive encrypted responses (810), generate aggregation vector (815), retrieve private encryption key using the aggregation vector (820), and generate aggregated model (825).Search in Eureka ↗ | Claim support |
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 8 (CRM/computer-readable storage media), and Claim 15 (system) — providing tripartite enforcement coverage. The dependent:independent ratio of 5.67:1 is moderate for the software/AI norm, providing reasonable fallback but leaving some gaps in technical differentiation across dependent claims. The parallel structure of Claims 1, 8, and 15 ensures comprehensive coverage, while Claims 2–3, 9–10, and 16–17 mirror participant dropout and onboarding scenarios across all three claim types.
Core inventive concept: The claims address the privacy risk in federated learning where an aggregator can infer individual participant training data from model parameters. The inventive mechanism, recited across Claims 1, 8, and 15, uses a trusted third-party key server that distributes unique per-participant public encryption keys and only releases a private decryption key when an aggregation vector — specifying participant weights — satisfies one or more security criteria (i.e., a minimum quorum threshold), preventing the aggregator from isolating any single participant's model parameters.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method | comprising | facilitating distribution of plurality of public encryption keys generated from master public/private key pair by trusted entity; receiving first plurality of encrypted responses containing machine learning model parameters trained on local data; generating first aggregation vector; upon satisfying security criteria, retrieving first private encryption key from trusted entity using aggregation vector; generating aggregated ML model based on private key and responsesSearch prior art ↗ |
| Claim 8 | One or more computer-readable storage media collectively containing computer program code that, when executed by operation of one or more computer processors | performs an operation comprising | facilitating distribution of plurality of public encryption keys generated from master public/private key pair by trusted entity; receiving first plurality of encrypted responses with ML model parameters from local training; generating first aggregation vector; upon satisfying security criteria, retrieving first private encryption key using aggregation vector; generating aggregated ML model based on private key and responsesSearch prior art ↗ |
| Claim 15 | A system | comprising | one or more computer processors; one or more memories containing programs which when executed perform: facilitating distribution of plurality of public encryption keys generated from master public/private key pair; receiving first plurality of encrypted responses with ML model parameters from local training; generating first aggregation vector; upon satisfying security criteria, retrieving first private encryption key from trusted entity using aggregation vector; generating aggregated ML model based on private key and responsesSearch prior art ↗ |
Claim Dependency Tree
1 Method: facilitating public key distribution to federated learning participants, collecting encrypted model responses, generating aggregation vector, retrieving private key on security criteria satisfaction, generating aggregated modelSearch Claim 1 prior art ↗
2 Adds: participant dropout handling — receiving second plurality of responses excluding dropped participant, generating second aggregation vector excluding that participant, retrieving second private key, refining modelSearch in Eureka ↗
3 Adds: new participant onboarding — determining new participant, identifying unused public encryption key, facilitating distribution to new participantSearch in Eureka ↗
4 Adds: aggregation vector defines respective weighting for each of the plurality of participantsSearch in Eureka ↗
5 Adds: security criteria — determining number of non-zero entries in first aggregation vector and confirming count exceeds predefined thresholdSearch in Eureka ↗
6 Further: (depends on 5) security criteria further comprises at least one of: equal weight per non-zero entry confirmation, weight exceeds weight threshold, or weight difference between highest and lowest non-zero entries does not exceed difference thresholdSearch in Eureka ↗
7 Adds: first private encryption key usable to determine aggregate values while individual values of each response remain encryptedSearch in Eureka ↗
8 CRM: computer-readable storage media performing operation equivalent to Claim 1 — public key distribution, encrypted response collection, aggregation vector generation, security-criteria-gated private key retrieval, aggregated model generationSearch Claim 8 prior art ↗
9 Adds: (depends on 8) participant dropout — second plurality of responses, second aggregation vector excluding first participant, second private key, model refinementSearch in Eureka ↗
10 Adds: (depends on 8) new participant onboarding — identifying unused public encryption key, facilitating distributionSearch in Eureka ↗
11 Adds: (depends on 8) aggregation vector defines respective weighting for each participantSearch in Eureka ↗
12 Adds: (depends on 8) security criteria — number of non-zero entries in first aggregation vector exceeds predefined thresholdSearch in Eureka ↗
13 Further: (depends on 12) security criteria further comprises equal weight confirmation, weight threshold check, or difference threshold checkSearch in Eureka ↗
14 Adds: (depends on 8) first private encryption key used to determine aggregate values while individual values remain encryptedSearch in Eureka ↗
15 System: one or more processors and memories performing operation equivalent to Claims 1 and 8 — public key distribution, encrypted response receipt, aggregation vector generation, security-criteria-gated private key retrieval, aggregated model generationSearch Claim 15 prior art ↗
16 Adds: (depends on 15) participant dropout — generating aggregation vector to exclude first participantSearch in Eureka ↗
17 Adds: (depends on 15) new participant onboarding — identifying unused public encryption key, facilitating distributionSearch in Eureka ↗
18 Adds: (depends on 15) security criteria — number of non-zero entries in first aggregation vector exceeds predefined thresholdSearch in Eureka ↗
19 Further: (depends on 18) security criteria further comprises equal weight confirmation, weight threshold check, or difference threshold checkSearch in Eureka ↗
20 Adds: (depends on 15) each participant adds noise to response prior to encrypting, noise determined based at least in part on key provisioning parametersSearch 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 | Always |
| 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 exhibit strong structural consistency across the tripartite method/CRM/system format, with Claims 1, 8, and 15 sharing identical substantive limitations — providing robust multi-vector enforcement. The primary weakness is the near-complete parallelism of dependent claims across the three independent claims (Claims 2–7 mirror Claims 9–14 mirror Claims 16–20), offering limited additional technical differentiation and creating a dependent claim set that a challenger could efficiently attack en masse.
✅
Antecedent Basis
The claims maintain consistent antecedent basis throughout. "The first plurality of responses" in all independent claims is properly introduced as "a first plurality of responses" earlier in the same claim body. "The first aggregation vector" is similarly preceded by "generating a first aggregation vector," and "the first private encryption key" is introduced by the retrieval limitation. No orphaned "the" references were identified across Claims 1–20.
✅
Spec–Claim Consistency
Every independent claim limitation maps directly to a named figure and specification passage. FIG. 3 (blocks 345–365) and the detailed description at columns 11–12 map to the aggregation vector generation and private key retrieval limitations in Claims 1, 8, and 15. FIG. 7 (blocks 735–750) directly supports the security criteria validation limitation of Claims 5–6, 12–13, and 18–19. FIG. 8 provides direct visual claim support for the entire Claim 1 method sequence.
✅
Transition Word Usage
All three independent claims (1, 8, 15) use "comprising" as the transition, correctly preserving open-ended scope — appropriate because additional network components or preprocessing steps should not defeat infringement. The CRM claim (Claim 8) uses "comprising" for both the media recitation and the operation body, which is the standard and strategically correct approach. No inadvertent use of "consisting of" or "consisting essentially of" was identified.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears across any of the 20 claims. Functional language is present (e.g., "retrieving a first private encryption key from the trusted entity using the first aggregation vector") but is tied to structural actors (the aggregator/system) and defined operations in the specification. The software component language in FIG. 4 (Setup Component 440, Request Component 445, Decryption Component 450, Model Component 455) provides structural definition for all functional operations. §112(f) risk is low.
⚠️
§101 Eligibility Risk
An Alice step-two analysis presents moderate risk: the claims recite distributing encryption keys, generating aggregation vectors, and producing aggregated ML models — all of which could be characterized at step one as abstract ideas (mathematical operations on data). The §101 defense rests on the hardware tie-in in Claim 15 ("one or more computer processors") and the CRM tie-in in Claim 8, but Claim 1 as a pure method claim lacks explicit hardware recitation beyond the implicit distributed system. The specification's reference to MIFE (Multi-Input Functional Encryption) cryptosystem provides a technical improvement argument, but a motivated examiner could challenge the method claim under Alice.
⚠️
Dependent Claim Fallback Quality
The most significant structural weakness is the near-complete mirroring of dependent claims across all three independent claims: Claims 2–7 replicate to Claims 9–14 (from Claim 8) and Claims 16–20 (from Claim 15), with no unique technical limitations exclusive to any one branch. Claim 20 (noise addition by participants) and Claim 7/14 (aggregate value computation while individual values remain encrypted) add genuine technical value. However, Claims 4/11, 3/10/17, and 2/9/16 are substantively identical in scope, providing no incremental fallback if the parallel claims fall together.
⚠️
Abstract Quality
The abstract describes the high-level operational sequence (distribute public keys, receive encrypted responses, generate aggregation vector, retrieve private key, generate aggregated model) but omits the key inventive mechanism — the security criteria / quorum threshold that gates private key release and prevents inference attacks. An examiner reading only the abstract would identify this as a generic federated learning system rather than recognizing the novel security-gated decryption mechanism using MIFE that differentiates the invention from prior art cited in the references.
✅
Figure Support Quality
Figure coverage is comprehensive for all structural claim limitations. FIG. 1 supports the high-level system topology recited in Claim 15. FIG. 5 supports the trusted entity/key server limitations of Claims 1, 8, and 15 via Key Component 540, Distribution Component 545, and Validation Component 550. FIG. 8 directly maps to the entire Claims 1/8/15 method sequence as a five-step flowchart. The differential privacy noise addition of Claim 20 is supported by the Encryption Component 645 in FIG. 6 and described at column 11. No claim limitation was identified as lacking figure support.
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.5
Prosecution Defensibility
3.5
Spec–Claim Consistency
4.5
Dependent Claim Coverage
2.5
Claim Type Diversity
4
Figure Support Quality
4.5
Key observation: This patent scores highest on Spec–Claim Consistency and Figure Support Quality (both 4.5/5.0) — every limitation in Claims 1, 8, and 15 maps to a named figure component (FIG. 8 for the complete method flow, FIG. 5 for the key server validation logic) and a specific specification passage. The lowest score is Dependent Claim Coverage (2.5/5.0), because 14 of 17 dependent claims are direct structural mirrors across the three independent claims — if the core aggregation vector / security criteria limitation is successfully challenged, the parallel dependent claim branches fall together with no unique technical fallback positions. Practitioners should note that a continuation filing targeting the MIFE cryptographic structure itself (Setup, PKDistribute, SKGenerate algorithms described in the specification but absent from the claims) would substantially strengthen the portfolio's defensive depth.
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.
MIFE cryptosystem not recited in claims No participant-side encryption claims Key server has no independent claim
Unlock Full Analysis — Free Frequently asked questions
US 12,160,504 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