Patent Drafting Analysis of BOBI, INC.’s Model Security in Distributed AI Training | US 12,093,400 B1
Patent Drafting Analysis of BOBI, INC.'s Model Security in Distributed AI Training | US 12,093,400 B1
A structural and strategic analysis of US 12,093,400 B1 examining claim architecture, drafting quality, critical gaps, and prosecution positioning for BOBI's federated learning model security system.
Spec Words
9,200
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
16
System architecture, process flows, data pipelines
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 55% of estimated total words, providing substantial embodiment support across 16 drawing sheets covering federated learning architecture, security flows, and hardware configurations. The claim set comprises 20 claims total — 3 independent claims (method, system, CRM) with 17 dependents yielding a 5.67:1 ratio, which is consistent with software/AI class norms. Figure coverage is extensive, spanning network topology (FIG. 1), local and global processing system components (FIGs. 2A–2B), end-to-end process flows (FIGs. 3A–3F), domain-specific application architecture (FIGs. 3G–3I), and hardware architectures (FIGs. 4–7).
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 16 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Network diagram of an AI model management system showing user devices (110a), other devices (110b), local processing system (152), global processing system (153), database (154), and network (150).Search in Eureka ↗ | System architecture |
| FIG. 2A | Local processing system (152) component diagram showing database interface (231), differential privacy engine (233), model training and evaluation engine (235), encryption engine (237), API interface (239), peripheral interface (241), security validation engine (243), user interface (245), monitoring engine (247), and alert engine (249).Search in Eureka ↗ | Key embodiment |
| FIG. 2B | Global processing system (153) component diagram showing user device interface (251), model security engine (253), global model training and evaluation engine (255), monitoring engine (257), model weighting engine (259), distribution verification engine (261), and server interface (263).Search in Eureka ↗ | Key embodiment |
| FIG. 3A | End-to-end AI model management process flow showing local steps (351–361: deploy, obtain data, apply differential privacy, train, evaluate, apply local security analytics) and global/central steps (363–371: receive models, apply central security, aggregate, update, apply governance).Search in Eureka ↗ | Flow diagram |
| FIG. 3B | Federated model broadcast architecture showing central servers deploying a serializable AI/ML model with federation-compliant data architecture and orchestration logic to eligible edge clients among all edge clients.Search in Eureka ↗ | Flow diagram |
| FIG. 3C | On-device federated analytics flow depicting data security review, differential privacy application, model training, iterative retraining during eligibility, model performance evaluation, and model security review leading to server update cache or data security incident response.Search in Eureka ↗ | Flow diagram |
| FIG. 3D | Central intake security review flow showing parallel paths for differentially private dataset (data intake security review) and optimal local model (model intake security review), with pass/fail branches leading to data store update, client model weight aggregation, or data security incident response.Search in Eureka ↗ | Flow diagram |
| FIG. 3E | Client weight aggregation strategies diagram showing lookahead optimizer and federated averaging algorithms, updated aggregated client model weights, data distribution check, and server update flow with pseudocode for the optimization algorithm.Search in Eureka ↗ | Flow diagram |
| FIG. 3F | Model governance and production staging flow showing model degradation and security threshold evaluation, unit/smoke tests, gated approval, deployment logistics, production endpoints, and continuous monitoring (CM) pipelines.Search in Eureka ↗ | Flow diagram |
| FIG. 3G | Pregnancy health monitoring system architecture showing data processing system (170) with monitoring engine (112), intervention engine (114), and alert engine (116) connected via network (150) to edge (120) comprising mobile device (122) and biometric device (126), training data (102), survey data (124), and external stakeholders (104).Search in Eureka ↗ | System architecture |
| FIG. 3H | Pregnancy health data processing system (170) component diagram showing biometric device interface (201), computing/mobile device interface (203), training data interface (205), data processing/standardizing engine (207), training engine (209), trained model analysis engine (211), monitoring engine (112), alert engine (116), intervention engine (114), and meta analysis/recommendation engine (221).Search in Eureka ↗ | Key embodiment |
| FIG. 3I | Pregnancy health monitoring process flow showing obtaining historical data (301), labeling health data (303), applying multiple models (307), best fit selection (309), obtaining near-real-time data (311), applying selected model (313), sending to monitoring classification system (315), trigger evaluation (317), alert deployment (319), trigger level determination (321), and meta analysis (329).Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Computing device (10) architecture block diagram showing processor(s) (13), local storage (11), memory (12), bus (14), interface (15), and remote storage (16).Search in Eureka ↗ | Claim support |
| FIG. 5 | Standalone computing system (20) architecture showing processors (21), operating systems (22), clients (23), memory (25), storage (26), outputs (27), and inputs (28).Search in Eureka ↗ | Claim support |
| FIG. 6 | Distributed computing network architecture (30) showing network(s) (31), servers (32), clients (33), database (34), config (35), security (36), and external services (37) interconnected through a central network node.Search in Eureka ↗ | System architecture |
| FIG. 7 | Detailed computer system (40) hardware architecture showing CPU (41), bus (42), memory (43), NVM (44), PSU (45), AC (46), display (47), I/O (48), keyboard (49), pointing device (50), HDD (52), NIC (53), and network cloud (54).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 19 (system/computing apparatus), and Claim 20 (non-transitory computer readable medium/CRM), providing a tripartite claim structure standard for software-implemented AI patents. The 17 dependent claims yield a 5.67:1 dependent-to-independent ratio, which is within the normal range for software/AI patents in the G06F/G06N class space. The tripartite structure provides enforcement coverage across method, system, and CRM formats, though all three independent claims recite nearly identical limitations, limiting fallback differentiation.
Core inventive concept: The claims address the vulnerability of federated learning systems to data poisoning and model manipulation attacks by implementing a dual-layer, edge-first security architecture. Claim 1 requires applying 'a local data security review' using 'at least one generated edge threshold to identify data anomalies,' generating a differentially private second data set, and then applying both a 'local model security review' and a 'central model security review' before combining locally trained models at a central processing system — ensuring malicious content is screened at the source device before it can corrupt the global model.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A computer implemented method for edge device level security analytics | comprising | creating first local model by deploying first central model to first user device; obtaining near-real-time digital data (physiology and health); generating first data set from obtained digital data; applying local data security review with edge sensor thresholds to identify anomalies; filtering anomalous data; generating second data set with differential privacy techniques; training second local model; applying local model security review; applying central model security review at central processing system; combining second local model with third local model from second user device; auditing performance of first central model to generate audit metrics; updating central model; deploying updated central model to plurality of user devicesSearch prior art ↗ |
| Claim 19 | A computing system for edge device level security analytics | comprising | at least one computing processor; memory comprising instructions that when executed enable: create first local model by deploying first central model; obtain near-real-time digital data; generate first data set; apply local data security review with edge sensor thresholds; filter anomalies; generate second data set with differential privacy; train second local model; apply local model security review; apply central model security review; combine second and third local models; audit first central model performance; update central model; deploy updated central modelSearch prior art ↗ |
| Claim 20 | A non-transitory computer readable medium comprising instructions that when executed by a processor enable the processor to | comprising | create first local model by deploying first central model; obtain near-real-time digital data; generate first data set; apply local data security review with edge sensor thresholds; filter anomalies; generate second data set with differential privacy; train second local model; apply local model security review; apply central model security review; combine second and third local models; audit first central model performance; update central model; deploy updated central modelSearch prior art ↗ |
Claim Dependency Tree
1 Computer implemented method for edge device level security analytics — federated learning with dual-layer local/central model security review and differential privacySearch Claim 1 prior art ↗
2 Adds: digital data is obtained through an APISearch in Eureka ↗
3 Adds: local data security review comprises identifying malicious data set failing edge sensor threshold analysis and reporting threshold failureSearch in Eureka ↗
4 Adds: converting first data set into a standardized formatSearch in Eureka ↗
5 Adds: auditing performance comprises at least one of FMEA, security testing, and non-failure mode and effects analysisSearch in Eureka ↗
6 Adds: updating central model based on audit metrics further comprises electronic design automation, feature engineering, training, evaluation; FMEA conducted during each update stepSearch in Eureka ↗
7 Adds: further comprising registering an audited and finalized model; receiving user input to evaluate permission to update local modelSearch in Eureka ↗
8 Adds: updating first central model comprises FMEA, smoke testing, checking obtained data, and unit testingSearch in Eureka ↗
9 Adds: further comprising implementing a security system within model training and data monitoring pipeline for adversarial attacksSearch in Eureka ↗
10 Adds: central model receives differentiated data if user provides sharing permissionSearch in Eureka ↗
11 Adds: further comprising training the second model on locally obtained dataSearch in Eureka ↗
12 Adds: user health data may comprise at least one of dietary information, exercise and activitySearch in Eureka ↗
13 Adds: physiology data comprises at least one of pulse, respiration rate, blood pressure, electrocardiogram, caloric expenditure, fetal kick counts, mental health, pain, bleeding, and contractions gathered at a first sampling frequencySearch in Eureka ↗
14 Adds: predictive inference is associated with pregnancy outcomesSearch in Eureka ↗
15 Adds: further comprising obtaining a pregnancy outcome metric by applying the first local model to the second data setSearch in Eureka ↗
16 Adds: (depends on 15) providing an alert to user and healthcare practitioner based on pregnancy outcome metric; healthcare practitioner comprises emergency medical services, physician, or practiceSearch in Eureka ↗
17 Adds: (depends on 16) providing alert comprises comparing pregnancy outcome metric to a threshold; metric comprises indication of positive or negative outcomeSearch in Eureka ↗
18 Adds: updating central model comprises re-training central model to predict pregnancy outcomes based on aggregated local modelsSearch in Eureka ↗
19 Computing system for edge device level security analytics — processor and memory implementing the full federated learning security pipeline of Claim 1Search Claim 19 prior art ↗
20 Non-transitory computer readable medium — instructions enabling processor to execute the full federated learning security pipeline of Claims 1 and 19Search Claim 20 prior art ↗
| Metric | This Application | Software / AI Norm |
|---|---|---|
| Total claims | 20 | 15 – 25 |
| Independent claim count | 3 | 1 – 4 |
| Dependent : Independent ratio | 5.67 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Always |
| System / apparatus claims? | Yes — Claim 19 | 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 completeness with a well-supported tripartite claim format (method, system, CRM) and extensive figure support across 16 sheets, but the nearly verbatim repetition of Claim 1's limitations in Claims 19 and 20 represents a significant missed opportunity to introduce differentiated claim scope. Dependent Claims 12–18 add genuinely useful technical fallback positions tied to the pregnancy monitoring domain, while Claims 2, 10, and 11 add only minimal limitation value.
✅
Antecedent Basis
The claims demonstrate generally clean antecedent basis throughout. The 'first local model,' 'first central model,' 'first data set,' 'second data set,' 'second local model,' and 'third local model' are all introduced with 'a' before subsequent 'the' references. One minor potential issue: Claim 1 introduces 'a second user device' without prior antecedent in the preamble, though this is an independent claim limitation establishing the structural context, so it is unlikely to cause office action rejection.
✅
Spec–Claim Consistency
FIG. 2A and the description of differential privacy engine (233) and security validation engine (243) directly support the Claim 1 limitations of applying differential privacy techniques and local model security review. FIG. 3A steps 355 and 361 map precisely to the 'local data security review' and 'local model security analytics' limitations. FIG. 3D maps to the central model security review limitation. The detailed description provides sufficient support for all independent claim elements.
✅
Transition Word Usage
All three independent claims correctly use 'comprising,' the broadest open-ended transition, preserving scope against accused infringers who implement additional steps or components beyond those recited. This is particularly important for the method claim (Claim 1) where 'comprising' allows for additional security layers not recited in the claim body. No 'consisting of' or 'consisting essentially of' transitions are used, which is strategically appropriate for this technology domain.
⚠️
§112(f) Means-Plus-Function Risk
No explicit 'means for' or 'step for' language appears in the claims. However, Claims 19 and 20 use highly functional language ('create,' 'obtain,' 'generate,' 'apply,' 'filter,' 'train,' 'combine,' 'audit,' 'update,' 'deploy') without structural definition of the hardware executing those functions beyond 'at least one computing processor' and 'memory.' An examiner or litigant could argue that some of these functional terms in a system claim warrant §112(f) treatment, which would limit the claim to the structures disclosed in FIGS. 2A–2B and equivalents.
⚠️
§101 Eligibility Risk
The claims face non-trivial Alice exposure because the core concept — detecting and filtering malicious data in a federated learning pipeline — could be characterized as an abstract idea of 'data filtering and model aggregation.' The §101 defense rests on the recitation of physical edge sensors ('the edge sensor uses at least one generated edge threshold to identify data anomalies') and user devices, which grounds the claims in specific hardware. However, the edge sensor limitation is functional rather than structural, and an examiner may argue it merely implements the abstract idea on conventional hardware without a further inventive concept.
✅
Dependent Claim Fallback Quality
Dependent Claims 5 (FMEA/security testing auditing), 9 (adversarial attack pipeline monitoring), 13 (specific physiological data types including fetal kick counts), and 15–17 (pregnancy outcome metric with threshold-based alerting) add genuinely distinct, defensible fallback positions. However, Claims 2 (API data collection), 10 (user sharing permission), and 11 (training on locally obtained data) add only thin limitations that a competitor could easily design around. Claims 14 and 18 narrow the claims to pregnancy outcomes, which is a domain-specific restriction that reduces breadth without adding technical distinction.
⚠️
Abstract Quality
The abstract states that 'security techniques are applied at the user device level on edge devices to evaluate data and/or locally trained models for malicious content' — this accurately describes the technology but omits the specific inventive mechanism: the generation of a differentially private second data set conditioned on edge sensor threshold analysis, which is the core novel contribution. An examiner reading only the abstract would understand the general category of the invention but might not identify what distinguishes it from prior art server-side federated security approaches.
✅
Figure Support Quality
Figure support is comprehensive. The edge sensor limitation of Claim 1 is supported by security validation engine (243) in FIG. 2A and the data security review step in FIG. 3C. The differential privacy limitation maps to the differential privacy engine (233) in FIG. 2A and step 355 in FIG. 3A. The central model aggregation limitation maps to FIG. 3D–3E. Hardware architecture for both method and system claims is supported by FIGS. 4–7. No independent claim limitation lacks figure support, though the 'at least one generated edge threshold' mechanism in Claim 1 would benefit from a more explicit figure showing threshold generation logic.
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.2
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3
Claim Type Diversity
4.5
Figure Support Quality
4
Key observation: Claim Type Diversity scores highest at 4.5 because the patent correctly files method (Claim 1), computing system (Claim 19), and CRM (Claim 20) claims, covering the three most commercially important enforcement formats for software-implemented AI technology. Dependent Claim Coverage scores lowest at 3.0 because Claims 19 and 20 replicate the Claim 1 body almost verbatim without independent structural differentiation, and many of the 17 dependent claims (e.g., Claims 2, 10, 11) add only thin functional limitations rather than structural fallback positions that would survive narrowing amendments. Practitioners should note that a continuation filing expressly claiming the edge threshold generation algorithm and the lookahead optimizer weight aggregation technique shown in FIG. 3E would significantly strengthen the prosecution portfolio.
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.
System claims duplicate method steps Edge threshold generation unclaimed Lookahead optimizer aggregation unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 12,093,400 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