Patent Drafting Analysis of NormShield’s AI-Based Cyber Risk Assessment System | US 2024/0273214 A1
Patent Drafting Analysis of NormShield's AI-Based Cyber Risk Compliance Assessment System | US 2024/0273214 A1
A structural and strategic analysis of NormShield's cybersecurity policy cross-correlation patent, examining claim architecture, drafting quality signals, critical prosecution gaps, and §101 eligibility positioning across all 17 claims.
Spec Words
9,200
Across 5 sections
Draft now ↗
Total Claims
17
1 independent · 16 dependent
Draft now ↗
Figure Sheets
16
System architecture, flow diagrams, mapping tables, compliance output tables
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates the specification at approximately 76% of total words across 16 figure-rich sheets, providing extensive operational narrative for the cyber-aware AI engine, embedding model pipeline, and compliance estimation flow. The claim architecture is narrow — all 17 claims are method claims depending from a single independent Claim 1, which recites an 11-step process that uniquely combines NLP-based embedding, non-intrusive domain discovery, and compliance level estimation. The 16 figures span system-level block diagrams (FIGs. 1A–1B), process flows (FIGs. 2–9), and real-world compliance output tables (FIGs. 10A–12B), offering thorough visual support for the disclosed embodiments.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 16 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1A | High-level block diagram of the cyber-risk assessment system 100 showing data sources 110, network 120, user authentication system 130, standards database 140, cyber intelligence system 150, asset discovery engine 160, questionnaire/policy examiner 170, compliance estimation system 180, remediation engine 190, and AI system 1100.Search in Eureka ↗ | System architecture |
| FIG. 1B | Detailed subsystem block diagram showing document parser engine 172, embedding engine 173, pivot/non-pivot standards databases 141/142, analyzer engine 176, mapping engine 182, compliance estimation engine 183, cyber-aware AI system 1100 with classification engine 1101, transformer library 1102, NLP engine 1103, and cyber-aware AI engine 1104.Search in Eureka ↗ | System architecture |
| FIG. 2 | Flow diagram of the compliance level estimation system, illustrating the pipeline from source document 210 through parse 220, itemize 230, calculate embeddings 240 with pivot embeddings 250, correlate embeddings 260, and calculate compliance levels 270.Search in Eureka ↗ | Flow diagram |
| FIG. 3 | Flow diagram of the document parser system 300 showing document type detection 310 and branching workflows for XLSX/XLSM (steps 320–326), CSV/TXT (step 310 direct), and PDF/DOCX (steps 330–334), ultimately generating an item list with Area, Description, Item ID, Compliance, and Confidence attributes 350.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Block diagram 400 showing the mapping of a source document item list 410 and pivot standard item list 420 through the embedding engine 173, pivot/source embedding databases 174/175, analyzer 176, mapping database 177, mapping engine 182, and compliance level estimation engine 183 with user input 440.Search in Eureka ↗ | Claim support |
| FIG. 5 | Flow diagram 500 illustrating many-to-many mapping from a source document item list 520 through multiple pivot item lists to multiple destination item lists, with the mapping table 530 storing source ID, source item ID, destination ID, destination item ID, and confidence level.Search in Eureka ↗ | Flow diagram |
| FIG. 6 | Flow diagram 600 of the compliance calculation method showing sequential steps: fetch initial parameters 610 (item score threshold, relevance threshold, temperature), determine relevant items 620, map source to pivot 630, calculate confidence/compliance for pivot items 640/650, fetch pivot-to-destination mappings 660, and calculate confidence/compliance for destination items 670/680.Search in Eureka ↗ | Claim support |
| FIG. 7 | Block diagram 700 showing compliance level estimation using technical findings 710 from cyber intelligence system 150, combined with standard mappings 720 (including technical findings-pivot standard mappings 730) through mapping engine 182 and compliance level estimation engine 183 with user input 740.Search in Eureka ↗ | Claim support |
| FIG. 8 | Process diagram 800 for manual classification of cybersecurity data for the cyber-aware AI engine, showing steps: unclassified/unlabelled data 801, organize similarity text pairs 802, label data based on similarity level 803, and produce classified/labeled cybersecurity data 804.Search in Eureka ↗ | Flow diagram |
| FIG. 9 | Training and model setup flow 900 for the cyber-aware AI engine, showing fetch cybersecurity training data 901, input to transformer-based NLP engine 902, set hyperparameters 903, training process 904, output example AI model 905, benchmark 906, and iterative accuracy-based update loop using training data 805 and test data 806.Search in Eureka ↗ | Flow diagram |
| FIG. 10A | Table 1200 showing document parser engine output mapping example_policy.docx to GDPR items P.3 and P.4, displaying item descriptions, matching customer policy file excerpts with similarity percentages (65.72% and 73.17%), and Yes/No compliance results.Search in Eureka ↗ | UI/interface |
| FIG. 10B | Continuation of table 1200 showing GDPR items P.4.2 and P.9 mappings from example_policy.docx with similarity scores of 74.54% and 81.07%, including matched policy excerpts and compliance result Yes.Search in Eureka ↗ | UI/interface |
| FIG. 11A | Table 1230 showing NIST 800-171 item 3.1.22 mapping from example_policy.docx with 68.42% similarity score, matched policy content excerpts about data consent and privacy by design, and a Yes compliance result.Search in Eureka ↗ | UI/interface |
| FIG. 11B | Continuation of NIST 800-171 table 1230 showing item 3.6.3 (incident response capability testing) mapped to example_policy.docx at 66.66% similarity with matched policy content and a star-rating result.Search in Eureka ↗ | UI/interface |
| FIG. 12A | Table 1250 showing the policy examiner system output with updated compliance and completeness levels for multiple standards (NIST 800-53 R4 at 99%, NIST CSF at 99%, ISO 27001 at 100%, GDPR at 82%, CCPA at 100%, CSC-20 at 97%, COBIT 5 at 96%, PCI DSS at 87%, HIPAA at 97%, NIST 800-171 at 98%) after processing example_Policy.docx.Search in Eureka ↗ | UI/interface |
| FIG. 12B | Continuation of table 1250 showing compliance levels for additional standards including CMMC at 98%, NYDFS at 100%, Shared Assessment SIG 2021 at 94%, and Online Trust Alliance at 66%, demonstrating multi-standard simultaneous compliance estimation.Search in Eureka ↗ | UI/interface |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent contains a single independent claim — Claim 1 — which is a method claim comprising 11 enumerated steps (a through k), with all 16 remaining claims dependent upon it, yielding an unusually skewed 16:1 dependent-to-independent ratio well above the software/cloud norm of 4–8:1. There are no system/apparatus or CRM claims, leaving significant claim-type coverage gaps. The single-independent structure concentrates all enforcement leverage on one method claim, creating substantial vulnerability if Claim 1 is rejected or narrowed during prosecution.
Core inventive concept: Claim 1 addresses the problem of labor-intensive, format-inconsistent cybersecurity questionnaire assessments by combining NLP-based embedding correlation of user-uploaded compliance documents against stored standard compliance items — including generation of a 'compliance item map' via embedding correlation — with non-intrusive domain-based digital footprint discovery to compute and then adjust entity compliance level estimates automatically, without requiring direct questionnaire responses from the assessed entity.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method of cyber risk assessment | comprising | storing standard compliance items in a database; generating an embedding modelling system; uploading a user cybersecurity standard with user compliance item as text converted to numeric array; retrieving standard compliance item from database and converting to numeric array; correlating embedded user and standard compliance items to generate compliance item map; determining second model compliance levels from compliance item map; generating improved embedding modelling system from second model levels; discovering entity digital footprint via non-intrusive domain-based gathering; generating entity technical finding from digital footprint and control item; computing entity compliance level estimate from compliance item map and technical finding; adjusting computer process of entity based on computed compliance level estimateSearch prior art ↗ |
Claim Dependency Tree
1 Method of cyber risk assessment — NLP embedding correlation of user compliance documents to standard items, digital footprint discovery, and entity compliance level computation and adjustmentSearch Claim 1 prior art ↗
2 Adds: compliance item map includes one compliance item per compliance item type, eliminating redundancy across standardsSearch in Eureka ↗
3 Adds: generating the embedding modelling system comprises a training stepSearch in Eureka ↗
4 Further: training step comprises training using a Natural Language Processing (NLP) model (depends on Claim 3)Search in Eureka ↗
5 Adds: generating embedding modelling system comprises a testing stepSearch in Eureka ↗
6 Adds: generating embedding modelling system comprises a benchmarking stepSearch in Eureka ↗
7 Further: benchmarking step performed before uploading the user cybersecurity standard (depends on Claim 6)Search in Eureka ↗
8 Adds: generating the improved embedding modelling system is performed continuouslySearch in Eureka ↗
9 Adds: further comprising classifying at least one standard compliance item, first model embedded user compliance level, or first model embedded standard compliance level used to generate the embedding modelling systemSearch in Eureka ↗
10 Further: classifying determines similarity between text within items and text in a training data set (depends on Claim 9)Search in Eureka ↗
11 Adds: at least one of user compliance item and standard compliance item comprises at least one of a network security process, threat detection process, or data storage processSearch in Eureka ↗
12 Adds: adjusting computer process comprises adjusting at least one of network security, threat detection, or data storage processSearch in Eureka ↗
13 Adds: control item comprises at least one of a vulnerability, a cyber-event, or a reputationSearch in Eureka ↗
14 Adds: entity technical finding comprises at least one of a misconfiguration, asset vulnerability, threat, data loss, or cyber-eventSearch in Eureka ↗
15 Further: same compliance item type comprises at least one of data protection, endpoint security, or network security (depends on Claim 2)Search in Eureka ↗
16 Adds: further comprising generating the user cybersecurity standard based on a documentSearch in Eureka ↗
17 Further: document is a questionnaire (depends on Claim 16)Search in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 17 | 15 – 25 |
| Independent claim count | 1 | 2 – 4 |
| Dependent : Independent ratio | 16.00 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Always |
| System / apparatus claims? | No | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The specification provides strong technical depth — particularly the detailed embedding pipeline, transformer-based AI training workflow, and multi-standard compliance calculation logic — giving the single independent Claim 1 meaningful written description support across FIGs. 1A–9. However, the filing's most significant quality weakness is the complete absence of system/apparatus or CRM claims, which leaves the core inventive concept unprotected in the most commercially significant enforcement formats and creates a trivial design-around path for competitors implementing equivalent systems.
✅
Antecedent Basis
The antecedent basis across all 17 claims is clean and consistently maintained. Claim 1 introduces all structural elements (standard compliance items, embedding modelling system, user compliance item, compliance item map, digital footprint, entity technical finding, entity compliance level estimate) with proper indefinite articles, and all dependent claims reference these elements with correct definite articles. For example, Claims 2, 6, 7, 8 all properly reference "the compliance item map," "the embedding modelling system," and "the user cybersecurity standard" introduced in Claim 1 without orphaned antecedent issues.
✅
Spec–Claim Consistency
The specification maps well to Claim 1's limitations. Steps (a)–(c) (storing, generating embedding system, uploading user standard) are directly supported by ¶[0039]–¶[0041] and FIG. 2 (steps 210–240). Step (e) (correlating to generate compliance item map) is supported by FIG. 4 and ¶[0098]–¶[0103]. Steps (h)–(i) (digital footprint discovery and entity technical finding) are supported by FIG. 7 and ¶[0039]–¶[0040]. Step (k) (adjusting computer process) is supported by ¶[0044] and ¶[0058]. No claim limitation appears without corresponding specification support.
✅
Transition Word Usage
Claim 1 correctly uses "comprising" as the open-ended transition word, which is strategically appropriate for a software/AI method claim where additional steps performed by the system would not negate infringement. All 16 dependent claims also use "wherein" for narrowing limitations, which is the correct form. No claim incorrectly uses "consisting of" or "consisting essentially of," which would have fatally closed the claim scope. The "comprising" transition in Claim 1 preserves maximum breadth for the method steps enumerated (a) through (k).
⚠️
§112(f) Means-Plus-Function Risk
A potential §112(f) issue exists in Claim 1's step (b), which recites "generating an embedding modelling system" — a functional label without explicit recitation of the structural algorithm or hardware implementing it. While the specification provides detailed algorithmic support in FIGs. 1B and 4 (embedding engine 173, analyzer 176, cyber-aware AI engine 1104), the claim language does not tie the functional label to a specific structural element, which an examiner could read as a "step for" analog under §112(f). If §112(f) is invoked, claim scope would be limited to the specific transformer/BERT embodiment described in ¶[0030], significantly narrowing enforcement.
⚠️
§101 Eligibility Risk
Claim 1 carries moderate Alice/Mayo exposure because the core concept — correlating text embeddings to produce a compliance map — is fundamentally an abstract data analysis process. The strongest §101 defense is step (h), which recites "discovering a digital footprint of an entity based on an associated domain name using non-intrusive information gathering," which ties the claim to real-world network infrastructure interactions. However, an examiner could characterize steps (b)–(g) as abstract mathematical operations (embedding conversion and correlation) applied to generic computer resources. The absence of specific hardware recitations in Claim 1 weakens the §101 defense compared to what apparatus claims with structural ties to specific computing components would have provided.
⚠️
Dependent Claim Fallback Quality
Several dependent claims add meaningful fallback positions: Claim 2 (one compliance item per compliance item type — a specific de-duplication mechanism), Claims 9–10 (classification via similarity scoring for AI training), and Claims 3–7 (training/testing/benchmarking sub-steps). However, Claims 5 and 6 add structurally parallel limitations (testing step vs. benchmarking step) that differ minimally and could be collapsed during prosecution with little loss of scope. Claims 11 and 12 essentially restate similar process categories (network security, threat detection, data storage) in the context of different claim elements, providing limited independent fallback value. A stronger filing would have included fallback system claims rather than relying entirely on process sub-step variations.
⚠️
Abstract Quality
The abstract (approximately 280 words) adequately describes the system workflow — embedding generation, compliance item map creation, digital footprint discovery, technical finding generation, and compliance level computation — but fails to highlight the novel contribution that distinguishes this invention from generic compliance scanning: the pivot-standard architecture that enables cross-correlation between custom questionnaires and multiple heterogeneous cybersecurity standards simultaneously via a common embedding space. An examiner reading only the abstract would understand the general workflow but could miss the "pivot embedding" architecture's role in making multi-standard cross-correlation computationally tractable, which is the central technical advance over prior art.
✅
Figure Support Quality
Figure support for Claim 1's limitations is comprehensive: the embedding generation steps (b)–(d) are mapped by FIGs. 1B, 2, and 4; the correlation step (e) is shown in FIG. 4 (analyzer 176) and FIG. 6; the digital footprint step (h) is covered by FIG. 7 and FIG. 1A (asset discovery engine 160); the technical finding step (i) is supported by FIG. 7; and the adjustment step (k) is shown in FIG. 1A (remediation engine 190). Real-world output examples in FIGs. 10A–12B directly illustrate the compliance estimation results described in steps (j)–(k). No claim limitation lacks 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
2.5
Prosecution Defensibility
2.8
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3
Claim Type Diversity
1.5
Figure Support Quality
4.5
Key observation: Figure Support Quality scores highest (4.5/5.0) because all 16 sheets directly map to specific claim limitations — the pivot embedding architecture, compliance calculation flow, multi-standard output tables, and AI training loop are all visually documented with numbered component references. Claim Type Diversity scores lowest (1.5/5.0) because the entire 17-claim set consists exclusively of method claims depending from a single Claim 1, with no system, apparatus, or computer-readable medium claims filed — a structural omission that eliminates three of the four standard enforcement vectors for software/AI patents and creates a design-around path for any competitor implementing the same system without performing the exact enumerated method steps. Practitioners reviewing this filing for FTO or validity analysis should note that a continuation filing with apparatus claims directed to the AI system 1100, embedding engine 173, and compliance estimation engine 183 would substantially strengthen the portfolio's commercial defensibility.
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 apparatus claims for AI system Pivot-standard architecture unclaimed OSINT discovery as independent method unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 2024/0273214 A1 — 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