Patent Drafting Analysis of Darktrace Holdings Limited’s Autonomous Email Report Generator | US 12,063,243 B2
Patent Drafting Analysis of Darktrace Holdings Limited's Autonomous Email Report Generator | US 12,063,243 B2
A structural and strategic analysis of US 12,063,243 B2 covering claim architecture, drafting quality signals, critical prosecution gaps, and competitive positioning of Darktrace's AI-driven email threat reporting system.
Spec Words
9,800
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
18
Report UI, system architecture, threat analysis flows
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 words (~6,200 of ~9,800), providing extensive narrative support for the AI model architecture and template-library mechanism. The claim set comprises 20 claims — 3 independent (apparatus Claim 1, method Claim 11, CRM Claim 20) and 17 dependent — yielding a 5.67:1 dependent-to-independent ratio that is typical for software/AI security patents. The 18 drawing sheets offer broad UI-level and system-architecture coverage, though several figures depict example report output pages rather than structural claim limitations.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 18 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Summary email threat report page generated by the autonomous email report generator showing attack types, user nodes, and email attack counts.Search in Eureka ↗ | Key embodiment |
| FIG. 2 | Bar chart view of the email threat report showing malicious emails received per Darktrace.com email address ranked by volume.Search in Eureka ↗ | UI/interface |
| FIG. 3 | Mailflow summary over a seven-day period showing inbound/outbound trends with key statistics including address counts and new sender percentages.Search in Eureka ↗ | UI/interface |
| FIG. 4 | Intent summary page categorising malicious emails by derived purpose including impersonation attempts, potential external account hijack, and solicitation.Search in Eureka ↗ | Claim support |
| FIG. 5 | Email threat intent summary showing communications with personal accounts, suspicious links, and suspicious attachments with trend charts over a seven-day period.Search in Eureka ↗ | Claim support |
| FIG. 6 | Individual interesting email incident detail page showing UUID, sender, recipient, subject, action taken, payload, and similar email count for a selected incident.Search in Eureka ↗ | Key embodiment |
| FIG. 7A | Bar graph of at-risk users showing malicious emails received per Holdingsinc.com email address to identify most-targeted recipients.Search in Eureka ↗ | Claim support |
| FIG. 7B | Bubble chart of at-risk Darktrace.com users showing malicious email volume as proportionally sized ellipses for each email address.Search in Eureka ↗ | UI/interface |
| FIG. 8 | Inbound email type pie charts and delivery status donut charts with a top-actions table showing autonomous response module actions and their percentage of total email.Search in Eureka ↗ | Claim support |
| FIG. 9 | Attachment actions report page showing Convert Attachments action statistics including email count, percentage of traffic, unread percentage, and Microsoft suppression rate.Search in Eureka ↗ | UI/interface |
| FIG. 10 | Link action report pages showing Lock Links and Double Lock Links autonomous response statistics with percentages for email traffic actioned and unread rates.Search in Eureka ↗ | UI/interface |
| FIG. 11 | System block diagram of the email protection system 100 showing trigger module, gatherer module, analyzer module, assessment module, formatting module, autonomous email-report composer, data store, and AI models.Search in Eureka ↗ | System architecture |
| FIG. 12 | Block diagram of the autonomous email-report composer cooperating with libraries, AI models, data store, and user interface to produce an email threat report.Search in Eureka ↗ | Key embodiment |
| FIG. 13 | Process flow diagram of the email protection system analysis pipeline from timestamped data through supervised/unsupervised ML models to formatted report output.Search in Eureka ↗ | Flow diagram |
| FIG. 14 | User interface diagram showing multi-window display of email under analysis with email metrics, network metrics, user metrics, action tabs, and time-window selection.Search in Eureka ↗ | UI/interface |
| FIG. 15 | Network infrastructure block diagram showing email protection system 100 as an appliance with firewalls, DMZ, bridge, load balancer, database cluster, and web server farm.Search in Eureka ↗ | System architecture |
| FIG. 16 | Decision flow diagram of the autonomous response module showing anomaly/threat detection decision leading to nine configurable response actions including Hold, Lock Link, and Convert Attachment.Search in Eureka ↗ | Flow diagram |
| FIG. 17 | Behavioral pattern analysis scatter plot showing chain of anomalous behavior 220 with unusual data transfer, email characteristics, and credential alert events plotted over time with score axis.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 (apparatus), Claim 11 (method), and Claim 20 (CRM), covering the tripartite enforcement structure standard for software-security patents. The 17 dependent claims yield a 5.67:1 dependent-to-independent ratio, which is within the norm for the G06F/H04L software security class. Notably, the independent claims are heavily loaded with functional limitations — particularly Claim 1's multi-clause 'wherein' structure — which creates both richness in written description support and potential prosecution vulnerability under §101.
Core inventive concept: The claims solve the problem of manually drafting comprehensible, audience-tailored cybersecurity reports by providing an autonomous email-report composer that cooperates with AI models and a library of prewritten text templates with fillable blanks, wherein the composer selects from "two or more sections" with "standard pre-written sentences written in a natural language prose" to populate an email threat report tailored to a target audience. The mechanism — specifically the combination of template libraries with AI-model-derived cyber threat data populated into fillable blanks — distinguishes the claims from generic report generation.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | An apparatus | comprising | one or more processing units; non-transitory computer readable medium; formatting module and autonomous email-report composer configured to cooperate with AI models and email protection system modules; libraries of prewritten text and visual representations; templates with two or more sections having standard pre-written sentences and fillable blanks; composer configured to compose email threat report with NLP prose for target audience summarising cyber threats over time period; composer configured to cooperate with libraries using standard pre-written sentences derived from previously generated reports and fillable-blank templates; formatting module configured to format and output report from a plurality of report templates for printable, digital, or machine-readable consumptionSearch prior art ↗ |
| Claim 11 | A method for an email protection system | comprising | configuring autonomous email-report composer to cooperate with AI models and email protection system modules and libraries of prewritten text and visual representations; each template with two or more sections with standard pre-written sentences and visual representations; configuring composer to compose email threat report in human-readable NLP prose summarising cyber threats in email network over time period; configuring composer to cooperate with libraries having standard pre-written sentences and fillable-blank templates populated with current cyber threat data including trend indicators; configuring formatting module to format, present, and output report from first template of plurality for printable, digital, machine-readable, or combination consumptionSearch prior art ↗ |
| Claim 20 | A non-transitory computer readable medium | comprising | computer readable code operable when executed by one or more processing apparatuses in the email protection system to instruct a computing device to perform the method of Claim 11Search prior art ↗ |
Claim Dependency Tree
1 Apparatus comprising processing units, formatting module, and autonomous email-report composer cooperating with AI models, libraries, and templates for NLP email threat report generationSearch Claim 1 prior art ↗
2 Adds: gatherer module, autonomous response module, analyzer module, and data store cooperating with composer to store inbound email flow data points and autonomous response actionsSearch in Eureka ↗
3 Adds: analyzer module and composer configured to identify and supply list of most at-risk users from email network over time periodSearch in Eureka ↗
4 Adds: composer cooperates with AI model trained on composing threat reports to compose in human-readable NLP format at prescribed level of detail for selected target audienceSearch in Eureka ↗
5 Adds: first template contains two or more sections each spanning one or more pages, each section having standard pre-written sentences, visual representations, and fillable blanksSearch in Eureka ↗
6 Adds: composer cooperates with data store and autonomous response module to collect data points and compose information for analysis of one or more specific autonomous response actionsSearch in Eureka ↗
7 Adds: composer cooperates with autonomous action module, data store, and AI model to list actionable actions in light of cyber threats and generate detailed explanation of interesting email incidentsSearch in Eureka ↗
8 Adds: composer cooperates with AI models trained on normal email pattern of life to draw links between email incidents and identify trends between current and similarly targeted future usersSearch in Eureka ↗
9 Adds: composer cooperates with data store to represent complex metrics in visually engaging way including graphs, contact links, pie charts, bar charts, and bubbles with textual analysisSearch in Eureka ↗
10 Adds: composer cooperates with user interface to make email threat report customizable for end user to select what sections appear in the presented and outputted email-threat reportSearch in Eureka ↗
11 Method comprising configuring autonomous email-report composer to cooperate with AI models, libraries of prewritten templates, formatting module for NLP email threat report outputSearch Claim 11 prior art ↗
12 Adds: configuring gatherer module and data store to store inbound email flow data points and autonomous response actions; configuring analyzer module with AI models for normal pattern of life and anomalous email detectionSearch in Eureka ↗
13 Adds: configuring analyzer module and composer to cooperate with data store to identify and supply list of most at-risk users in email network over time periodSearch in Eureka ↗
14 Adds: configuring composer to cooperate with AI model trained on composing threat reports for human-readable NLP output at prescribed detail level for selected target audienceSearch in Eureka ↗
15 Adds: composer cooperates with library of templates where first template has two or more sections each spanning pages with standard pre-written sentences, visual representations, and fillable blanksSearch in Eureka ↗
16 Adds: configuring composer to cooperate with data store and autonomous response module to collect data points for analysis of specific autonomous response actionsSearch in Eureka ↗
17 Adds: configuring composer to cooperate with user interface to make email threat report customizable for end user to select what sections appearSearch in Eureka ↗
18 Adds: configuring composer to cooperate with AI models trained with machine learning on normal email pattern of life to draw links between email incidents identifying trends between current and similarly targeted future usersSearch in Eureka ↗
19 Adds: configuring composer to cooperate with data store to represent complex metrics visually including graphs, contact links, pie charts, bar charts, bubbles with textual analysisSearch in Eureka ↗
20 Non-transitory CRM with computer readable code to perform the method of Claim 11Search Claim 20 prior art ↗
| Metric | This Application | Software / Cloud 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 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
Claim 1's apparatus claim is structurally rich, with well-layered 'wherein' clauses tying the autonomous email-report composer to specific AI model cooperation and template library mechanics, creating strong spec–claim consistency. However, the almost exclusively functional language in the independent claims — particularly phrases like 'cooperate with' and 'configured to cooperate' throughout Claims 1 and 11 — creates meaningful §101 Alice exposure that the hardware tie-in (processing units and non-transitory CRM) only partially mitigates.
✅
Antecedent Basis
Antecedent basis is generally clean across the 20 claims. Elements introduced in Claim 1 — such as "the autonomous email-report composer," "the formatting module," and "the one or more libraries" — are consistently referenced with proper "the" articles in dependent Claims 2–10. Claim 20's reference to "the method of claim 11" is well-anchored. No orphaned antecedents were identified in the reviewed claim set.
✅
Spec–Claim Consistency
The specification provides robust support for Claim 1's key limitations. FIG. 11 and FIG. 12 directly map to the "formatting module" and "autonomous email-report composer" elements. The template library limitation ("libraries of sets of prewritten text and visual representations") maps to the libraries shown in FIG. 12 and extensively described in the detailed description pages 15–18. The "fillable blanks" limitation is addressed at specification columns 15–16. The "trend indicator" limitation in Claims 11 is supported by FIGS. 3–5 and spec column 5–6.
✅
Transition Word Usage
All three independent claims use "comprising" — the broadest open-ended transition — which is strategically correct for software-system claims where additional unclaimed elements (e.g., additional AI models or modules) should not be excluded. The method claim (Claim 11) also uses "comprising" with "further comprising" in dependent claims, which is appropriate. No missed opportunity was identified; use of "consisting of" would have been counterproductive in this technology domain.
⚠️
§112(f) Means-Plus-Function Risk
No explicit "means for" language appears in the claims. However, Claims 1 and 11 make repeated use of "configured to cooperate" phrasing — e.g., "autonomous email-report composer configured to cooperate with Artificial Intelligence (AI) models" — without specifying structural details of how cooperation is implemented. An examiner could argue that "autonomous email-report composer" is a purely functional label without structural definition in the claims themselves, potentially triggering §112(f) treatment and limiting claim scope to the specific disclosed embodiments. The specification does define the composer's components (FIG. 12), partially mitigating this risk.
⚠️
§101 Eligibility Risk
Claims 1 and 11 face meaningful Alice exposure because the core concept — selecting and populating pre-written template sentences with threat data — can be characterized as an abstract idea of organizing and presenting information. The hardware anchor in Claim 1 ("one or more processing units" and "non-transitory computer readable medium") provides a generic computer implementation, but the prosecution history shows non-final and final office actions were issued (Jun. 2021, Aug. 2022, Feb. 2022, Dec. 2021), suggesting the examiner challenged the claims under §101. The strongest §101 defense lies in the AI model cooperation limitation that ties the report composition to dynamically derived "normal email pattern of life" analysis, which provides a technical solution to a technical problem.
✅
Dependent Claim Fallback Quality
The dependent claims add genuinely distinct fallback positions. Claim 3 (most at-risk user list) and Claim 8 (AI-linked email trend identification between similar users) add technically distinct limitations. Claim 7 adds the actionable suggestions component and detailed interesting-incident write-up, which is commercially significant. Claim 9's explicit enumeration of visual representation types (graphs, pie charts, bar charts, bubbles) provides a useful design-around barrier. Claims 12–19 closely mirror Claims 2–10 on the method side, which is structurally sound but does create some redundancy.
⚠️
Abstract Quality
The abstract accurately identifies the autonomous email-report composer and the template-plus-fillable-blanks mechanism, stating "a template for the type of report contains two or more sections in that template. Each section having different standard pre-written sentences written in the natural language prose." However, the abstract omits the technically novel AI-model cooperation element — specifically that the composer uses AI trained on a "normal email pattern of life" to populate the templates — which is the strongest differentiator from prior art. An examiner relying only on the abstract may underweight the AI-pattern-of-life limitation when searching prior art.
✅
Figure Support Quality
Figure support is strong for the core structural limitations. FIG. 11 supports the system module architecture (trigger, gatherer, analyzer, assessment, formatting, autonomous email-report composer). FIG. 12 directly supports the library cooperation mechanism central to Claims 1 and 11. FIGS. 1–10 and 14 support the visual representation limitations (graphs, bubbles, pie charts, bar charts) recited in Claim 9. FIG. 17 supports the behavioral pattern analysis and anomaly-chain limitation described in the specification. The one gap is that no figure explicitly shows the NLP prose generation or sentence selection process from libraries, leaving that key limitation without direct 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.2
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3.8
Claim Type Diversity
4.5
Figure Support Quality
4
Key observation: Claim Type Diversity scores highest (4.5/5.0) because the patent correctly files apparatus (Claim 1), method (Claim 11), and CRM (Claim 20) claims, providing enforcement coverage across all three standard software patent formats and closing the design-around gap of implementing the same system in different claim categories. Prosecution Defensibility scores lowest (3.2/5.0) because the heavily functional "configured to cooperate" language throughout Claims 1 and 11, combined with a prosecution history that required multiple office action responses, indicates the claims were not easily allowable as filed — suggesting the independent claims carried §101 vulnerability that required amendment. Practitioners should note that a continuation filing narrowed to the most technically specific embodiment (AI pattern-of-life model + trend indicator + fillable blank population chain) would likely face less §101 resistance.
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.
No standalone AI training claim filed Trend indicator missing from apparatus claim No claims on autonomous remediation reporting
Unlock Full Analysis — Free Frequently asked questions
US 12,063,243 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