Patent Drafting Analysis of Darktrace Holdings Limited’s AI Adversary Red Team System | US 12,034,767 B2
Patent Drafting Analysis of Darktrace Holdings Limited's AI Adversary Red Team System | US 12,034,767 B2
A structural and strategic analysis of claim architecture, drafting quality, critical gaps, and prosecution positioning for Darktrace's AI-driven automated phishing penetration testing patent.
Spec Words
12,400
Across 6 sections
Draft now ↗
Total Claims
18
4 independent · 14 dependent
Draft now ↗
Figure Sheets
7
System architecture, network topology, module diagrams, attack graphs
Draft now ↗
Published by PatSnap Insights Team · · 13 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 62% of total words (~8,000 words), with the claims section contributing a substantial ~31% — unusually high for a software/AI patent — reflecting the dense, multi-element claim construction used across all 18 claims. The claim architecture comprises 4 independent claims (Claims 1, 4, 10, and 11) covering two apparatus formats and two method formats, with 14 dependent claims creating fallback positions of varying depth. Seven figure sheets cover system topology (FIGs. 1–3), module architecture (FIG. 4), attack spread visualization (FIG. 5), anomaly scoring (FIG. 6), and a cloud deployment scenario (FIG. 7), providing reasonable but not exhaustive structural support for the claimed elements.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 7 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Block diagram of the full AI cyber threat security system (100) showing the AI adversary red team (105) communicatively coupled to a cyber security appliance (120), email defense system (115), network defense system (125), endpoint computing devices (101A-B), and open source database server (122) over networks (110/112).Search in Eureka ↗ | System architecture |
| FIG. 2 | Block diagram of an AI cyber security system (200) showing the AI adversary red team (105) cooperating with a cyber security appliance (120), host endpoint agents (211A-D) on endpoint computing devices (201A-D), email server (136), open source database server (122), and communication server (130) over network (110).Search in Eureka ↗ | System architecture |
| FIG. 3 | Block diagram of an AI-based cyber security network environment (300) illustrating the AI adversary red team (105) and cyber security appliance (120) operating over the Internet, with internal IT network servers protected by external (FW-1) and internal (FW-2) firewalls, DMZ zones, web server farm with load balancer, and database cluster.Search in Eureka ↗ | System architecture |
| FIG. 4 | Block diagram of the cyber security appliance (120) showing multiple cooperating modules including Trigger Module, Gather Module, Network Module, Email Module, Coordinator Module, AI adversary red team (105), Orchestration Module, Profile Manager, Communication Module, Analyzer Module, Cyber Threat Module, Host Module, User Interface Module, Researcher Module, Autonomous Response Module, plus four AI Model cylinders (Network Pattern of Life, Email Data with Multiple Data Points, Potential Cyber Threats, Normal Pattern of Life) and I/O Ports.Search in Eureka ↗ | Key embodiment |
| FIG. 5 | Exemplary graph (500) of a pentested network in an email/network defense system showing the simulated spread of a customized phishing email payload from an initially compromised Device n, illustrating multiple vulnerabilities across key servers and devices over 10-, 100-, and 500-day timeframes using various exploit types (Web Application Exploit, Broadcast Poisoning, SMB Exploit, SSH, Unknown Exploit, SQL Injection).Search in Eureka ↗ | Claim support |
| FIG. 6 | Exemplary graph (600) depicting events and alerts triggered by detected unusual email and network connectivity and behavior pattern data, plotting cyber-threat scores (0–100) against detected event launch dates (Days 1–8), with cluster types including unusual email activity, unusual network activity, and unusual behavior patterns, shown in relation to the AI adversary red team with trained AI models.Search in Eureka ↗ | Claim support |
| FIG. 7 | Block diagram of an exemplary AI cyber threat defense system (700) with AI adversary red team (105) and cyber security appliance (120) protecting a network of computer systems (750), showing first computer system (710) with computers 701-703, local server 704, multifunctional device 705, database server 730, and second computer system (740) with computers 741-742, all connected over network (110).Search in Eureka ↗ | System architecture |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent contains 4 independent claims: Claims 1 and 4 are apparatus claims ("An apparatus, comprising"), Claims 10 and 11 are method claims ("A method for generating AI automated phishing emails"), and Claim 18 is a computer-readable medium claim — however, careful reading reveals Claim 18 is dependent on Claim 10, making it a dependent CRM claim rather than a standalone independent. The 14 dependent claims yield a 3.5:1 dependent-to-independent ratio, which is below the software/AI norm of 5–8:1 and signals relatively thin fallback coverage. The parallel apparatus/method structure in Claims 1/4 and 10/11 creates redundant independent claim pairs covering substantively identical scope in different claim types, which partially compensates for the thinner dependent chain depth.
Core inventive concept: The claims solve the problem of generic, non-targeted penetration testing by reciting an AI adversary red team simulator that trains AI models on an organization's specific contextual knowledge — including language-based data, email/network connectivity and behavior pattern data, and historic knowledgebase data — and cooperates with an AI classifier to produce organization-specific classifiers, which then drive a phishing email generator to generate and customize automated phishing emails used to initiate targeted attacks on specific users in the organization's email and network defense systems. The paraphrasing engine limitation, requiring segmentation of email data into subject line, body content, and signature line with rephrasing to differentiate variants, is a structural differentiator present in all independent apparatus and method claims.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | An apparatus, comprising: an artificial intelligence (AI) adversary red team simulator configured to pentest one or more defenses implemented by a cyber threat defense system | comprising | AI adversary red team simulator configured to pentest email and network defense systems; one or more AI models trained on contextual knowledge (language-based data, email/network connectivity and behavior pattern data, historic knowledgebase data) cooperating with AI classifier producing organization-based classifiers; phishing email generator cooperating with trained AI models to customize automated phishing emails based on identified data points; paraphrasing engine receiving email data from identified data points, breaking email into two or more segments (subject line, body content, signature line), rephrasing segments to differentiate first phishing email from second phishing emailSearch prior art ↗ |
| Claim 4 | An apparatus, comprising: an artificial intelligence (AI) adversary red team simulator configured to pentest one or more defenses implemented by a cyber threat defense system | comprising | AI adversary red team simulator pentesting email and network defense systems; AI models trained on contextual knowledge cooperating with AI classifier producing organization-based classifiers; phishing email generator cooperating with trained AI models to customize automated phishing emails; analyzer module cooperating with AI classifier to produce list of organization-based classifiers and cooperating with trained AI models to identify normal pattern of life for entities in email and network defense systems; communications module cooperating with analyzer module and communicating with API hosted by cyber security appliance; profile manager module in cyber security appliance maintaining profile tag on each entity based on email/network connectivity and behavior pattern dataSearch prior art ↗ |
| Claim 10 | A method for generating AI automated phishing emails to pentest a cyber threat defense system | comprising | Configuring AI adversary red team simulator to pentest email and network defense systems; training AI models on contextual knowledge (language-based data, email/network connectivity, behavior pattern data, historic knowledgebase data) cooperating with AI classifier producing organization-based classifiers; configuring phishing email generator to generate and customize automated phishing emails based on identified data points; attack scenarios implemented by scenario module cooperating with orchestration module and trained AI models, customized based on email/network connectivity and behavior pattern dataSearch prior art ↗ |
| Claim 11 | A method for generating AI automated phishing emails to pentest a cyber threat defense system | comprising | Configuring AI adversary red team simulator to pentest one or more defenses including email and network defense systems; training AI models on contextual knowledge cooperating with AI classifier producing organization-based classifiers; configuring phishing email generator to customize automated phishing emails based on identified data points; configuring paraphrasing engine to receive email data from identified data points, break into two or more segments (subject line, body content, signature line), rephrase to differentiate first phishing email from second phishing emailSearch prior art ↗ |
Claim Dependency Tree
1 Apparatus: AI adversary red team simulator pentesting cyber threat defense; AI models on contextual knowledge; phishing email generator with paraphrasing engine segmenting and rephrasing emailsSearch Claim 1 prior art ↗
2 Adds: payload module (first non-executable payload + second executable payload); training module training attacked users; simulated cyber-attack module using second payload to pentest network defense systemSearch in Eureka ↗
3 Further: specific attack scenarios implemented by scenario module cooperating with orchestration module and trained AI models, customized based on email/network connectivity and behavior pattern dataSearch in Eureka ↗
4 Apparatus: AI adversary red team simulator; AI models on contextual knowledge; phishing email generator; analyzer module; communications module with API to cyber security appliance; profile manager module with profile tagsSearch Claim 4 prior art ↗
5 Adds: collections module monitoring and collecting organization-based data from host endpoint agents; network module with network probes; email module with email probes; profile manager maintaining profile tags based on behavior pattern data from email and network modulesSearch in Eureka ↗
6 Further: collections module cooperating with communication module and analyzer module to gather external data from open source databases (online professional networking, organization website, online public search database)Search in Eureka ↗
7 Further: list of organization-based classifiers includes context classifier, natural language classifier, historic knowledgebase classifier, open source classifier, industry group classifier, domain classifier, attack vector classifier, and/or hierarchical relationship classifier — each trained on specific data typesSearch in Eureka ↗
8 Further: cyber threat module referencing machine-learning models trained on potential cyber threats, cooperating with payload module, scenario module, and simulated attack module to generate specific attack scenarios based on trained potential cyber threatsSearch in Eureka ↗
9 Further: user interface cooperating with orchestration module providing user input parameters (first parameter: identify predetermined attack; second parameter: select user/entity; third parameter: establish threshold; fourth parameter: restrict users/entities from being attacked; threshold based on time schedule, maximum paths, maximum compromised users/devices/entities)Search in Eureka ↗
10 Method: configuring AI adversary red team simulator; training AI models on contextual knowledge cooperating with AI classifier; configuring phishing email generator; attack scenarios implemented by scenario module cooperating with orchestration module and trained AI modelsSearch Claim 10 prior art ↗
14 Adds: configuring analyzer module cooperating with AI classifier; configuring communications module cooperating with analyzer module and API to cyber security appliance; configuring profile manager module maintaining profile tags; configuring collections module monitoring host endpoint agents; configuring network module with network probes; configuring email module with email probesSearch in Eureka ↗
15 Further: collections module cooperating with communication module and analyzer module to gather external data from open source databases specific to organization, entities, and usersSearch in Eureka ↗
16 Further: list of classifiers includes context, natural language, historic knowledgebase, open source, industry group, domain, attack vector, and/or hierarchical relationship classifiers, each with specific training dataSearch in Eureka ↗
17 Further: configuring cyber threat module referencing ML models on potential cyber threats; configuring user interface with orchestration module providing four user input parameters including time schedule, maximum paths, maximum compromised users/devices/entitiesSearch in Eureka ↗
18 Adds: non-transitory computer readable medium with computer readable codes operable, when executed by one or more processors, to instruct an AI adversary red team simulator to perform the method of Claim 10Search in Eureka ↗
11 Method: configuring AI adversary red team simulator; training AI models on contextual knowledge cooperating with AI classifier; configuring phishing email generator; configuring paraphrasing engine to receive, segment, and rephrase email data to differentiate multiple phishing email variantsSearch Claim 11 prior art ↗
12 Adds: configuring payload module (first non-executable + second executable payload); configuring training module to train attacked users; configuring simulated cyber-attack module using second payload to pentest network defense systemSearch in Eureka ↗
13 Further: specific attack scenarios implemented by scenario module cooperating with orchestration module and trained AI models, customized based on email/network connectivity and behavior pattern data of usersSearch in Eureka ↗
| Metric | This Application | Software / Cloud Security Norm |
|---|---|---|
| Total claims | 18 | 15 – 30 |
| Independent claim count | 4 | 3 – 5 |
| Dependent : Independent ratio | 3.50 : 1 | 5 – 8 : 1 |
| Method claims present? | Yes — Claims 10, 11 | Common |
| System / apparatus claims? | Yes — Claims 1, 4 | Always |
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 solid structural coverage with a tripartite claim type architecture (apparatus, method, CRM) and detailed organizational classifier enumeration in Claim 7/16, but the parallel independent claim structure in Claims 1/4 and 10/11 creates redundant scope coverage rather than genuinely expanding the claimed space, reducing the effective independent claim leverage. The most significant quality risk is the dense functional claim language throughout Claims 1 and 4 — particularly the phrases 'configured to cooperate' and 'configured to communicate' — which may invite §112(f) scrutiny despite the absence of explicit 'means for' language.
✅
Antecedent Basis
The claim set is largely clean on antecedent basis, with no identifiable orphaned 'the [element]' references. Claim 1 introduces 'a phishing email generator' and 'a paraphrasing engine' on first mention, then correctly references 'the paraphrasing engine' in subsequent limitations. Claims 4 and 10 each introduce 'an analyzer module,' 'a communications module,' and 'a profile manager module' with proper article usage. The only marginal case is Claim 2's reference to 'the phishing email module' which is not explicitly named in Claim 1's preamble as a standalone element — the dependency on Claim 1 mitigates but does not fully eliminate this ambiguity.
✅
Spec–Claim Consistency
The specification provides strong written description support for the primary independent claim limitations. FIG. 1 and the description at pages 5–6 directly map to the AI adversary red team simulator of Claims 1 and 4. FIG. 4 maps specifically to the analyzer module, communications module, orchestration module, and profile manager module limitations in Claims 4 and 14. The paraphrasing engine of Claim 1 is supported by detailed description at pages 3, 13, 24–25. The AI classifier and organization-based classifiers of Claims 1/4 are directly supported by pages 11–12 of the specification, which enumerate all eight classifier types later recited in Claims 7 and 16.
✅
Transition Word Usage
All 18 claims use 'comprising' as the transition, which is the strategically optimal open-ended choice for a software/AI system patent — it prevents a competitor from avoiding infringement by adding additional components. No claim uses 'consisting of' or 'consisting essentially of,' which would be inappropriate for this technology type. The use of 'comprising' throughout the claim set is particularly important for Claim 1 given the extensive functional limitation chain, as it preserves infringement coverage for implementations that include additional AI modules or subsystems beyond those recited.
⚠️
§112(f) Means-Plus-Function Risk
No explicit 'means for' language appears in the claims, which avoids automatic §112(f) invocation. However, the pervasive use of 'configured to cooperate with' throughout Claims 1, 4, 10, 11, and their dependents — e.g., 'a phishing email generator...configured to cooperate with the one or more trained AI models' in Claim 1 — is nontrivially functional. Under Williamson v. Citrix (Fed. Cir. 2015), 'configured to' without sufficient structural definition can still trigger §112(f) if the term is deemed a generic functional placeholder. The specification mitigates this by naming specific module architectures in FIG. 4, but an examiner could challenge whether 'phishing email generator' and 'paraphrasing engine' connote sufficient structure for a POSITA in this art unit.
⚠️
§101 Eligibility Risk
This patent carries moderate §101 Alice/Mayo exposure. Claims 10 and 11 are method claims whose preambles recite 'a method for generating AI automated phishing emails to pentest a cyber threat defense system' — a process that, at the abstract idea level, could be characterized as 'organizing information through mathematical correlations' (Alice Step 1). The hardware tie-in defense in the apparatus claims (Claims 1 and 4) relies on 'an AI adversary red team simulator' and 'a phishing email generator,' which are software constructs rather than specific hardware. The §101 defense is strengthened by Claim 4's explicit recitation of a 'cyber security appliance' and 'profile manager module' as structural entities, and by Claim 9's detailed UI parameter constraints — but Claims 10 and 11 lack equivalent hardware anchors, creating examination vulnerability at Step 2A, Prong 2.
⚠️
Dependent Claim Fallback Quality
The dependent claims add genuine technical depth in some cases but create structural redundancy in others, reducing fallback value. Claims 7 and 16 are strong fallback claims — the enumeration of eight specific AI classifiers (context, natural language, historic knowledgebase, open source, industry group, domain, attack vector, hierarchical relationship) provides meaningful secondary fallback positions. Claims 3 and 13 are weaker, adding only the scenario module/orchestration module combination already partly implied by the independent claims. The most significant weakness is that Claims 2 and 12 mirror each other identically (payload module + training module + simulated cyber-attack module), and Claims 3 and 13 likewise mirror each other — these parallel dependencies consume half the dependent claim count without expanding coverage beyond the dual independent claim pairs.
⚠️
Abstract Quality
An examiner reading only the abstract would correctly identify the general topic — AI red team pentesting of email/network defenses using trained AI models and a phishing email generator — but would miss the critical differentiating limitations. Specifically, the abstract mentions 'customized phishing emails' and 'specific organization-based classifiers' but does not disclose the paraphrasing engine mechanism (segment breakup and rephrasing to differentiate multiple phishing email variants), which is the structural element most likely to distinguish over prior art. The abstract also does not identify the analyzer module, profile manager module, or communications module API cooperation that constitutes the core architecture of Claim 4. This omission means the abstract undersells the technical specificity of the claims to both examiners and potential licensees scanning the document.
✅
Figure Support Quality
The seven-figure set provides good but not complete structural support for the claim limitations. FIG. 1 supports the high-level system recitation in Claims 1 and 4 (AI red team 105, cyber security appliance 120, email defense system 115, network defense system 125). FIG. 4 directly supports the module-level limitations of Claims 4–9 and 14–17, naming Orchestration Module, Profile Manager, Communication Module, Analyzer Module, and Cyber Threat Module. FIG. 5 supports the simulated cyber-attack module recitation in Claims 2 and 12. However, the paraphrasing engine — the key structural differentiator in Claims 1 and 11 — has no dedicated figure, relying entirely on textual description in the specification. A stronger filing would have included a flowchart showing email segmentation and rephrasing 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.2
Prosecution Defensibility
3.5
Spec–Claim Consistency
4
Dependent Claim Coverage
3
Claim Type Diversity
4
Figure Support Quality
3.5
Key observation: The highest-scoring dimensions are Spec–Claim Consistency and Claim Type Diversity (both 4.0/5.0) — the specification's detailed module descriptions in FIG. 4 and pages 11–14 map precisely to the independent claim limitations, and the apparatus/method/CRM tripartite structure covers the key enforcement vectors. The lowest-scoring dimension is Dependent Claim Coverage (3.0/5.0): seven of the fourteen dependent claims simply mirror the Claims 1–3 chain in the Claims 4 and 11 parallel chains, consuming claim count without adding genuinely distinct technical fallback positions — a continuation application should convert these parallel mirrors into novel limitations covering real-time feedback loops, autonomous response integration, and network graph visualization outputs that are disclosed but not claimed.
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.
CRM only dependent — not standalone Paraphrasing engine absent from Claim 4 and 10 Autonomous response feedback loop unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 12,034,767 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