Patent Drafting Analysis of IBM’s Federated Learning Framework with Hierarchical MLM Hierarchy | US 12,093,837 B2
Patent Drafting Analysis of IBM's Federated Learning Framework with Hierarchical MLM Management | US 12,093,837 B2
A structural and strategic analysis of IBM's federated learning framework patent covering claim architecture, drafting quality, critical gaps, and prosecution positioning across system, CRM, and method claim types.
Spec Words
9,200
Across 6 sections
Draft now ↗
Total Claims
17
3 independent · 14 dependent
Draft now ↗
Figure Sheets
8
System architecture, hierarchy, process flows, cloud
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 specification words (~5,850 of ~9,200), providing substantial support for the hierarchical federated learning framework across 8 figures. The claim architecture comprises 17 total claims with 3 independent claims (system/CRM/method), resulting in a 4.67:1 dependent-to-independent ratio that is below the software/AI industry norm of 6–8:1. Figure coverage spans system architecture (FIG. 1), hierarchy nodes (FIG. 2), API orchestration (FIG. 3), process flows (FIGs. 4–5), and cloud infrastructure (FIGs. 6–8), providing moderate structural breadth.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 8 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | System diagram showing server (110) with AI platform (150) including hierarchy manager (152), MLM manager (154), and training manager (156) connected to knowledge base (160) and computer network (105).Search in Eureka ↗ | System architecture |
| FIG. 2 | Block diagram of federated learning framework (200) showing three-tier hierarchy (Tier_0, Tier_1, Tier_2) with global model (224), local models (242A, 244A, 246A), and dependent nodes with associated data sets.Search in Eureka ↗ | Key embodiment |
| FIG. 3 | Block diagram of AI platform (300) showing API orchestrator (360) transparently threading hierarchy manager (352), MLM manager (354), and training manager (356) via API_0, API_1, and API_2.Search in Eureka ↗ | System architecture |
| FIG. 4 | Flow chart (400) illustrating building a federated learning framework including identifying secondary MLMs (404), creating secondary MLMs via splitting (412), forming new (414), or combining existing (416), then initializing (418) and training or synchronizing.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Flow chart (500) showing controlled local model training algorithm including F1 score computation, batch-size adaptation using B_threshold, convergence check against F1_target, and iteration limit N.Search in Eureka ↗ | Flow diagram |
| FIG. 6 | Block diagram of computer system/server (600) showing processing unit (604), memory (606) with RAM (630) and cache (632), storage system (634), network adapter (620), I/O interfaces (622), and display (624).Search in Eureka ↗ | Claim support |
| FIG. 7 | Cloud computing network diagram (700) showing cloud computing environment (750) with nodes (710) and local computing devices (754A–754N) including phone, desktop, laptop, and automobile computer connected to cloud infrastructure.Search in Eureka ↗ | Other |
| FIG. 8 | Functional abstraction layers diagram (800) of cloud computing environment showing hardware/software layer (810), virtualization layer (820), management layer (830), and workloads layer (840) including hierarchical management of neural models.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 contains 3 independent claims: Claim 1 (computer system/apparatus), Claim 6 (computer program product/CRM), and Claim 11 (method), providing tripartite enforcement coverage. The 4.67:1 dependent-to-independent ratio is below the software/AI industry norm of 6–8:1, suggesting the claim set could have benefited from additional dependent fallback positions. The tripartite structure spanning system, CRM, and method claim types (Claims 1, 6, and 11) ensures enforcement flexibility across different potential infringer profiles, though the dependent claims across all three independent claims substantially mirror each other in subject matter.
Core inventive concept: The claims solve the problem of centralised machine learning data aggregation compromising local privacy by creating a hierarchy of machine learning models where a secondary MLM is initialised by "cloning weights and framework of the primary MLM" and then populated with locally-sourced model updates, with the secondary MLM "logically stored local to the secondary layer" and access "limited to the secondary layer" — preserving data locality while enabling federated gradient aggregation back to the global primary model.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A computer system comprising: a processor operatively coupled to a memory; an artificial intelligence (AI) platform, in communication with the processor, having tools configured to build a federated learning framework | comprising | training manager to train primary MLM capturing contributing model updates across at least one communication channel; hierarchy manager to create secondary MLM in secondary layer operatively coupled to primary MLM; training manager to initialize secondary MLM by cloning weights and framework; MLM manager to logically position secondary MLM local to secondary layer and limit access; MLM manager to store primary MLM globally accessible to secondary MLM; MLM manager to apply clustering technique; MLM manager to synchronize secondary MLM with primary MLM aggregating weights; three APIs with API orchestrator transparently threading APIsSearch prior art ↗ |
| Claim 6 | A computer program product to build a federated learning framework, the computer program product comprising: a computer readable storage medium having a program code embodied therewith, the program code executable by a processor to | comprising | build hierarchy of MLMs integrating federated learning; train primary MLM capturing contributing model updates across communication channel; create secondary MLM in secondary layer logically coupled to primary MLM; initialize secondary MLM cloning weights and framework; store secondary MLM local to secondary layer limiting access; store primary MLM globally accessible to secondary MLM; manage federated learning framework applying clustering technique; synchronize secondary MLM with primary MLM aggregating weights; three APIs with API orchestratorSearch prior art ↗ |
| Claim 11 | A method, comprising: building a federated learning framework, including a hierarchy of machine learning models (MLMs) and integrating federated learning into the hierarchy, wherein the hierarchy of MLMs comprises a primary MLM in a primary layer of the hierarchy | comprising | training manager training primary MLM capturing contributing model updates; hierarchy manager creating secondary MLM in secondary layer operatively coupled to primary MLM; training manager initializing secondary MLM cloning weights and populating with secondary data; MLM manager storing secondary MLM local to secondary layer limiting access; MLM manager managing federated learning framework applying clustering technique; MLM manager synchronizing secondary MLM with primary MLM; three APIs with API orchestrator threading APIsSearch prior art ↗ |
Claim Dependency Tree
1 Computer system with AI platform tools to build federated learning framework including hierarchical MLM creation, initialization by cloning, local positioning, clustering, and API orchestrationSearch Claim 1 prior art ↗
2 Adds: MLM manager applies clustering technique to form new cluster or split existing cluster of MLMs within secondary layerSearch in Eureka ↗
3 Further: clustering technique in secondary layer comprises MLM manager splitting secondary MLM to form at least one new secondary MLM and training itSearch in Eureka ↗
4 Further: clustering technique further comprises MLM manager combining two or more existing secondary MLMs into a merged secondary MLMSearch in Eureka ↗
5 Adds: training manager updates secondary MLM using model updates local to that secondary MLMSearch in Eureka ↗
6 Computer program product (CRM) to build federated learning framework including hierarchical MLM hierarchy, cloning initialization, local storage, clustering, synchronization, and three-API orchestrationSearch Claim 6 prior art ↗
7 Adds: clustering technique applied to two or more MLMs to form new cluster or split existing cluster within secondary layerSearch in Eureka ↗
8 Further: clustering technique in secondary layer further comprises splitting secondary MLM and training newly formed secondary MLMSearch in Eureka ↗
9 Further: clustering technique further comprises combining two or more existing secondary MLMs into merged secondary MLMSearch in Eureka ↗
10 Adds: program code updates secondary MLM using model updates local to that secondary MLMSearch in Eureka ↗
11 Method of building federated learning framework including hierarchical MLM creation, cloning initialization, local storage, clustering management, weight synchronization, and three-API orchestrationSearch Claim 11 prior art ↗
12 Adds: applying clustering technique to two or more MLMs in secondary layer to form new cluster or split existing clusterSearch in Eureka ↗
13 Further: clustering technique within secondary layer further comprises splitting secondary MLM and training newly formed secondary MLMSearch in Eureka ↗
14 Further: clustering technique further comprises combining two or more existing secondary MLMs into merged secondary MLMSearch in Eureka ↗
15 Further: storing primary MLM data globally wherein primary MLM is accessible to secondary MLMSearch in Eureka ↗
16 Further: updating secondary MLM using model updates local to that secondary MLMSearch in Eureka ↗
17 Adds: one or more attributes of federated learning framework comprises one or more physical features, one or more performance characteristics, or combination thereofSearch in Eureka ↗
| Metric | This Application | Software / AI Industry Norm |
|---|---|---|
| Total claims | 17 | 15 – 25 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 4.67 : 1 | 5 – 8 : 1 |
| Method claims present? | Yes — Claim 11 | 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 structure across Claims 1, 6, and 11 (system/CRM/method), and the detailed description provides solid support for the hierarchical federated learning framework through 8 figures. However, the inclusion of the three-API orchestration requirement as a body limitation in all three independent claims — rather than in dependent claims — narrows the independent claims unnecessarily and creates a readily exploitable design-around opportunity.
✅
Antecedent Basis
The claim set maintains clean antecedent basis throughout. In Claim 1, "a training manager" is introduced and then referenced as "the training manager" consistently across subsequent limitations; similarly, "the hierarchy manager" and "the MLM manager" follow proper introduction-then-reference patterns. Claims 6 and 11 mirror this structure, with "a hierarchy manager" introduced before "a hierarchy manager creating" — the parallel construction is clean and consistent across all 17 claims.
✅
Spec–Claim Consistency
The specification provides strong claim support. FIG. 2 and the detailed description (col. 7–8) directly map to the hierarchy manager and secondary MLM creation limitations in Claim 1. FIG. 4 and col. 11–12 support the clustering technique limitations (Claims 2–4, 7–9, 12–14). FIG. 5 supports the training approach, and FIG. 3 maps directly to the three-API orchestrator structure required in Claims 1, 6, and 11. No claim limitation appears without corresponding figure and textual support.
⚠️
Transition Word Usage
All three independent claims use "comprising" as the transition word, which is strategically appropriate for open-ended coverage. However, the use of "comprising" in Claim 6's preamble — "a computer program product to build a federated learning framework, the computer program product comprising" — combined with "a computer readable storage medium having a program code embodied therewith" is a well-established Beauregard formulation. The missed opportunity is the absence of any "consisting essentially of" claim variation to capture partially overlapping implementations that might otherwise avoid literal infringement.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in any of the 17 claims, and the functional components are named as specific structural elements ("training manager," "hierarchy manager," "MLM manager") rather than generic "means." The specification at col. 5–6 provides detailed structural description of each named manager, further grounding them as non-means-plus-function structural elements under MPEP 2181. The three API elements are similarly named as distinct APIs with specific functional descriptions, reducing §112(f) exposure.
⚠️
§101 Eligibility Risk
The claims face moderate Alice/Mayo exposure because the core concept — creating a hierarchy of ML models, cloning weights, and restricting access — reads as an abstract idea in data organisation without the hardware tie-in. The hardware anchor in Claim 1 ("a processor operatively coupled to a memory") and in Claim 6 ("computer readable storage medium") provides a baseline §101 defense, but these are generic recitations. The strongest §101 argument lies in the specific operational coupling of the secondary MLM to the primary MLM across a communication channel and the specific weight-cloning initialisation step, which together represent a concrete technical improvement over generic distributed ML.
⚠️
Dependent Claim Fallback Quality
The 14 dependent claims are structurally weak as fallback positions because they are near-identical triplicates across the three independent claims — Claims 2–5 mirror Claims 7–10 which mirror Claims 12–17, covering the same clustering split/merge and local update subjects. Claim 17 adds a unique limitation (the attributes of the federated framework comprising physical features, performance characteristics, or combination) but only for the method claim. Claims 3 and 4 (and their parallels 8/9 and 13/14) do add distinct fallbacks for split vs. merge operations, but the lack of claims adding limitations on the F1-score-based training algorithm (FIG. 5), the batch-size adaptation mechanism, or the privacy differential mechanism represents a significant missed opportunity for meaningful fallback depth.
⚠️
Abstract Quality
The abstract adequately identifies the hierarchical MLM structure and the secondary MLM initialisation by cloning weights, but fails to highlight the most novel and defensible technical detail — the specific weight-cloning plus local-data-populating initialisation sequence that distinguishes this from generic federated learning. An examiner reading only the abstract would understand the broad hierarchical concept but might miss the clustering-based dynamic group management and the three-API orchestration layer that are recited as body limitations in all three independent claims, potentially leading to an initial §101 or §103 rejection based on an incomplete appreciation of the contribution.
✅
Figure Support Quality
Figure support is strong for the core claim limitations. FIG. 1 supports the system architecture of Claim 1 including processor (112), memory (116), and AI platform (150) with managers (152–156). FIG. 2 provides direct visual support for the hierarchical tier structure and node dependencies. FIG. 3 maps to the three-API and API orchestrator limitations. FIG. 4 supports the clustering technique limitations in Claims 2–4. The batch-size training algorithm in FIG. 5 is described in the specification but not directly claimed — a missed claim opportunity — while FIGs. 6–8 provide cloud deployment context without adding new claim-supported limitations.
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
Spec–Claim Consistency
4.2
Dependent Claim Coverage
2.5
Claim Type Diversity
4.5
Figure Support Quality
4
Key observation: Claim Type Diversity scores highest (4.5/5.0) because the filing covers all three relevant claim forms — system (Claim 1), CRM (Claim 6), and method (Claim 11) — ensuring IBM can pursue infringers regardless of their product, software, or process implementation model. Dependent Claim Coverage scores lowest (2.5/5.0) because the 14 dependent claims are essentially triplicated across the three independent claims, covering only clustering split/merge and local update variations, while the technically distinctive F1-score training algorithm (FIG. 5), batch-size adaptation mechanism, and privacy differential techniques disclosed in the specification are entirely absent from the claim set. Practitioners should note that the unclaimed FIG. 5 training methodology represents a prime continuation opportunity for IBM to capture more specific technical implementations.
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.
API orchestration locked into independent claims F1-score training algorithm entirely unclaimed No privacy access-control mechanism claims
Unlock Full Analysis — Free Frequently asked questions
US 12,093,837 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