Patent Drafting Analysis of Irdeto B.V.’s Method and System for Preventing and Detecting Security Threats | US 12,197,566 B2
Patent Drafting Analysis of Irdeto B.V.'s Kernel-Level Security Agent for Open-Platform Devices | US 12,197,566 B2
A structural and strategic analysis of US 12,197,566 B2 covering claim architecture, drafting quality, critical gaps, and prosecution positioning for Irdeto's LSM-based dynamic platform security system.
Spec Words
9,800
Across 6 sections
Draft now ↗
Total Claims
8
1 independent · 7 dependent
Draft now ↗
Figure Sheets
14
System architecture, boot flow, security process diagrams
Draft now ↗
Published by PatSnap Insights Team · · 11 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 66% of total specification words (~6,500 of ~9,800), providing extensive embodiment coverage across boot integrity, LKM control, system call table protection, and anti-debug mechanisms. The claim set is unusually compact at only 8 claims — 1 independent method claim and 7 dependent claims — reflecting significant narrowing through the multi-continuation prosecution history spanning back to PCT/CA2012/000298. The 14 drawing sheets provide strong visual support for each major operational scenario, including boot loading (FIG. 4), provisioning (FIG. 5), installation (FIG. 6), runtime integrity (FIG. 7), call stack validation (FIG. 8), and kernel module enforcement (FIG. 10).
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 14 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Prior art static platform security schematic showing secure boot loader 110, ROM with digital certificate, Stage 1 and Stage 2 bootloaders, OS Kernel with signature verification, access control framework, and process isolation.Search in Eureka ↗ | Other |
| FIG. 2A | System architecture embodiment 200 showing the Android OS layered stack from SOC hardware (ROM BIOS, CPU, GPU) through bootloaders, OS Kernel with LSM-compliant Agent 217, Secure Store 218, and Android applications 210a/210b.Search in Eureka ↗ | System architecture |
| FIG. 2B | Alternative embodiment 201 showing the Secure Store 218 located within the Hard Drive or Flash storage 220, rather than as a separate component, with the Agent remaining LSM I/F compliant.Search in Eureka ↗ | System architecture |
| FIG. 2C | Further alternative embodiment 202 showing the Secure Store as Secure Memory 218 located within the SOC base layer 219, with the Agent communicating directly to on-chip secure memory.Search in Eureka ↗ | System architecture |
| FIG. 3 | Detailed dynamic platform security schematic 300 showing the full system with Linux kernel LSM/Agent 336, Signature Verification 338, Process Isolation 326, Secure Store 327, and boot-time vs. run-time integrity verification paths (dotted and solid arrows).Search in Eureka ↗ | Key embodiment |
| FIG. 4 | Boot loading sequence flow diagram 400 showing eight-step process from Device Reset through Device ROM Execution, OS Boot Loader, OS Image Initialization, and Agent Continuous Runtime Operation with Agent Secure Store.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Application provisioning sequence 500 showing how an unsigned asset and unsigned enhanced permission container manifest 510 are processed by the Asset Protection Tool 514 using a Root of Trust 511 to produce a signed and protected asset 513 stored in Application Secure Store 512.Search in Eureka ↗ | Flow diagram |
| FIG. 6 | Application installation permissions sequence 600 showing how the Agent 613 validates the OS Kernel 614, retrieves signed enhanced permission container manifest 611 from Application Secure Store 610, and stores validated permissions in Agent Secure Store 612.Search in Eureka ↗ | Claim support |
| FIG. 7 | Kernel access control runtime integrity flow 700 showing nine-step process where User Application 710 makes OS requests through User Application Request OS Service 711, OS Kernel 712, and Agent 713 evaluating allow/deny decisions via LSM.Search in Eureka ↗ | Claim support |
| FIG. 8 | Runtime call stack signature validation diagram 800 illustrating three address spaces — Application Address Space 810, OS Kernel Address Space 811, and Agent Address Space 812 (shared with kernel) — showing how stack frames are validated during OS kernel service requests.Search in Eureka ↗ | Claim support |
| FIG. 9 | Application permission enforcement flow 900 showing Agent 912 enforcing permissions at runtime by validating against Signed Enhanced Permission Container Manifest 910 stored in Agent Secure Store 911, with allow/deny decisions returned to OS Kernel 913 and Application Code 914.Search in Eureka ↗ | Claim support |
| FIG. 10 | Loadable kernel module (LKM) enforcement process 1000 showing four-step flow where a request to install an LKM 1014 is passed to OS Kernel 1016, forwarded to Agent 1012 via LSM, validated against Agent Secure Store 1018, and an allow/deny decision returned.Search in Eureka ↗ | Claim support |
| FIG. 11 | System call table protection process 1100 showing Agent 1112 receiving memory write requests from OS Kernel 1116 via LSM, performing bounds checking against System Call Table 1113, and returning allow/deny decisions to prevent system call table overwrite attacks.Search in Eureka ↗ | Claim support |
| FIG. 12 | Debug utility blocking process 1200 showing Agent 1212 intercepting Debug Request 1214 passed by OS Kernel 1216 via LSM, evaluating whether to allow or deny the debug utility request to prevent ptrace/ADBd-based rootkit attacks.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 1 independent claim (Claim 1, a method claim) and 7 dependent claims (Claims 2–8), yielding a dependent-to-independent ratio of 7:1 which is above the typical norm for G06F 21/55 system security patents. The single independent claim strategy concentrates all scope in one method claim — no apparatus or system claims are filed — leaving significant design-around and enforcement coverage gaps for system and CRM formats. Claim 1 is structured around a boot ROM verification sequence coupled with an LSM-embedded agent that receives upcalls, validates loadable kernel modules, and installs them only after successful validation against a secure store.
Core inventive concept: The patent addresses the problem of dynamic runtime attacks on open-platform consumer electronic devices that bypass static boot-time security measures, solving it by embedding a secured software agent within the OS kernel using a Linux Security Module (LSM) interface that receives upcalls at kernel access points and performs validation of loadable kernel modules (LKMs) against information stored in a secure store before permitting installation — as recited in Claim 1's elements (i) through (iv). The agent is described as an integral and un-detachable part of the OS kernel (unlike a conventional LKM) that bridges boot integrity verification with continuous runtime enforcement.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method for preventing security threats on a device, the device having a boot ROM, the boot ROM containing executable code | comprising | receiving an OS bootloader component; verifying integrity of OS bootloader via first computed digital signature vs. certificate; loading OS bootloader in device memory; executing OS bootloader to securely load OS image including OS kernel and transfer execution control; initializing OS image by starting OS kernel; starting secured software agent embedded in OS kernel using LSM interface configured to: (i) insert upcalls at kernel access points, (ii) receive request to install loadable kernel module, (iii) perform validation against secure store, (iv) install LKM into OS kernelSearch prior art ↗ |
Claim Dependency Tree
1 Method for preventing security threats on a device with boot ROM — covers boot integrity verification, OS bootloader loading, LSM-embedded agent with upcalls, LKM validation against secure store, and LKM installationSearch Claim 1 prior art ↗
2 Adds: secured software agent has sole access to the secure storeSearch in Eureka ↗
3 Adds: agent validates LKM by computing a hash value and comparing to a known good value (integrity verification process)Search in Eureka ↗
4 Adds: agent further configured to check that the request to install the LKM is a valid requestSearch in Eureka ↗
5 Further: agent passes the result of checking valid request to OS kernel (depends on Claim 4)Search in Eureka ↗
6 Adds: elements (i) through (iii) of Claim 1 are performed dynamicallySearch in Eureka ↗
7 Adds: the request to install a loadable kernel module is performed dynamicallySearch in Eureka ↗
8 Adds: the request to install a loadable kernel module comes from the insmod utility of the OS kernelSearch in Eureka ↗
| Metric | This Application | Software / Security Industry Norm |
|---|---|---|
| Total claims | 8 | 15 – 25 |
| Independent claim count | 1 | 2 – 4 |
| Dependent : Independent ratio | 7.00 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| 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
US 12,197,566 B2 exhibits strong specification depth with detailed figure support across all major operational scenarios (boot, provisioning, runtime enforcement), but the claim set is critically weakened by the absence of any apparatus, system, or computer-readable medium claims — leaving Claim 1 as the sole independent claim after extensive prosecution narrowing through five continuation generations. The dependent claims add meaningful technical fallbacks on hash-based validation (Claim 3), valid-request checking (Claims 4–5), and dynamic operation (Claims 6–7), but the single-claim-type strategy creates substantial enforcement exposure.
✅
Antecedent Basis
The claim set is small enough that antecedent basis is cleanly maintained throughout. Claim 1 introduces "an operating system bootloader component," "a loadable kernel module," and "a secure store" with appropriate indefinite articles, and all subsequent dependent claims reference "the secured software agent," "the loadable kernel module," and "the secure store" with correct definite articles tracing directly to Claim 1. Claims 2–8 contain no orphaned "the" references, and the LSM interface element introduced in Claim 1 is consistently re-referenced in the dependent claims as "the secured software agent."
✅
Spec–Claim Consistency
FIG. 10 and its corresponding description (column 19) directly support the LKM validation elements (i)–(iv) of Claim 1, showing the exact four-step flow where OS Kernel 1016 forwards an LKM request to Agent 1012 via LSM, Agent validates against Agent Secure Store 1018, and returns allow/deny. The boot ROM integrity verification limitation in Claim 1 is supported by FIGS. 3–4 and columns 10–12. The secure store limitation in Claims 2–3 maps to FIGS. 2A–2C (elements 218, 327) and column 9. Every claim limitation has direct figure and paragraph support.
✅
Transition Word Usage
Claim 1 correctly uses "comprising" as its transition, which is the broadest open-ended transition and appropriate here given the multi-step method nature. The "comprising" transition means an accused infringer cannot avoid infringement by performing additional steps beyond those recited. No dependent claim uses "consisting of" or "consisting essentially of" which would be unduly narrow for a security method patent. This is the strategically correct transition choice for a method claim in this technology space.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in any of the 8 claims. Claim 1 uses structural and functional descriptions such as "secured software agent," "configured to insert," and "configured to receive" rather than means-plus-function formulations. The "secured software agent" is defined structurally as being embedded in the OS kernel and implemented using an LSM interface, providing sufficient structural context to avoid §112(f) invocation. The claim language presents no §112(f) risk.
⚠️
§101 Eligibility Risk
Despite being a granted patent, Claim 1 carries moderate Alice/Mayo exposure in post-grant proceedings because the core LKM validation concept (receiving a request, validating against stored data, allowing or denying) could be characterized as an abstract idea of "authorization checking" at step one of the Alice framework. The patent's defense rests on the hardware tie-in of the LSM interface, the boot ROM executable code, and the physical secure store — these are meaningful structural anchors. However, if a petitioner argues that the LSM upcall mechanism is a generic computer function, the claim would need to demonstrate inventive concept in elements (i)–(iv), which describe specific technical interactions rather than purely functional steps.
⚠️
Dependent Claim Fallback Quality
The 7 dependent claims provide some meaningful technical differentiation: Claim 2 (sole access to secure store) and Claim 3 (hash-based integrity verification) add distinct structural limitations. However, Claims 6 and 7 both merely specify that certain steps are "performed dynamically" — a limitation that provides minimal differentiation from Claim 1 since dynamic operation is already implied by the LSM runtime architecture. Claim 8, which specifies the insmod utility as the source of LKM requests, is highly specific and narrows unnecessarily, weakening its value as a fallback position against non-insmod LKM installation vectors.
⚠️
Abstract Quality
The abstract states that "a secured software agent is provided for embedding within the abstraction layer" and is "configured to limit access to the abstraction layer by either blocking loadable kernel modules from loading, blocking writing to the system call table or blocking requests to attach debug utilities" — this accurately describes a broader scope than what Claim 1 actually covers after prosecution narrowing. An examiner or litigation opponent reading only the abstract would expect claims covering system call table blocking and debug utility blocking, neither of which appears in the granted claims, potentially misleading stakeholders about the actual scope of protection.
✅
Figure Support Quality
All structural limitations in Claim 1 have direct figure support: the boot ROM and bootloader chain are shown in FIGS. 1–4, the OS kernel and LSM interface are shown in FIGS. 2A–3, the LKM validation flow is shown in FIG. 10 with numbered steps corresponding to elements (i)–(iv) of Claim 1, and the secure store is shown in FIGS. 2A–2C and 3. The dependent claim limitations — hash validation (Claim 3) and valid-request checking (Claims 4–5) — are supported by the FIG. 10 description in column 19. No claim limitation lacks figure support, which is the patent's strongest drafting attribute.
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
3
Spec–Claim Consistency
4.5
Dependent Claim Coverage
3
Claim Type Diversity
1.5
Figure Support Quality
4.5
Key observation: Spec–Claim Consistency (4.5/5) and Figure Support Quality (4.5/5) are the patent's strongest dimensions — every limitation in Claims 1–8 maps precisely to named figures and specific specification paragraphs, reflecting 14 sheets of purpose-built diagrams covering all operational scenarios. The weakest dimension by a substantial margin is Claim Type Diversity (1.5/5): after five continuation generations, the claim set was reduced to a single method-type independent claim with no system, apparatus, or computer-readable medium counterparts, creating an immediately exploitable gap where a competitor could design and sell an infringing device without performing the claimed method steps. A practitioner reviewing this patent for FTO or licensing purposes should prioritise mapping whether the assignee filed parallel apparatus claims in related patents US 11,514,159 or US 10,120,999.
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 — method-only enforcement gap System call table and anti-debug not claimed Remote command override embodiment unprotected
Unlock Full Analysis — Free Frequently asked questions
US 12,197,566 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