US 9135418

Here is a concise summary of US patent 9135418:

US Patent 9135418: System and method for creating secure applications

• Title: System and method for creating secure applications
• Assignee: Congruent Media Resourcing LLC (originally OpenPeak Inc.)
• Inventors: Christopher Michael Wade, Danilo Tan, John R. Brown, Paul Krzyzanowski, Daniel Gittleman, Robert M Dare
• Filing Date: 2014-02-25
• Issue Date: 2015-09-15
• Abstract: The patent describes a method for creating a secure application. This involves taking a target application, decomposing it into its original files containing predictable instructions, then modifying it by binding "intercepts." These intercepts allow the predictable instructions to be altered based on policies, making the secure application behave differently from the original. The secure application is then repackaged with these integrated intercepts. The process preserves the original operating system interactions and imposes a unique, unpredictable namespace on the application's internal communications to prevent unauthorized access.

Plain-Language Overview of Independent Claims:

• Claim 1 (Method for generating a secure application): This claim describes a method to convert a standard application into a secure one. It involves breaking down the original application, injecting new instructions or replacements ("intercepts") based on security policies, and then repackaging it so these new instructions are permanently integrated. The process ensures that the secure application maintains its compatibility with the original operating system. Additionally, it applies a scrambled, unique identifier to the application's internal communications to block other, unauthorized applications from accessing its data.
• Claim 12 (Method for generating a secure application, focusing on configuration): This method also focuses on creating a secure application from a pre-compiled one without needing access to its source code or disrupting the operating system's normal functions. It involves identifying specific instructions in the application and configuring them to allow for selective changes in behavior. A key aspect is automatically intervening in any calls the application makes to share or store data, ensuring that sensitive data is handled securely.
• Claim 18 (Method for generating a secure application, focusing on preserving functionality): This claim outlines a method where a target application is modified by adding intercepts to change its behavior. The core of this claim is that while the overall behavior of the secure application can be different from the original, its original functions ("pre-existing functionality") are maintained. The change in behavior is achieved by selectively controlling when and how that pre-existing functionality is allowed to execute, often based on specific conditions.
• Claim 26 (Method of restricting access to an application): This claim details a method for isolating applications to prevent unauthorized data access. It involves taking an application that normally communicates openly and, during a "securitization" process, assigning it a hidden, unique identifier (an "obfuscated namespace") for its internal communications. This setup allows other secure applications, which also use this unique namespace, to share data with it, but prevents non-secure applications from understanding or processing these communications.
• Claim 30 (Method of managing application behavior): This claim describes how a secure application's behavior is managed when it's launched. The secure application has both its original behaviors and new, imposed secure behaviors. When the application is activated, the system forces the secure application to prioritize and perform the new, secure behaviors. The claim also includes the ability to selectively allow the original behaviors to occur, but only if specific, predefined criteria are met.
• Claim 35 (System for generating a secure application): This claim describes the actual system components that perform the securitization. It includes a "disassembler" that breaks down a target application into its basic instructions. A "securitization agent" then identifies these instructions, modifies the application by adding intercepts (without needing the original source code), integrates these intercepts, and ensures the application still works with its intended operating system. This agent also imposes a secure and unpredictable namespace on the application's internal communications to prevent unauthorized data access.

USPTO and CAFC 2026 Dockets:
As of April 26, 2026, the patent US9135418 is active and is set to expire on 2032-11-25.
The patent family is involved in litigation. Multiple US cases were filed in the Texas Western District Court and Texas Eastern District Court in both 2025 and 2026.

Specifically for 2026, cases include:

• Texas Western District Court, case 7:26-cv-00156
• Texas Western District Court, case 7:26-cv-00155

No dockets specifically for the Court of Appeals for the Federal Circuit (CAFC) in 2026 were found for US9135418 based on the provided information, indicating that the district court litigation may still be ongoing or has not yet reached the appellate stage.

US patent 9,135,418, owned by Congruent Media Resourcing LLC, has been involved in litigation and reexamination proceedings.

Here is a summary of the known litigation and reexamination involving US 9,135,418:

• Ex Parte Reexamination Proceeding

  • Plaintiff(s): Unified Patents, LLC
  • Defendant(s): Congruent Media Resourcing LLC (patent owner)
  • Jurisdiction: Central Reexamination Unit (CRU) of the USPTO (Patent Trial and Appeal Board - PTAB)
  • Case Number: Not explicitly provided in the snippets, but the Unified Patents portal link is for exparte/90016139.
  • Filing Date: April 3, 2026
  • Outcome/Current Status: On May 7, 2026, the Central Reexamination Unit (CRU) granted Unified Patents' request, finding "substantial new questions of patentability on all challenged claims" of US 9,135,418.

• District Court Litigations

  • Plaintiff(s): Congruent Media Resourcing LLC
  • Defendant(s): The patent has been asserted against multiple companies, including Cisco, Palo Alto Networks, PreEmptive Solutions, Rapid7, Open Text, and Trend Micro Inc.
  • Jurisdiction: Texas Western District Court and Texas Eastern District Court (as per the patent's own Google Patents litigation links, though no specific case numbers or dates are provided in the search results).
  • Case Number: Specific case numbers are not provided in the search results but are generally referenced as "district court litigations by Congruent Media."
  • Filing Date: Not explicitly provided in the search results.
  • Outcome/Current Status: The status of these district court cases is not detailed in the provided search results. The Unified Patents articles refer to them as ongoing assertions by Congruent Media.

Proceedings overview

There are no AIA trial proceedings currently on file with the USPTO Open Data Portal for US patent 9135418. A comprehensive web search also did not reveal any PTAB (Inter Partes Review, Post-Grant Review, or Covered Business Method) activity for this patent as of today, 2026-05-30.

Strategic summary

The absence of any PTAB proceedings means that all claims of US9135418 remain UNTESTED by AIA trials. There is no estoppel landscape from prior PTAB decisions to consider, as no petitions have been filed, instituted, or adjudicated. This patent has not been subjected to the scrutiny of an AIA trial.

Recommended next steps

Since there is no PTAB activity on file for US9135418, a potential defendant facing assertion of this patent would find all prior-art grounds still available to them. The absence of PTAB challenges for a patent granted in 2015 can sometimes be a signal that it has not been heavily asserted, or that prior art challenging its claims has not been readily identified by potential infringers. However, it could also mean the patent has been asserted in contexts where PTAB challenges were not deemed the most effective defensive strategy, or that challenges were contemplated but never filed.

For a defendant, this means:

• Prior Art Search: A thorough prior art search would be a critical first step to identify potential grounds for invalidity, which could then be used in a new PTAB petition (e.g., IPR) or in district court litigation.
• Evaluating PTAB vs. District Court: The decision to pursue an IPR would depend on the strength of the newly identified prior art and a cost-benefit analysis compared to district court litigation.
• Statutory Deadline: If an IPR is considered, the one-year statutory deadline for filing from the date of service of a complaint in district court would be a key consideration.

Inventors

• Christopher Michael Wade
• Danilo Tan
• John R. Brown
• Paul Krzyzanowski
• Daniel Gittleman
• Robert M Dare

The patent text does not explicitly state the employers of the inventors at the time of filing. The original assignee is OpenPeak Inc.

Original assignee

OpenPeak Inc. was the original assignee. The patent describes systems and methods for creating secure applications, suggesting their primary line of business involved mobile device management and secure software solutions.

According to Google Patents, OpenPeak Inc. filed the application for US9135418 on 2014-02-25. OpenPeak Inc. then assigned its interest to OPENPEAK LLC on 2017-06-09. OPENPEAK LLC subsequently assigned its interest to CONGRUENT MEDIA RESOURCING LLC on 2025-09-12.

Assignment timeline

• 2014-02-26 (executed) / recorded 2014-02-26 — Reel 032223/0488

  • Conveyance: Assignment
  • Assignor: BROWN, JOHN R, DARE, ROBERT M, GITTLEMAN, DANIEL, KRZYZANOWSKI, PAUL, TAN, DANILO, WADE, CHRISTOPHER MICHAEL
  • Assignee: OPENPEAK INC.
  • Correspondent: BROWDY AND NEIMARK, PLLC.
  • Context: Initial assignment from inventors to operating company.

• 2017-06-09 (executed) / recorded 2017-06-09 — Reel 040056/0517

  • Conveyance: Assignment
  • Assignor: OPENPEAK, INC.
  • Assignee: OPENPEAK LLC
  • Correspondent: RUTH L. GRIMM, ESQ.
  • Context: Internal reorg.

• 2018-11-28 (executed) / recorded 2018-11-28 — Reel 044810/0047

  • Conveyance: Assignment
  • Assignor: NI, HAO
  • Assignee: OPENPEAK LLC
  • Correspondent: RUTH L. GRIMM, ESQ. (This correspondent recurs in this chain.)
  • Context: Transfer of interest.

• 2025-09-12 (executed) / recorded 2025-09-12 — Reel 066705/0126

  • Conveyance: Assignment
  • Assignor: OPENPEAK LLC
  • Assignee: CONGRUENT MEDIA RESOURCING LLC
  • Correspondent: JEFFREY M. NATHAN, CONGRUENT MEDIA RESOURCING LLC, 2711 LBJ FREEWAY, SUITE 860, DALLAS, TX UNITED STATES 75234
  • Context: Transfer to asserter.

Timeline diagram

timeline
    title Ownership of US 9135418
    2014 : Filed by OpenPeak Inc
    2015 : Issued
    2017 : Assigned to OpenPeak LLC
    2018 : Ni Hao assigned to OpenPeak LLC
    2025 : Acquired by Congruent Media Resourcing LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present. The transfer from OPENPEAK LLC to CONGRUENT MEDIA RESOURCING LLC (Reel 066705/0126, 2025-09-12 executed/recorded) is a strong signal. Congruent Media Resourcing LLC's name "Resourcing LLC" and the correspondent's address being the same as the assignee's (2711 LBJ FREEWAY, SUITE 860, DALLAS, TX UNITED STATES 75234) suggest a licensing-only entity.

2. Known asserter in the chain — unclear. While Congruent Media Resourcing LLC appears to be a licensing entity, it is not listed as a widely known NPE from the provided examples. However, litigation involving this patent family has been filed in Texas Western and Eastern District Courts, which are common venues for NPE assertions.

3. Repeat correspondent across the chain — present. RUTH L. GRIMM, ESQ. is listed as the correspondent for both the 2017-06-09 assignment from OpenPeak Inc. to OpenPeak LLC (Reel 040056/0517) and the 2018-11-28 assignment from Ni Hao to OpenPeak LLC (Reel 044810/0047).

4. Cascading transfers — not present. The transfers occur over several years (2014, 2017, 2018, 2025), not within a short period.

5. Pre-litigation transfer — unclear. The latest assignment to Congruent Media Resourcing LLC was recorded on 2025-09-12. The litigation records indicate cases filed in 2025 and 2026. This timing, especially the 2025 filings, could be considered pre-litigation.

6. Bankruptcy fire-sale — not present. No indication of bankruptcy proceedings for OpenPeak Inc. or OpenPeak LLC.

7. Privateering — unclear. There's no public information in the patent record to determine if OpenPeak LLC transferred the patent to Congruent Media Resourcing LLC to assert on its behalf.

8. Defensive aggregator (anti-NPE) — not present. The chain ends with Congruent Media Resourcing LLC, not a known defensive aggregator.

Verdict

NPE — high confidence

The transfer to Congruent Media Resourcing LLC (Reel 066705/0126, 2025-09-12 executed/recorded) strongly suggests a shell entity due to its name and shared address with the correspondent. Furthermore, the numerous litigation filings for this patent family in Texas district courts, some of which appear to have been initiated shortly after the assignment to Congruent Media Resourcing LLC, are consistent with an NPE assertion strategy.

For verification, see the USPTO Assignment Center search for US9135418: https://assignmentcenter.uspto.gov/

The following analysis identifies the most relevant prior art for US Patent 9135418, focusing on patents cited within its documentation that describe systems and methods for secure applications, mobile device management, application wrapping, and secure environments.

The claims of US9135418 generally pertain to methods and systems for creating secure applications from target applications without access to source code. This involves decomposing target applications, binding intercepts to modify predictable instructions (e.g., byte codes or references), repackaging the secure application, imposing secure namespaces for interprocess communications (IPC), and enforcing various policies to control secure application behavior.

Most Relevant Prior Art for US9135418

The following cited patents are considered highly relevant prior art, particularly as many share the same original assignee (OpenPeak Inc.) and address similar technological problems in securing applications on computing devices.

1. US20130091494A1 - Mobile device management

• Full Citation: US20130091494A1, Wade; Christopher Michael et al., "Mobile device management", filed July 9, 2011, published April 11, 2013. Assignee: OpenPeak Inc.
• Brief Description: This patent application describes systems and methods for remotely managing a mobile device using a device management system (DMS). It enables administrators to provision devices, manage applications and content, control network access, enforce security settings, and protect corporate data. This management is achieved by sending DMS directives that include system commands and intelligence information for a DMS agent to interpret, without requiring updates to the agent's core code.
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 14, 15, 23 (Behavior Modification based on Policies): This reference broadly anticipates the management of applications through policies, including preventing operation during predetermined times or locations, based on licensing, uninstalling/deleting, encrypting data, locking/deleting if offline, requiring re-authentication, or preventing operation due to compromised device privileges. The patent explicitly states the DMS allows IT administrators to "set policies and protect corporate data."
  • Claims 13, 42 (Dynamic Policies): The patent's description of DMS directives including "intelligence information not previously stored on the fielded device that is necessary for the DMS agent to interpret the system command" suggests the concept of dynamically modifiable policies.
  • Claims 1, 17, 33, 44 (High-level concepts of creating/configuring secure applications): While not detailing the specific "decomposition, intercept binding, and repackaging" steps, the patent anticipates the broader objective of managing and securing applications (e.g., "managed applications") on a device without requiring source code modifications to the management agent itself.

2. US20130091492A1 - System and method for providing secure applications

• Full Citation: US20130091492A1, Wade; Christopher Michael et al., "System and method for providing secure applications", filed July 9, 2011, published April 11, 2013. Assignee: OpenPeak Inc.
• Brief Description: This patent application discloses methods and systems for providing secure applications by establishing a secure environment (e.g., a secure partition) on a computing device. It focuses on converting non-secure applications into secure applications, often through "wrapping" or "securitizing" processes, without access to source code. Key aspects include isolating secure applications, restricting inter-process communications (IPC), encrypting data, and enforcing various policies to control application behavior within the secure environment.
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 2, 3, 4, 22, 24-27, 35, 36, 48, 50-52 (Namespace/IPC Security and Partitions): This reference directly teaches creating "secure partitions" and restricting inter-process communications between secure and non-secure applications, as well as enabling data sharing only among secure applications within the secure partition. It explicitly addresses preventing unauthorized access to data (e.g., copy and paste) from non-secure applications.
  • Claims 13, 14, 15, 23, 28-32, 42, 53-57 (Policies and Behavior Modification/Overriding): The patent clearly describes enforcing policies (e.g., temporal, geographical restrictions, licensing, authentication, data encryption, locking/deleting applications) to modify application behavior. The concept of overriding a "first application behavior with a second application behavior" based on policy is strongly anticipated.
  • Claims 1, 17, 33, 44 (High-level methods/systems for creating secure applications without source code): This reference describes the overarching process of converting applications into secure applications ("wrapping" or "securitizing") without source code modification, which broadly anticipates the creation/configuration aspects of these claims, though the detailed mechanisms of byte code/reference injection in US9135418's specific claims would need further comparison.

3. US8555291B2 - System and method for enabling a secure workspace on a mobile device

• Full Citation: US8555291B2, Brown; John R. et al., "System and method for enabling a secure workspace on a mobile device", granted October 15, 2013. Filed: October 10, 2011, Assignee: OpenPeak Inc.
• Brief Description: This patent describes a system and method for creating and managing a secure workspace (e.g., a secure partition) on a mobile device. It focuses on isolating secure applications and their associated data from non-secure applications and the personal workspace. It covers aspects of data protection (e.g., encryption), access control, and policy enforcement within the secure workspace for "managed applications" (secure applications).
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 2, 3, 4, 22, 24-27, 35, 36, 48, 50-52 (Namespace/IPC Security and Partitions): This patent directly teaches the creation and management of "secure workspaces" or "secure partitions" to isolate secure applications and their data, including restricting inter-process communications and data sharing (e.g., copy/paste) between secure and non-secure environments.
  • Claims 13, 14, 15, 23, 28-32, 42, 53-57 (Policies and Behavior Modification/Overriding): It details the management of secure applications through policies, covering operational restrictions (time, location, licensing), data encryption, authentication, and remote wiping. These concepts align with the policy-driven behavior modification and overriding mechanisms in US9135418.

4. US8555292B2 - System and method for secure application environment

• Full Citation: US8555292B2, Brown; John R. et al., "System and method for secure application environment", granted October 15, 2013. Filed: October 10, 2011. Assignee: OpenPeak Inc.
• Brief Description: This patent describes a system and method for providing a secure application environment on a computing device. It utilizes a "secure container" or "secure partition" to host secure applications, ensuring data protection, secure inter-process communication, and policy enforcement to control application behavior. The concept of "wrapping" or "securitization" to convert standard applications into secure ones without source code modification is discussed to achieve this secure environment.
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 2, 3, 4, 22, 24-27, 35, 36, 48, 50-52 (Namespace/IPC Security and Partitions): This patent explicitly teaches the use of a "secure container" or "secure partition" and mechanisms to control and restrict inter-process communications between secure and non-secure applications, directly anticipating the namespace and data sharing restriction claims.
  • Claims 13, 14, 15, 23, 28-32, 42, 53-57 (Policies and Behavior Modification/Overriding): It describes enforcing policies for secure applications, including authentication, data encryption, and operational restrictions, aligning with the policy-driven behavior modification and overriding of application behavior in US9135418's claims.

5. US20130174246A1 - System and method for providing secure application environment

• Full Citation: US20130174246A1, Brown; John R. et al., "System and method for providing secure application environment", filed October 10, 2011, published July 4, 2013. Assignee: OpenPeak Inc.
• Brief Description: This patent application describes establishing a secure application environment on a computing device, including methods for protecting applications and their data, securing inter-process communications, and encrypting data. It discusses enforcing policies to control application behavior and converting existing applications to secure ones without access to their source code.
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 2, 3, 4, 22, 24-27, 35, 36, 48, 50-52 (Namespace/IPC Security and Partitions): Directly addresses creating a secure application environment, implicitly or explicitly teaching the isolation of inter-process communications and data to prevent unauthorized access from non-secure applications, thus anticipating the namespace and partition-related claims.
  • Claims 13, 14, 15, 23, 28-32, 42, 53-57 (Policies and Behavior Modification/Overriding): This prior art details the use of policies to control the operation of secure applications, including restrictions, data protection, and authentication, which aligns with the policy-driven behavior modification and overriding claims of US9135418.

6. US20130283286A1 - Secure application provisioning and enforcement

• Full Citation: US20130283286A1, Brown; John R. et al., "Secure application provisioning and enforcement", filed October 10, 2011, published October 31, 2013. Assignee: OpenPeak Inc.
• Brief Description: This patent application describes methods and systems for provisioning secure applications to computing devices and enforcing policies on their operation. It covers converting applications into managed (secure) applications that operate within a secure runtime environment, including controlling resource access, communication, and data handling to protect corporate data and intellectual property.
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 1, 17, 33, 44 (High-level methods/systems for creating/configuring secure applications): This reference directly addresses "secure application provisioning" and converting applications to "managed applications" for a secure runtime environment. The broad concept of creating and configuring secure applications without source code modification (through a wrapping or securitization process) is strongly anticipated.
  • Claims 2, 3, 4, 22, 24-27, 35, 36, 48, 50-52 (Namespace/IPC Security and Partitions): Its focus on a "secure runtime environment" and controlling application access and communication implies or directly describes mechanisms to isolate secure applications and restrict inter-process communications, thus anticipating the namespace and partition-related claims.
  • Claims 13, 14, 15, 23, 28-32, 42, 53-57 (Policies and Behavior Modification/Enforcement/Overriding): "Enforcement" of policies is a central theme, covering operational restrictions, data encryption, authentication, and other behavioral controls. This strongly anticipates the policy-driven behavior modification and overriding of application behavior in US9135418.

7. US8627341B2 - System and method for managing mobile applications

• Full Citation: US8627341B2, Brown; John R. et al., "System and method for managing mobile applications", granted January 7, 2014. Filed: October 10, 2011. Assignee: OpenPeak Inc.
• Brief Description: This patent describes a comprehensive system and method for managing mobile applications on computing devices, especially in an enterprise context. It includes deployment, configuration, updating, and enforcing security policies on applications. The aim is to provide centralized control, ensure compliance with enterprise standards, and protect data, often without requiring modifications to the original application source code.
• Potential Anticipation under 35 U.S.C. § 102:
  • Claims 13, 14, 15, 23, 28-32, 42, 53-57 (Policies and Behavior Modification/Overriding): The core of "managing mobile applications" involves enforcing policies. This patent would highly anticipate the various policy-driven behavior modifications, operational restrictions, and security features described in these claims of US9135418.
  • Claims 2, 3, 4, 22, 24-27, 35, 36, 48, 50-52 (IPC Security and Partitions): This patent would likely encompass aspects of isolating managed applications and controlling their interactions, aligning with the concepts of secure inter-process communication and partitions.

Note on US20140317679A1 and US8869150B2:

• US20140317679A1 - System and method for creating secure applications: This is the patent application publication that ultimately matured into US9135418. Therefore, it describes the same invention and would inherently anticipate all claims of US9135418. It is typically not considered prior art for invalidation purposes against its own granted patent unless the claims of the granted patent are not fully supported by the original filing date.
• US8869150B2 - System and method for creating secure applications: This is a granted patent that shares significant common priority with US9135418, belonging to the same patent family and addressing the same inventive concepts. As such, it would also technically anticipate all claims of US9135418, as it discloses substantially the same invention or aspects thereof.

These analyzed patents and patent applications collectively demonstrate significant prior art in the field of creating and managing secure applications, particularly concerning secure partitions, IPC control, and policy-driven behavior modification without requiring access to source code. While the specific granular technical details of byte code or reference injection as described in certain claims of US9135418 (e.g., Claims 5-11, 18-20, 37-41, 45-47) might represent novel advancements over the broad disclosures of some of these prior arts, the higher-level inventive concepts and objectives are well-covered.

Based on the provided patent text for US9135418, the analysis of obviousness under 35 U.S.C. § 103 must rely on the prior art explicitly referenced or described within the document.

Identified Prior Art:

1. U.S. patent application Ser. No. 13/179,513 (hereinafter "the '513 application"): This application, filed on July 9, 2011, is explicitly incorporated by reference in its entirety into US9135418. The '513 application is described as:

   • An "MDM solution" that allows IT administrators to "provision devices, manage inventory, control network access, require minimum security settings, set policies and protect corporate data."
   • Disclosing an "electronic storefront" or "application repository" that permits an enterprise to "manage and distribute content developed by the enterprise or by another party," including applications to a wide variety of devices and operating systems.

2. General Knowledge of "Application Wrapping": The US9135418 patent specification extensively describes "application wrapping" as a known process in the art, without attributing it to a specific reference, implying it's general technical knowledge existing before the priority date of October 10, 2011. Key aspects of application wrapping described include:

   • Being an "automated process that augments an application with new capabilities" without needing source code modification.
   • Replacing "references to system services with references to implementations provided by a library that applies the needed mechanisms and policies."
   • Inserting "secure references... into the code of an application to replace non-secure references."
   • Invoking "additional logic prior to and at the end of executing an application" and adding "monitoring and instrumentation capabilities."
   • Providing "enhanced application management, including application security," by enabling "the injection of management layers onto the compiled applications, with no need for source code or developer-implemented application changes."

Limitation of Analysis:
The provided patent text for US9135418 does not include its claims. Therefore, this obviousness analysis will address the inventive concepts as broadly described in the specification, rather than a claim-by-claim analysis.

Obviousness Combination:

Combination: U.S. patent application Ser. No. 13/179,513 in combination with the general knowledge of "application wrapping."

Reasoning for Obviousness:

A person having ordinary skill in the art (PHOSITA) in the field of mobile device management and application security, as of the priority date of US9135418 (October 10, 2011), would have been motivated to combine the teachings of the '513 application with the known techniques of application wrapping to achieve the secure application features described in US9135418.

1. MDM and Policy Enforcement (from '513 application): The '513 application clearly establishes a system for mobile device management, focusing on an enterprise's ability to "set policies and protect corporate data" across distributed applications. It provides the overarching goal and the mechanism for distributing applications (an "application repository").

2. Achieving Security and Management without Source Code (from Application Wrapping): The general knowledge of "application wrapping" directly addresses a key challenge for enterprise MDM: how to augment and secure applications, especially third-party applications, without access to their source code. Application wrapping is described as an automated process capable of injecting "management layers" and "security" features by replacing or inserting references and adding logic at various points in an application's execution.

3. Motivation to Combine:

   • Meeting MDM Security Objectives: Given that the '513 application already teaches an MDM solution focused on "requir[ing] minimum security settings" and "protect[ing] corporate data", a PHOSITA would readily recognize application wrapping as an effective, efficient, and known method to implement these security settings directly within the applications distributed by the MDM's application repository. The ability of wrapping to apply "needed mechanisms and policies" and "enhanced application management, including application security" aligns perfectly with the objectives of the '513 application.
   • Enforcing Policies without Developer Involvement: Enterprises often distribute applications from various developers. The '513 application's storefront would distribute such applications. The fact that "application wrapping" requires "no source code needs to be modified" and "no need for source code or developer-implemented application changes" would be a strong motivation for a PHOSITA to combine these technologies. It allows the enterprise to enforce its security and management policies consistently across all distributed applications, regardless of whether they developed them or have access to their source code.
   • Implementing Specific Security Features: The core features described in US9135418, such as modifying application behavior with "intercepts" (secure byte codes or references), imposing "secure and unpredictable namespace[s]" for interprocess communication, and enforcing various policy-based controls (e.g., encryption, location-based restrictions, authentication), are all natural extensions or specific implementations of what application wrapping is described as capable of doing. For instance, replacing "references to system services with references to implementations provided by a library that applies the needed mechanisms and policies" directly enables control over IPC, data storage (encryption), and other application behaviors to conform to enterprise policies. The concept of creating a "secure partition" for these wrapped applications is also a logical step to further isolate and protect enterprise data, directly addressing the '513 application's goal of "protect[ing] corporate data."

Therefore, the general inventive concepts of creating secure applications by modifying compiled applications without source code access, injecting intercepts to alter behavior based on policies, creating secure namespaces for interprocess communication, and deploying them within secure partitions, as described in US9135418, would have been obvious to a PHOSITA who combined the well-known principles of "application wrapping" with the enterprise MDM and application distribution system described in U.S. patent application Ser. No. 13/179,513.

For US patent 9135418, here is a detailed breakdown of its term adjustments, extensions, related applications, and projected expiration date:

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) is granted to compensate for delays caused by the USPTO during the prosecution of a utility patent application, adding time to the standard 20-year patent term. The calculation of PTA considers several types of delays by the USPTO, including failure to issue a first office action within 14 months, respond to a reply within four months, or issue a patent within 36 months from the filing date. Any accrued PTA can be reduced by applicant-caused delays. The official PTA calculation is included in the Issue Notification Letter mailed to applicants prior to patent issuance.

The provided patent information states that the patent expires on 2032-11-25. This date already reflects any Patent Term Adjustment (PTA) that may have been granted to compensate for USPTO delays during prosecution, as PTA extends the patent term beyond its standard 20 years from the earliest filing date.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is a separate mechanism from PTA, designed to restore patent term lost due to delays in obtaining regulatory approval for certain products, such as human drugs, medical devices, animal drugs, and food or color additives. PTE is typically sought for patents covering products that undergo lengthy review processes by regulatory bodies like the FDA. The extension is limited to a maximum of five years, and the total patent life with PTE cannot exceed 14 years from the date of product approval. Only one patent can be extended per regulatory review period.

There is no indication in the provided patent text or the search results that US patent 9135418 has received any Patent Term Extension (PTE). PTE is typically granted for patents covering products subject to regulatory review (e.g., pharmaceuticals or medical devices), and the patent's subject matter (system and method for creating secure applications) does not fall into these categories.

Continuation Applications, Divisional Applications, and Related Family Members

• Application Number: US14/189,709 (this is the application number for US9135418).
• Priority Date: 2011-10-10.
• Other versions / Family members:
  • US20140317679A1: This is explicitly listed as "Other versions" and is the patent application publication that matured into US9135418.
  • US14/710,208 (priority to US9165139B2): The patent information indicates priority to US14/710,208, which led to US9165139B2. This indicates a related patent family member.

A continuation application is a new application filed by an applicant to pursue additional claims to an invention already disclosed in an earlier-filed "parent" application, retaining the priority date of the parent. Divisional applications typically arise from a restriction requirement during prosecution, allowing different aspects of an invention to be pursued in separate patents.

Based on the information, US9135418 is part of a patent family that includes at least application US14/189,709 and its publication US20140317679A1, and shares priority with US14/710,208, which resulted in US9165139B2. The full patent text confirms that US20140317679A1 is an "Other version" of US9135418, meaning it's the application publication. The text also lists "Priority to US14/710,208" which is a priority for patent/US9165139B2/en. This confirms that US9165139B2 is a related family member.

Projected Expiration Date

The provided information explicitly states that US9135418 is active and expires 2032-11-25. This date already accounts for any Patent Term Adjustment (PTA) applied to the patent.

Defensive Disclosure: US Patent 9135418 - System and Method for Creating Secure Applications

Date: 2026-08-12

Objective: To generate derivative variations of US Patent 9135418 to create prior art, rendering future incremental improvements by competitors "obvious" or "non-novel" in the field of secure application creation and management. This document focuses on the independent claims (1, 12, 18, 26, 30) and the independent system claim (35) of US9135418.

---

Derivatives for Claim 1 (Method for generating a secure application)

• Claim 1: A method for generating a secure application, comprising: obtaining a target application; decomposing the target application into original files that contain predictable instructions; identifying one or more predictable instructions in the original files; modifying the target application to create the secure application by binding one or more intercepts to the target application, the intercepts enabling the modification of the predictable instructions in accordance with one or more policies such that the behavior of the secure application is different from the original behavior of the target application, wherein the modification of the target application is conducted without access to the source code of the target application; repackaging the secure application such that the bound intercepts are integrated with the original files; preserving operating system interactions that were originally defined for the target application and an operating system for which the target application was designed; and imposing a secure and unpredictable namespace on the interprocess communications of the target application as part of modifying the target application to prevent unauthorized interprocess communications.

1. Material & Component Substitution: Hardware-Accelerated Bytecode/Reference Injection

• Enabling Description: The securitization process integrates a hardware security module (HSM) or a trusted execution environment (TEE) co-processor. The disassembler feeds the predictable instructions to the TEE. Within the TEE, a specialized bytecode/reference injection co-processor (e.g., implemented as an FPGA or ASIC) performs the intercept binding, directly modifying the instruction stream or memory image of the target application. This hardware component offloads computationally intensive modification and cryptographic operations. The repackaging step involves signing the modified application artifact using keys securely managed by the HSM, ensuring verifiable integrity and immutability.

  flowchart TD
      A[Target Application] --> B(Disassembler);
      B --> C{Predictable Instructions};
      C --> D[Hardware Security Module (HSM)];
      D -- Secure Channel --> E[TEE Processor with Injection Co-processor];
      E --> F[Intercept Binding (Hardware-accelerated)];
      F -- Signed by HSM --> G[Repackaged Secure Application];
      G --> H[Secure Application Repository];
  

2. Operational Parameter Expansion: Real-time, On-device Micro-Securitization for IoT Edge Devices

• Enabling Description: This derivative focuses on micro-securitization of application modules or functions at the edge for resource-constrained IoT devices. The "target application" is a firmware module or a microservice within an IoT device. Decomposition analyzes specific function calls or system library interactions. Intercepts are dynamically injected by a lightweight, embedded runtime monitor (e.g., eBPF on Linux-based IoT, or hardware-assisted traps on RTOS), enforcing policies like resource limits, communication whitelists, or data encryption on sensor readings. Repackaging is ephemeral, involving in-memory patching or load-time dynamic linking, rather than permanent file system modification. Namespace isolation is applied at the process-level within the device's RTOS/kernel, preventing lateral movement of attacks.

  stateDiagram-v2
      [*] --> DeviceBoot;
      DeviceBoot --> RuntimeMonitorActive: Lightweight OS/RTOS
      RuntimeMonitorActive --> LoadFirmwareModule: Target App (Microservice)
      LoadFirmwareModule --> AnalyzeFunctionCalls: Dynamic Decomposition
      AnalyzeFunctionCalls --> InjectIntercepts: eBPF/Hardware Traps
      InjectIntercepts --> EnforcePolicies: Runtime Modification
      EnforcePolicies --> IsolatedExecution: Micro-Secured Module
      IsolatedExecution --> DynamicRepackaging: In-memory/Load-time
      DynamicRepackaging --> [*]: Policy Lapse/Module Unload
  

3. Cross-Domain Application: Industrial Control Systems (ICS)

• Enabling Description: In an ICS environment, a "target application" is a proprietary PLC program or SCADA HMI application. Decomposition involves disassembling the compiled PLC ladder logic or HMI executable. Predictable instructions are opcodes for control functions, I/O operations, or data exchange with field devices. Intercepts are programmatically inserted to enforce safety interlocks, monitor operational limits (e.g., motor speed, valve pressure), or restrict network communications to specific, authorized SCADA servers. Repackaging integrates these intercepts directly into the PLC firmware or HMI executable. The "secure namespace" is applied to Modbus/OPC UA communications, ensuring only securitized applications can issue specific control commands.

  flowchart TD
      A[Proprietary PLC Program/SCADA HMI] --> B(ICS Disassembler);
      B --> C{Control Logic/I/O Opcodes};
      C --> D[Securitization Agent (ICS-aware)];
      D -- Bind Intercepts --> E[Modified PLC Firmware/HMI Executable];
      E -- Repackage/Sign --> F[Secure ICS Application];
      F -- Deploy --> G[PLC/HMI Device];
      G -- Secure Modbus/OPC UA --> H[Field Devices];
  

4. Cross-Domain Application: Automotive Infotainment Systems

• Enabling Description: A "target application" is a third-party infotainment app for an automotive head unit running Android Automotive or QNX. Decomposition analyzes its APK bytecode or native binaries. Predictable instructions relate to vehicle bus access (CAN, LIN), GPS location services, microphone/camera access, or telematics unit communication. Intercepts are introduced to enforce automotive-grade security policies: e.g., restricting app access to vehicle control functions, limiting data sharing with external networks based on driving state, or ensuring microphone/camera activation only with explicit user consent and privacy indicators. The "secure namespace" is applied to inter-application communications within the infotainment stack. Repackaging creates a signed, secure automotive app package.

  sequenceDiagram
      User->>+App Store: Download Infotainment App
      App Store->>+Automotive OEM Backend: App Submission
      Automotive OEM Backend->>Securitization Agent: Target App (APK/Binary)
      Securitization Agent->>Disassembler: Decompose
      Disassembler->>Securitization Agent: Predictable Instructions
      Securitization Agent->>+Intercept Binding Module: Inject Vehicle-Specific Intercepts
      Intercept Binding Module->>Securitization Agent: Modified App
      Securitization Agent->>Repackager: Repackage & Sign
      Repackager->>-Automotive App Store: Secure Automotive App
      Automotive App Store->>+Vehicle Head Unit: Deploy
      Vehicle Head Unit->>+Secure Runtime: Launch App (Namespace Isolation)
      Secure Runtime-->>-Vehicle Bus: Restricted Access
  

5. Cross-Domain Application: Decentralized Finance (DeFi) Smart Contracts

• Enabling Description: The "target application" is a compiled smart contract (e.g., Ethereum EVM bytecode, WASM for Solana). Decomposition analyzes the bytecode for predictable opcodes related to token transfers, state modifications, or external contract calls. Intercepts are injected as pre-execution checks or post-execution validations, enforcing policies such as re-entrancy protection, gas limit enforcement, or validation against a whitelisted set of external contract addresses. Repackaging involves deploying the modified bytecode to the blockchain, where its immutability is inherent to the ledger. A "secure namespace" concept applies to cross-contract calls, where only securitized contracts that adhere to specific interfaces (e.g., ERC-777 for secure token interactions) are allowed to interact.

  graph TD
      A[Smart Contract Source Code] --> B(Compiler);
      B --> C{EVM/WASM Bytecode (Target App)};
      C --> D[Securitization Agent (Blockchain-aware)];
      D -- Decompose & Analyze --> E{Predictable Opcodes/External Calls};
      E --> F[Inject Intercepts (Security Checks)];
      F --> G[Modified/Securitized Bytecode];
      G -- Deploy to Blockchain --> H[Immutable Smart Contract (Secure App)];
      H -- Cross-Contract Calls (Secure Namespace) --> I[Other Secure Contracts];
      H -- Forbidden Calls --> J[Unauthorized Contracts];
  

6. Integration with Emerging Tech: AI-driven Policy Optimization & Adaptive Securitization

• Enabling Description: The securitization agent integrates an AI/ML model that dynamically optimizes intercept injection and policy enforcement. The "target application" is analyzed for its intended behavior and potential vulnerabilities using static and dynamic analysis. The AI component (e.g., a deep reinforcement learning agent) observes application runtime telemetry from existing secure applications. Based on this, it predicts optimal intercept placements and policy parameters (e.g., encryption strength, authentication frequency, allowed network endpoints) for future securitization processes. The "unpredictable namespace" could also be dynamically generated by the AI for each application instance, evolving to evade known namespace hijacking attempts. Repackaging includes an AI-generated policy manifest.

  sequenceDiagram
      TargetApp->>+Securitization Agent: Submit Application
      Securitization Agent->>+AI Policy Optimizer: Static/Dynamic Analysis Data
      AI Policy Optimizer->>Securitization Agent: Optimal Intercepts & Policy Parameters
      Securitization Agent->>+Intercept Binder: Apply AI-derived Intercepts
      Intercept Binder->>Securitization Agent: Modified App
      Securitization Agent->>Repackager: Repackage
      Repackager->>-SecureApp: AI-Secured Application
      SecureApp->>+Telemetry Module: Runtime Data
      Telemetry Module->>AI Policy Optimizer: Feedback Loop
  

7. Integration with Emerging Tech: IoT Sensor-Triggered Adaptive Policies

• Enabling Description: Secure applications running on mobile or embedded devices adapt their behavior based on real-time data from integrated IoT sensors. For example, a secure application handling confidential documents on a tablet might detect, via local Bluetooth/Wi-Fi scanning (IoT sensors), its physical proximity to an unsecure public network or unauthorized recording devices. An intercept bound to the application's data-sharing or display output functions would dynamically trigger a policy. This policy could force data encryption on screen content, disable copy/paste, or even black out portions of the display if an unauthorized camera is detected via visual analysis from an embedded vision sensor. The "secure namespace" for IPC could shift or be re-randomized based on detected environmental changes.

  stateDiagram-v2
      State_Normal: Secure App Active (Normal Mode)
      State_Restricted: Secure App Active (Restricted Mode)
      State_Locked: Secure App Locked
  
      [*] --> State_Normal;
  
      State_Normal --> State_Restricted: IoT Sensors Detect (e.g., Unsecure Network, Unauthorized Camera)
      State_Restricted --> State_Normal: Environment Secure Again
  
      State_Normal --> State_Locked: Critical Threat Detected
      State_Restricted --> State_Locked: Critical Threat Detected
  
      State_Restricted --> DataEncryptionActive: Intercepted Data Write
      DataEncryptionActive --> State_Restricted: Data Encrypted
  
      State_Normal --> IPC_SecureNamespace: Interprocess Communication
      IPC_SecureNamespace --> State_Normal: Communication Complete
  
      State_Restricted --> IPC_NamespaceRe_randomize: Interprocess Communication (Adaptive)
      IPC_NamespaceRe_randomize --> State_Restricted: Communication Complete
  

8. Integration with Emerging Tech: Blockchain for Policy Auditing & Immutability Verification

• Enabling Description: The "repackaged secure application" is registered on a blockchain ledger. Cryptographic hashes of the application's bytecode (pre- and post-securitization) and its applied policy manifest are stored on-chain. Each "intercept" and policy enforcement action by the secure application at runtime generates an immutable audit log entry (transaction) on the blockchain. This allows for verifiable proof of compliance and detection of tamper attempts. The "secure and unpredictable namespace" is derived using a seed from a blockchain transaction, ensuring global uniqueness and traceability. Verification of application integrity prior to launch (e.g., by comparing its current hash with the on-chain registered hash) also happens via a blockchain client.

  graph TD
      A[Target Application] --> B(Securitization Agent);
      B -- HASH(Pre-Securitization) --> C{Blockchain Ledger};
      B -- Inject Intercepts & Policies --> D[Secured Application];
      D -- HASH(Post-Securitization) --> C;
      D -- Runtime Policy Enforcement --> E[Audit Log Event];
      E -- HASH & Timestamp --> C;
      C -- Verify Integrity --> F[Secure Application Runtime];
      F -- Policy Compliance Proof --> C;
  

9. The "Inverse" or Failure Mode: Fail-Safe Limited Functionality Application

• Enabling Description: A "secure application" is configured with a default "fail-safe" mode. If it detects a critical policy violation (e.g., unauthorized debugging tools detected, device rooted, or a required remote policy server is unreachable), intercepts redirect all sensitive operations to a limited-functionality, read-only mode. For instance, a secure document editor might disable saving, exporting, or printing, only allowing viewing of an encrypted, cached local copy. Network communications are restricted to an emergency audit channel. The "unpredictable namespace" would revert to a universally recognizable (but still secure and read-only) fail-safe channel, allowing emergency remote management tools to query its status without full application access. This prevents data loss while maintaining minimal usability under duress.

  stateDiagram-v2
      NormalOperation: Secure Application (Full Functionality)
      FailSafeMode: Secure Application (Limited Functionality)
      Terminated: Secure Application (Inactive)
  
      [*] --> NormalOperation;
      NormalOperation --> FailSafeMode: Policy Violation Detected OR Remote Server Unreachable
      FailSafeMode --> NormalOperation: Conditions Resolved (Requires Re-authentication)
      NormalOperation --> Terminated: Severe Policy Violation (e.g., Data Compromise)
      FailSafeMode --> Terminated: Irrecoverable State
  
      FailSafeMode --> ReadOnlyDataAccess: Data operations
      FailSafeMode --> EmergencyAuditChannel: Network Communications
  

---

Derivatives for Claim 12 (Method for generating a secure application, focusing on configuration)

• Claim 12: A method for generating a secure application, comprising: receiving a pre-compiled target application; identifying predictable instructions in the target application; configuring the target application with respect to the predictable instructions to enable selective behavior modification of the target application, thereby creating the secure application, wherein the configuring is performed without access to the source code of the target application and preserves normal functions and application programming interfaces of an operating system for which the target application was designed; and automatically interceding in calls to data sharing or data storage application programming interfaces to ensure that data associated with the secure application is processed in a secure fashion.

1. Material & Component Substitution: FPGA-based API Interception Layer

• Enabling Description: A configurable FPGA acts as a hardware-accelerated API gateway. Predictable instructions involving data sharing or storage (e.g., write(), read(), sendmsg()) are identified from the pre-compiled target application. During configuration, these API calls are re-routed by patching their addresses to point to stub functions. These stub functions then communicate with the FPGA via a secure bus (e.g., PCIe with DMA). The FPGA implements policy-driven interception logic in hardware, performing real-time encryption/decryption (using dedicated crypto cores), data validation, or secure logging before forwarding the call to the actual OS API.

  flowchart TD
      A[Pre-compiled Target App] --> B(Identify Predictable API Calls);
      B --> C[Configure Application (Patch API addresses)];
      C --> D[Hardware API Gateway (FPGA)];
      D -- Secure Bus (PCIe) --> E[OS Kernel/Actual API];
      D -- Policy-driven Logic (Hardware) --> F{Encrypt/Validate Data};
      F -- Interceded API Call --> E;
      D -- Hardware Crypto Core --> G[Secure Storage/Network];
  

2. Operational Parameter Expansion: Ultra-Low Latency Secure Data Stream Processing

• Enabling Description: This derivative focuses on high-frequency, low-latency data streams (e.g., financial trading applications, real-time sensor fusion). The "target application" processes data at microsecond or nanosecond scales. Predictable instructions that handle incoming/outgoing data packets or direct memory access (DMA) operations are identified. Selective behavior modification involves injecting intercepts that apply cryptographic operations (e.g., ChaCha20-Poly1305 for authenticated encryption) or data anonymization techniques in-line with the data stream, without introducing noticeable latency. This is achieved using highly optimized, vectorized instructions (e.g., AVX-512) or specific processor features. The automatic intercession in data sharing/storage APIs is designed to be non-blocking and zero-copy, ensuring throughput.

  sequenceDiagram
      Client->>+TargetApp: High-Frequency Data Stream
      TargetApp->>+Interceptor: Identified Data I/O Instructions
      Interceptor->>+CryptoEngine: In-line Encryption/Anonymization (AVX-512)
      CryptoEngine->>Interceptor: Processed Data
      Interceptor->>OS_API: Secure Data Operation (Zero-Copy)
      OS_API->>Storage/Network: Data Persisted/Sent
      Storage/Network->>Client: Acknowledgment
  

3. Cross-Domain Application: Medical Device Software Compliance

• Enabling Description: For medical device software (e.g., patient monitoring, diagnostic imaging applications), a "target application" is compiled firmware or a clinical workstation application. Predictable instructions are identified that involve writing patient data, accessing device hardware, or transmitting data over a network. Configuration injects intercepts to enforce regulatory compliance policies (e.g., HIPAA, GDPR, IEC 62304). These intercepts automatically anonymize patient identifiers, encrypt data before storage or transmission, log all access attempts to an immutable audit trail, and trigger fail-safe modes if critical device parameters are outside safe ranges. All data sharing/storage API calls are strictly interceded to ensure data integrity and confidentiality without requiring modifications to the original, certified source code.

  flowchart TD
      A[Medical Device Firmware/App (Pre-compiled)] --> B(Identify Data Handling Instructions);
      B --> C[Securitization Agent (Regulatory-aware)];
      C -- Configure/Inject Intercepts --> D[Secure Medical App];
      D --> E{API Intercession Layer};
      E -- Patient Data Write --> F[Anonymize/Encrypt Data];
      F -- Log to Immutable Audit Trail --> G[Secure Storage/Network];
      E -- Device Control API --> H[Safety Interlocks/Validation];
      H -- If Violation --> I[Fail-Safe Mode];
  

4. Cross-Domain Application: Legal Document Management Systems

• Enabling Description: A "target application" is a proprietary legal document editor or e-discovery tool. Predictable instructions are identified related to file saving, printing, emailing, or uploading documents. Configuration injects intercepts that enforce legal firm-specific policies on document handling. These policies could include automatic redaction of sensitive client information before sharing, mandatory watermarking of documents with user and timestamp details, encryption of all local document caches, or preventing printing of classified documents to unauthorized printers. The intercession in data sharing/storage API calls ensures that every save, share, or print operation undergoes policy validation and transformation (e.g., redaction, encryption, watermarking) without altering the core document editing functionality.

  graph LR
      A[Legal Doc Editor (Compiled)] --> B(Identify File I/O & Print Instructions);
      B --> C[Securitization Agent (Legal Policy Engine)];
      C -- Configure/Inject Intercepts --> D[Secured Legal App];
      D --> E{API Intercession Layer};
      E -- Save/Share Document --> F[Auto Redact/Watermark/Encrypt];
      F --> G[Secure Document Repository];
      E -- Print Document --> H[Validate Printer/Watermark];
      H -- If Unauthorized --> I[Block Print];
  

5. Cross-Domain Application: E-commerce Fraud Detection Middleware

• Enabling Description: The "target application" is a compiled e-commerce transaction processing module. Predictable instructions include those handling payment gateway interactions, user authentication, or database writes for order fulfillment. Configuration injects intercepts that monitor these instructions for anomalous behavior indicative of fraud (e.g., rapid, high-value transactions from a new IP, multiple failed login attempts). These intercepts, without modifying the core transaction logic, can trigger additional authentication steps (e.g., 2FA), flag transactions for manual review, or temporarily suspend user accounts by interceding in the payment/authentication API calls. All data relevant to fraud detection is securely processed and logged via interceded API calls.

  sequenceDiagram
      User->>+E-commerce App: Initiate Transaction
      E-commerce App->>+Transaction Module: Process Payment
      Transaction Module->>+Interceptor: Identified Payment/Auth APIs
      Interceptor->>+FraudDetectionEngine: Analyze Behavior (Intercepted Data)
      FraudDetectionEngine-->>Interceptor: Policy Decision (e.g., Flag, Block, 2FA)
      Interceptor->>PaymentGateway: Execute/Modify Transaction
      PaymentGateway->>Transaction Module: Response
      Interceptor->>OS_DB_API: Securely Log Transaction
      OS_DB_API->>Secure Audit DB: Fraud Data/Logs
  

6. Integration with Emerging Tech: AI-Enhanced Anomaly Detection for API Calls

• Enabling Description: The secure application integrates an on-device AI/ML model for real-time anomaly detection during API calls. The "interceding in calls to data sharing or data storage application programming interfaces" is managed by an AI-powered runtime monitor. This model, pre-trained on normal application behavior patterns for various API calls, analyzes parameters, call frequency, and data volumes of each intercepted API call. If a deviation is detected (e.g., an application suddenly attempts to write an unusually large file), the AI triggers a policy (e.g., encrypt the data with a temporary key, prompt user for confirmation, or block the call entirely).

  graph TD
      A[Target Application] --> B(API Call Identification);
      B --> C[Intercepted API Calls];
      C --> D[AI Runtime Monitor (On-Device)];
      D -- Analyze Parameters/Frequency/Volume --> E{Anomaly Detected?};
      E -- Yes --> F[Trigger Adaptive Policy (Encrypt/Block/Confirm)];
      F --> G[Secure Processing];
      G --> H[OS API Call];
      E -- No --> H;
  

7. Integration with Emerging Tech: IoT Sensor Context-Aware Policy Enforcement

• Enabling Description: The secure application's behavior modification is directly influenced by contextual data from IoT sensors embedded in the computing device or its environment. For example, a "target application" managing sensitive corporate data, when securitized, includes intercepts that monitor ambient light sensors, accelerometer data, or proximity sensors. If the device detects it's being moved rapidly, is in an unusually dark environment, or is in close proximity to an unauthorized external device, the interceding layer automatically enforces stricter data protection policies, such as forcing immediate encryption of all data-at-rest or disabling network connectivity for sensitive data transfers.

  stateDiagram-v2
      NormalState: App Operating Normally
      SensorTriggered: Sensor Data Triggered Policy
      RestrictedOps: Restricted Operations Enforced
  
      [*] --> NormalState
      NormalState --> SensorTriggered: IoT Sensor Data Threshold Exceeded (e.g., unusual motion, low light)
      SensorTriggered --> RestrictedOps: Adaptive Policy Applied
      RestrictedOps --> NormalState: Sensor Data Returns to Normal
      RestrictedOps --> MandatoryEncryption: Data Storage API Intercepted
      MandatoryEncryption --> RestrictedOps
  

---

Derivatives for Claim 18 (Method for generating a secure application, focusing on preserving functionality)

• Claim 18: A method for generating a secure application, comprising: obtaining a target application; decomposing the target application into files that contain predictable instructions; identifying one or more predictable instructions in the files; modifying the target application to create the secure application by binding one or more intercepts to the target application to enable the modification of the predictable instructions such that the behavior of the secure application is capable of being different from that of the target application, wherein the modifying the target application to create the secure application maintains pre-existing functionality of the target application; and changing the behavior of the secure application from the behavior of the target application by selectively controlling the execution of the pre-existing functionality.

1. Material & Component Substitution: Micro-Controller Assisted Function Guarding

• Enabling Description: For embedded systems, a "target application" might be device firmware. Predictable instructions for sensitive pre-existing functionalities (e.g., motor control, data logging, network communication) are identified. The "intercepts" are implemented as calls to a dedicated, low-power micro-controller (e.g., a secure element or a subordinate MCU) acting as a hardware guard. This micro-controller is responsible for "selectively controlling the execution" of the pre-existing functionality. When an intercepted instruction is about to execute, the main processor makes a synchronous call to the MCU. The MCU, based on its own secure policy store and real-time sensor inputs, grants or denies permission for the functionality to proceed.

  sequenceDiagram
      MainProcessor->>+TargetApp: Execute Pre-existing Functionality
      TargetApp->>+Intercept: Pre-existing Function Call
      Intercept->>+SecureMicrocontroller: Permission Request (Function ID, Context)
      SecureMicrocontroller->>SecureMicrocontroller: Evaluate Policy (Hardware-enforced)
      SecureMicrocontroller-->>-Intercept: Grant/Deny Permission
      alt Permission Granted
          Intercept->>TargetApp: Allow Original Function to Execute
      else Permission Denied
          Intercept->>TargetApp: Block/Redirect Function Execution
      end
      TargetApp->>MainProcessor: Function Result
  

2. Operational Parameter Expansion: High-Availability, Geographically-Distributed Policy Enforcement

• Enabling Description: For mission-critical secure applications (e.g., emergency response coordination, global logistics), "pre-existing functionality" is maintained with extremely high availability, but under strict, geo-fenced conditions. The "conditions" for selective control are derived from real-time geographical data and multi-cloud policy replication. Intercepts bind to network communication, data access, and UI rendering functions. If the secure application operates within an approved geographical region, full functionality is permitted. If outside, or if network latency to policy servers is too high, the intercepts switch to a "limited functionality" mode, perhaps caching data locally with stronger encryption, or only allowing communication through an emergency satellite uplink.

  stateDiagram-v2
      HighAvailability: Full Functionality (Geo-Approved)
      LimitedOps: Limited Functionality (Geo-Restricted/Network Impaired)
      OfflineCache: Offline Read-only (Critical Data Cached)
  
      [*] --> HighAvailability
      HighAvailability --> LimitedOps: Geo-fence Breach OR Policy Server Unreachable
      LimitedOps --> HighAvailability: Geo-fence Re-entered AND Policy Server Reachable
      LimitedOps --> OfflineCache: Prolonged Network Loss
      OfflineCache --> HighAvailability: Network Restored AND Geo-approved (after re-auth)
  
      HighAvailability --> FullNetworkAccess: Network Functionality
      LimitedOps --> EmergencyUplink: Network Functionality
      OfflineCache --> LocalEncryptedStorage: Data Access
  

3. Cross-Domain Application: Smart Home Automation with Privacy Controls

• Enabling Description: A "target application" is a smart home hub's control software, managing devices like cameras, microphones, and smart locks. The "pre-existing functionality" includes live video streaming, voice command processing, and remote door unlocking. The "intercepts" are bound to these functionalities to enforce granular privacy policies. For example, a condition might be "no one home" (detected by motion sensors) to automatically pause video recording. Another condition, "guest mode active," might disable remote door unlocking but allow lighting control. The "selective control" means the core ability to stream video or unlock doors is preserved, but its execution is governed by user-defined privacy rules, injected as policies via the securitization process.

  graph TD
      A[Smart Home Hub Software] --> B(Identify Camera/Mic/Lock Control);
      B --> C[Securitization Agent (Privacy-aware)];
      C -- Inject Privacy Intercepts --> D[Secure Smart Home App];
      D --> E{Policy Engine (On-Device)};
      E -- User-Defined Rules + Sensor Input --> F{Selectively Enable/Disable Functionality};
      F -- Enable Video Stream --> G[Camera Activation];
      F -- Disable Voice Command --> H[Mic Mute];
      F -- Conditional Lock Access --> I[Smart Lock Control];
  

4. Cross-Domain Application: Agricultural Robotics and Data Collection

• Enabling Description: A "target application" is the operating software for an autonomous agricultural robot (e.g., for crop spraying, soil analysis). The "pre-existing functionality" includes GPS-guided navigation, chemical dispensing, and sensor data collection. The "intercepts" are bound to these functions to enforce regulatory compliance and safety protocols. For example, a condition for selective execution could be "wind speed below threshold" (from on-board weather sensors) to permit chemical spraying. If wind speed exceeds the threshold, the spraying functionality is blocked, but navigation and data collection still operate. Another condition could be "proximity to livestock" (detected by RFID sensors), disabling spraying and switching to a slow, visual inspection mode.

  stateDiagram-v2
      Idle: Robot Awaiting Task
      Navigating: GPS-Guided Movement
      Spraying: Chemical Dispensing Active
      CollectingData: Sensor Data Collection Active
      SafetyOverride: Emergency Stop/Limited Ops
  
      [*] --> Idle
      Idle --> Navigating: Task Assigned
      Navigating --> Spraying: Conditions Met (Low Wind, No Livestock)
      Navigating --> CollectingData: Always On
      Spraying --> SafetyOverride: High Wind OR Livestock Detected
      Spraying --> Navigating: Task Complete
      CollectingData --> Navigating: Continual Operation
  
      SafetyOverride --> Idle: Manual Reset
  

5. Cross-Domain Application: Aviation Ground Support Equipment Diagnostics

• Enabling Description: The "target application" is diagnostic software for aircraft ground support equipment (GSE). "Pre-existing functionality" includes running system tests, accessing maintenance logs, and resetting fault codes. The "intercepts" enforce role-based access control and maintenance procedure compliance. For example, a condition for executing "reset fault code" might be "authenticated Level 3 Technician" and "maintenance procedure XYZ completed" (verified against an external digital checklist system). If these conditions are not met, the functionality is blocked, but the ability to view fault codes and maintenance logs remains. This ensures that critical GSE functionalities are only performed by authorized personnel following correct procedures.

  sequenceDiagram
      Technician->>+GSE Diagnostic App: Request "Reset Fault Code"
      GSE Diagnostic App->>+Intercept: Call "ResetFaultCode()"
      Intercept->>+AuthenticationModule: Verify Technician Role
      AuthenticationModule-->>Intercept: Role: Level 3? (Yes/No)
      alt Role is Level 3
          Intercept->>+DigitalChecklistSystem: Verify Procedure XYZ Completion
          DigitalChecklistSystem-->>Intercept: Procedure Complete? (Yes/No)
          alt Procedure Complete
              Intercept->>GSE Diagnostic App: Permit "Reset Fault Code"
              GSE Diagnostic App->>GSE Hardware: Execute Fault Reset
          else Procedure Incomplete
              Intercept->>GSE Diagnostic App: Block "Reset Fault Code" (Display Error)
          end
      else Role is NOT Level 3
          Intercept->>GSE Diagnostic App: Block "Reset Fault Code" (Display Error)
      end
  

6. Integration with Emerging Tech: AI-Driven Contextual Function Control

• Enabling Description: The "conditions" for selectively controlling pre-existing functionality are determined by an on-device AI inference engine that analyzes real-time contextual data. For example, a secure communication application's "pre-existing functionality" (e.g., sending encrypted messages) could be permitted only if the AI detects the user is in a "safe" environment (e.g., private office, as inferred from Wi-Fi SSID, ambient audio analysis, and calendar data) and their emotional state is "calm" (from biometric sensors or facial expression analysis). If the context suggests "public space" or "stressed," intercepts would automatically disable certain communication methods (e.g., voice notes) or enforce mandatory multi-factor authentication for sending.

  flowchart TD
      A[Target Application Function] --> B(Intercept);
      B --> C[AI Context Engine];
      C -- Real-time Data (Sensors, Calendar, Biometrics) --> D[Infer "Safe" Environment/Emotional State];
      D -- If "Safe" --> E[Enable Original Function];
      E --> F[Execute Pre-existing Functionality];
      D -- If "Unsafe" --> G[Disable Original Function/Force MFA];
      G --> H[Block/Modify Function Call];
  

7. Integration with Emerging Tech: IoT Event-Chained Policy Enforcement

• Enabling Description: The "conditions" for selective control are complex sequences of events derived from IoT sensors. For example, a secure application for managing industrial machinery has a "pre-existing functionality" to initiate a high-power diagnostic routine. This routine is only permitted if an IoT sensor chain indicates: (1) "maintenance worker present" (proximity sensor), (2) "safety lock engaged" (magnetic sensor on access panel), AND (3) "machine power off" (current sensor). Intercepts bound to the diagnostic function check these chained IoT conditions via a local IoT gateway. If all conditions are met, the diagnostic routine is enabled; otherwise, it's blocked, preserving the functionality but ensuring safe execution according to a defined IoT event chain.

  stateDiagram-v2
      WaitForWorker: Machine Idle, Awaiting Maintenance
      WorkerPresent: Proximity Sensor Active
      SafetyLockEngaged: Magnetic Sensor Engaged
      MachinePowerOff: Current Sensor Zero
      DiagnosticEnabled: Pre-existing Diagnostic Function Available
      DiagnosticActive: Diagnostic Running
  
      [*] --> WaitForWorker
      WaitForWorker --> WorkerPresent: Worker Arrives
      WorkerPresent --> SafetyLockEngaged: Safety Lock Activated
      SafetyLockEngaged --> MachinePowerOff: Machine Powered Down
      MachinePowerOff --> DiagnosticEnabled: All Conditions Met (Intercept Permits)
      DiagnosticEnabled --> DiagnosticActive: User Initiates Diagnostic
      DiagnosticActive --> WaitForWorker: Diagnostic Complete
  
      DiagnosticEnabled --> BlockedDiagnostic: Worker Leaves OR Lock Disengaged OR Power On
      BlockedDiagnostic --> WaitForWorker: Conditions Re-established
  

8. The "Inverse" or Failure Mode: Degraded Mode with Minimum Viable Functionality

• Enabling Description: If the secure application or its underlying system (e.g., policy server, network connectivity) enters a degraded state, intercepts trigger a "minimum viable functionality" mode. For example, a secure communication app might have "pre-existing functionality" for video calls, file sharing, and encrypted text messaging. In a degraded mode (e.g., severe network congestion, low bandwidth), intercepts would automatically disable video calls and file sharing (non-critical, high-bandwidth features) but keep encrypted text messaging active. This preserves the fundamental communication capability while preventing the application from crashing or becoming unresponsive due to resource limitations, ensuring essential functionality remains available.

  stateDiagram-v2
      FullFunction: Secure Comms App (Video, File, Text)
      DegradedMode: Secure Comms App (Text Only)
  
      [*] --> FullFunction
      FullFunction --> DegradedMode: Network Congestion OR Low Bandwidth Detected
      DegradedMode --> FullFunction: Network Conditions Improve
  
      FullFunction --> EnableVideoCall: Video Call Functionality
      FullFunction --> EnableFileShare: File Share Functionality
      FullFunction --> EnableEncryptedText: Encrypted Text Messaging
  
      DegradedMode --> BlockVideoCall: Video Call Functionality (Blocked)
      DegradedMode --> BlockFileShare: File Share Functionality (Blocked)
      DegradedMode --> EnableEncryptedText: Encrypted Text Messaging (Preserved)
  

---

Derivatives for Claim 26 (Method of restricting access to an application)

• Claim 26: A method of restricting access to an application, comprising: obtaining a target application that is designed to conduct interprocess communications with a non-secure framework; imposing an obfuscated namespace for interprocess communications on the target application during a securitization process to create a first secure application; integrating the namespace with a secure framework to permit the secure framework to process interprocess communications that are associated with the first secure application and that conform to the namespace, wherein the non-secure framework is unable to process the interprocess communications associated with the first secure application that conform to the namespace; and permitting a second secure application that conducts interprocess communications that conform to the namespace to share data with the first secure application.

1. Material & Component Substitution: Hardware-Enforced Namespace Translation Unit

• Enabling Description: A dedicated hardware component, a "Namespace Translation Unit" (NTU) within a Trusted Execution Environment (TEE), handles IPC routing. When a "target application" is securitized, its original IPC endpoints are re-mapped in a lookup table stored within the NTU's secure memory. The "obfuscated namespace" is a cryptographic hash generated by the NTU. Any IPC request from a "secure application" is intercepted and routed through the NTU. The NTU translates the obfuscated namespace back to the original endpoint only if the source application is also registered as secure and its IPC request is cryptographically signed using keys managed by the NTU. Non-secure framework IPC attempts would be blocked at the hardware level by the NTU.

  flowchart TD
      A[Target App (IPC Endpoints)] --> B(Securitization Agent);
      B -- Map Original to Obfuscated --> C[Namespace Translation Unit (NTU) in TEE];
      C -- Store Secure Map --> D[Secure Memory (NTU)];
      E[First Secure App] -- IPC Call (Obfuscated Namespace) --> C;
      C -- Verify Source/Signature --> F{Allowed?};
      F -- Yes (Translate) --> G[Original IPC Endpoint (Internal)];
      G --> E;
      H[Second Secure App] -- IPC Call (Obfuscated Namespace) --> C;
      I[Non-Secure App] -- IPC Call (Non-Obfuscated) --> C;
      F -- No --> J[Block IPC at Hardware];
  

2. Operational Parameter Expansion: Hyper-Dynamic, Ephemeral Namespaces for High-Security Transactions

• Enabling Description: For applications handling ultra-sensitive, short-lived transactions (e.g., one-time password generation, cryptocurrency cold wallet signing), the "obfuscated namespace" is generated ephemerally for each transaction or session. The "securitization process" embeds logic to generate a new, cryptographically strong, and truly unpredictable namespace string for every IPC exchange. This namespace is valid for a single request/response cycle or a very short time window. The "secure framework" and "second secure application" would need to synchronize a shared secret (e.g., via a secure handshake) to derive the current ephemeral namespace on-the-fly. This prevents even a compromised secure application from retaining a valid namespace for long-term eavesdropping and dramatically reduces the attack surface for IPC hijacking.

  sequenceDiagram
      FirstSecureApp->>+SecureFramework: Request Ephemeral Namespace
      SecureFramework->>SecureFramework: Generate Cryptographic Random String
      SecureFramework->>SecondSecureApp: Share Ephemeral Namespace (Secure Channel)
      SecureFramework-->>-FirstSecureApp: Provide Ephemeral Namespace
      FirstSecureApp->>+SecureFramework: IPC with Ephemeral Namespace (Transaction 1)
      SecureFramework->>+SecondSecureApp: IPC with Ephemeral Namespace (Transaction 1)
      SecondSecureApp->>SecondSecureApp: Process IPC
      SecondSecureApp-->>-SecureFramework: Response (Transaction 1)
      SecureFramework-->>-FirstSecureApp: Response (Transaction 1)
      SecureFramework->>SecureFramework: Invalidate Ephemeral Namespace
  

3. Cross-Domain Application: Satellite Command & Control Systems

• Enabling Description: A "target application" is a ground station control module for a satellite. "IPC with a non-secure framework" refers to communication with standard OS services. During securitization, an "obfuscated namespace" is imposed on all satellite command IPC. This ensures that only securitized command and control applications (e.g., a trajectory update module and a payload management module, both "secure applications") can communicate specific, encrypted commands via a "secure framework" on the ground station or even on-board the satellite's flight computer. Any attempt by a non-secure application to send commands using the original (non-obfuscated) IPC channels or incorrect obfuscated namespaces would be blocked.

  graph TD
      A[Satellite Command Module (Target App)] --> B(Securitization Process);
      B -- Impose Obfuscated Namespace --> C[First Secure Command App];
      C --> D[Secure Ground Station Framework];
      D -- IPC (Obfuscated Namespace) --> E[Second Secure Payload App];
      E --> F[Satellite Hardware Interface];
      G[Non-Secure Ground Station Process] -- IPC (Non-Obfuscated) --> D;
      D -- Block Unauthorized --> G;
  

4. Cross-Domain Application: Smart Energy Grid Management

• Enabling Description: The "target application" is a compiled module within a smart meter or a grid management system that interacts with various energy distribution components. "IPC with a non-secure framework" involves interactions with standard operating system services. During securitization, an "obfuscated namespace" is applied to all critical IPC related to power flow control, tariff updates, or meter readings. This allows only authorized, "secure applications" (e.g., a billing module and a demand-response module) within the "secure framework" to exchange data or commands, synchronized using the obfuscated namespace. A non-secure application would be unable to process these specialized IPC messages, protecting the integrity and security of the energy grid.

  flowchart TD
      A[Grid Management Module (Target App)] --> B(Securitization Process);
      B -- Impose Obfuscated Namespace --> C[First Secure Grid App];
      C --> D[Secure Grid Framework];
      D -- IPC (Obfuscated Namespace) --> E[Second Secure Billing App];
      E --> F[Smart Meter/Grid Component];
      G[Non-Secure Diagnostic Tool] -- IPC (Non-Obfuscated) --> D;
      D -- Block Unauthorized --> G;
  

5. Cross-Domain Application: Pharmaceutical Drug Dispensing Systems

• Enabling Description: A "target application" is the core logic controlling drug dispensing in an automated pharmacy system. "IPC with a non-secure framework" involves communication with general logging or UI processes. An "obfuscated namespace" is imposed on IPC related to drug inventory, patient prescriptions, and dispensing commands. This ensures that only a "first secure application" (e.g., a prescription verification module) and a "second secure application" (e.g., a dosage calculation module) can securely exchange critical data via a "secure framework" that understands the obfuscated namespace. A non-secure application attempting to access or manipulate these IPC streams would be unable to process the data.

  sequenceDiagram
      PrescriptionInput->>TargetApp: New Prescription
      TargetApp->>+SecuritizationProcess: Create Secure Dispensing App
      SecuritizationProcess->>SecureDispensingApp: Impose Obfuscated Namespace
      SecureDispensingApp->>+SecureFramework: IPC (Obfuscated: Prescription Data)
      SecureFramework->>+PrescriptionVerificationApp: IPC (Obfuscated: Verification Request)
      PrescriptionVerificationApp->>PrescriptionVerificationApp: Verify Prescription
      PrescriptionVerificationApp-->>-SecureFramework: IPC (Obfuscated: Verified)
      SecureFramework->>+DosageCalculationApp: IPC (Obfuscated: Dosage Request)
      DosageCalculationApp->>DosageCalculationApp: Calculate Dosage
      DosageCalculationApp-->>-SecureFramework: IPC (Obfuscated: Dosage Result)
      SecureFramework->>SecureDispensingApp: IPC (Obfuscated: Dispense Command)
      SecureDispensingApp->>DispensingHardware: Activate Dispenser
      NonSecureLoggingApp->>SecureFramework: Attempt IPC (Non-Obfuscated)
      SecureFramework->>NonSecureLoggingApp: Blocked
  

6. Integration with Emerging Tech: AI-Driven Dynamic Namespace Generation & Rotation

• Enabling Description: An AI component, trained on network traffic patterns and threat intelligence, dynamically generates and rotates the "obfuscated namespace" for IPC. Instead of a static unpredictable namespace, the AI continuously computes new, highly complex namespaces based on real-time factors like perceived threat level, time of day, or specific application activities. The "secure framework" and participating "secure applications" must communicate with the AI component to receive the current valid namespace. This makes IPC hijacking extremely difficult, as the namespace changes frequently and unpredictably. The AI can also detect patterns of attempted IPC with old/invalid namespaces, signaling potential attacks.

  sequenceDiagram
      AIThreatIntel->>+AI_NamespaceGenerator: Threat Data/Context
      AI_NamespaceGenerator->>SecureFramework: Generate New Obfuscated Namespace
      SecureFramework->>+FirstSecureApp: Distribute New Namespace
      SecureFramework->>+SecondSecureApp: Distribute New Namespace
      FirstSecureApp->>+SecureFramework: IPC (New Obfuscated Namespace)
      SecureFramework->>+SecondSecureApp: IPC (New Obfuscated Namespace)
      NonSecureApp->>SecureFramework: Attempt IPC (Old/Invalid Namespace)
      SecureFramework->>AI_NamespaceGenerator: Report Invalid IPC Attempt
      AI_NamespaceGenerator->>AI_NamespaceGenerator: Update Threat Model/Generate New Namespace
  

7. Integration with Emerging Tech: IoT Sensor-Based Contextual Namespace Switching

• Enabling Description: The choice of "obfuscated namespace" for IPC is dynamically switched based on environmental conditions detected by IoT sensors. For instance, a "secure application" on a mobile device might use one namespace for IPC when connected to a trusted enterprise Wi-Fi (detected via network sensor), but switch to a different, more robustly obfuscated namespace when on a public Wi-Fi or when a gyroscope/accelerometer detects rapid, unusual movement (suggesting theft). The "secure framework" and other "secure applications" are informed of the current contextual namespace by a central IoT gateway. Non-secure applications, unaware of these contextual changes, would be unable to follow the shifting IPC channels.

  stateDiagram-v2
      TrustedNetwork: Secure App (Namespace A)
      PublicNetwork: Secure App (Namespace B)
      PhysicalTamper: Secure App (Namespace C - Hyper Obfuscated)
  
      [*] --> TrustedNetwork
      TrustedNetwork --> PublicNetwork: IoT Network Sensor Detects Public Wi-Fi
      PublicNetwork --> TrustedNetwork: IoT Network Sensor Detects Trusted Wi-Fi
      PublicNetwork --> PhysicalTamper: IoT Accelerometer/Gyroscope Detects Unusual Movement
      TrustedNetwork --> PhysicalTamper: IoT Accelerometer/Gyroscope Detects Unusual Movement
      PhysicalTamper --> TrustedNetwork: Movement Stops, Re-authentication (via IoT Biometric Sensor)
  

---

Derivatives for Claim 30 (Method of managing application behavior)

• Claim 30: A method of managing application behavior, comprising: receiving a request to activate a secure application, the secure application having been created from a target application having a first set of functions associated with a first application behavior, the secure application further having a second set of functions that are imposed on the first set of functions and that are associated with a second application behavior; in response to the receipt of the request, forcing the secure application to override the first application behavior with the second application behavior, the second application behavior taking priority over the first application behavior; performing the second application behavior; and selectively permitting the secure application to engage in the first application behavior.

1. Material & Component Substitution: Hardware-Enforced Policy Engine with Secure Boot

• Enabling Description: The "processing unit" that forces the override and selectively permits behaviors is integrated with a secure boot and a hardware-enforced policy engine (e.g., a dedicated security co-processor or ARM TrustZone). When the "secure application" receives an activation request, the secure boot process ensures the integrity of the second set of functions/behaviors (the imposed security policies). The hardware policy engine then intercepts calls to the "first application behavior" (original functionality). It uses hardware-level access controls and memory protection to ensure the "second application behavior" always takes priority. "Predetermined criteria" for permitting the first behavior are verified by the hardware policy engine against immutable configuration stored in secure flash, providing tamper-proof policy enforcement.

  flowchart TD
      A[Activation Request] --> B(Secure Boot Process);
      B -- Verified Integrity --> C[Secure App (First & Second Behaviors)];
      C --> D[Hardware Policy Engine (Security Co-processor)];
      D -- Intercept Calls to First Behavior --> E{Evaluate Predetermined Criteria (Hardware)};
      E -- Criteria Met --> F[Selectively Permit First Behavior];
      F --> G[Execute First Behavior];
      E -- Criteria Not Met --> H[Force Second Behavior Override];
      H --> I[Execute Second Behavior (e.g., Encrypt/Log)];
      I --> J[Return to Secure App];
  

2. Operational Parameter Expansion: Ultra-Scalable, Multi-Tenant Policy Orchestration

• Enabling Description: The "system" operates as a geographically distributed, hyper-scale grid for parallel securitization of millions of target applications. The "activation request" for a secure application is received by a scalable, distributed policy orchestration system. The "predetermined criteria" for selectively permitting original behavior are evaluated across a global policy grid, considering factors like tenant-specific SLAs, geographic location of data centers, and real-time load balancing. The "forcing override" and "selectively permitting" logic for the secure application is dynamically provisioned and updated over a high-bandwidth, low-latency network. This enables immediate policy changes to cascade across entire fleets of devices, adapting behavior in real-time to evolving threats or compliance requirements across vast scales.

  graph TD
      A[User/System] --> B(Activation Request);
      B --> C[Policy Orchestration System (Global)];
      C -- Tenant Policies + Context --> D[Distributed Policy Engine];
      D --> E[Secure Application Instance (on device)];
      E -- Evaluate Criteria --> F{Permit First Behavior?};
      F -- Yes --> G[Execute Original Behavior];
      F -- No --> H[Execute Second Behavior (Override)];
      H --> I[Policy Enforcement Feedback];
      I --> C;
  

3. Cross-Domain Application: Autonomous Driving System Update Management

• Enabling Description: A "secure application" is a firmware update module in an autonomous vehicle. The "first application behavior" is to perform standard, non-critical updates (e.g., infotainment features), while the "second application behavior" is to enforce critical safety updates (e.g., braking system patches, lidar calibration updates). Upon an "activation request" (e.g., vehicle startup, network connection), the system forces the override of any pending non-critical updates with critical safety updates. The "predetermined criteria" for allowing the first behavior (non-critical updates) might be "vehicle stationary," "non-emergency mode," and "adequate battery power." If these criteria are not met, only the safety-critical "second behavior" is permitted, prioritizing immediate safety over other updates.

  sequenceDiagram
      VehicleECU->>+FirmwareUpdateModule: Activation Request
      FirmwareUpdateModule->>+PolicyEngine: Check Update Priority
      PolicyEngine->>FirmwareUpdateModule: Force Override (Safety Critical First)
      FirmwareUpdateModule->>+UpdateAgent: Execute Safety Update (Second Behavior)
      UpdateAgent->>VehicleSystems: Apply Patch
      UpdateAgent-->>-FirmwareUpdateModule: Safety Update Complete
      FirmwareUpdateModule->>+PolicyEngine: Check Criteria for Non-Critical Updates
      PolicyEngine->>PolicyEngine: Evaluate (Stationary, Non-Emergency, Battery)
      alt Criteria Met
          PolicyEngine-->>-FirmwareUpdateModule: Permit Non-Critical Update
          FirmwareUpdateModule->>+UpdateAgent: Execute Non-Critical Update (First Behavior)
          UpdateAgent->>Infotainment/Other: Apply Patch
      else Criteria Not Met
          PolicyEngine-->>-FirmwareUpdateModule: Deny Non-Critical Update
      end
  

4. Cross-Domain Application: Smart Manufacturing Robot Task Prioritization

• Enabling Description: A "secure application" controls a robotic arm in a smart factory. The "first application behavior" is to perform its scheduled manufacturing task (e.g., assembly, welding), while the "second application behavior" is to execute an emergency safety shutdown or a critical quality control routine. Upon "activation request" for a task, the system forces an override: if a safety sensor (e.g., human presence in exclusion zone) or a critical quality defect (detected by vision system) triggers the "second behavior," the scheduled manufacturing task (first behavior) is immediately suspended. The "predetermined criteria" for selectively permitting the first behavior might be "no safety alarms" and "quality checks passed." This ensures that safety and quality always take precedence over production targets.

  graph TD
      A[Robot Task Activation] --> B(Secure Robot Controller);
      B -- Request Task Execution --> C[Policy Engine];
      C -- Safety/Quality Override --> D[Force Second Behavior (Emergency Stop/QC)];
      D --> E[Execute Safety/QC Protocol];
      E --> F[Robot State: Safe/Inspected];
      C -- No Override --> G{Predetermined Criteria Met (No Alarms/Good Quality)?};
      G -- Yes --> H[Permit First Behavior (Scheduled Task)];
      H --> I[Execute Manufacturing Task];
      G -- No --> J[Block First Behavior (Hold/Wait)];
  

5. Cross-Domain Application: Government Classified Document Access

• Enabling Description: A "secure application" manages access to classified documents on a government workstation. The "first application behavior" allows standard document viewing and editing, while the "second application behavior" enforces strict "need-to-know" principles and auditing. Upon an "activation request" (e.g., opening a document), the system forces the override of normal access. The "second behavior" might involve mandating a re-authentication via a biometric scanner and creating an immutable, cryptographically signed audit trail entry for the access. The "predetermined criteria" for "selectively permitting" the first behavior (e.g., full editing rights) could be "Top Secret clearance verified," "project access granted," and "physical workstation secured." If criteria are not met, access is limited to read-only, watermarked viewing.

  sequenceDiagram
      User->>+SecureDocApp: Request Open Classified Doc
      SecureDocApp->>+PolicyEngine: Activation Request (Doc ID, User ID)
      PolicyEngine->>PolicyEngine: Force Override (Audit, Biometric Auth)
      PolicyEngine->>+BiometricScanner: Request Biometric Auth
      BiometricScanner-->>PolicyEngine: Authentication Result
      PolicyEngine->>+AuditService: Create Immutable Audit Log (Second Behavior)
      AuditService-->>-PolicyEngine: Log Acknowledged
      PolicyEngine->>PolicyEngine: Evaluate Predetermined Criteria (Clearance, Project Access, Workstation Secure)
      alt Criteria Met
          PolicyEngine-->>-SecureDocApp: Permit Full View/Edit (First Behavior)
          SecureDocApp->>DocumentStorage: Load Document
      else Criteria Not Met
          PolicyEngine-->>-SecureDocApp: Permit Read-Only/Watermarked View
          SecureDocApp->>DocumentStorage: Load Encrypted/Watermarked Doc
      end
  

6. Integration with Emerging Tech: AI-Driven Risk-Adaptive Behavior Management

• Enabling Description: The "predetermined criteria" for selectively permitting the "first application behavior" are dynamically adjusted by an AI-driven risk assessment engine. This engine continuously monitors user behavior, system telemetry, and external threat intelligence. When an "activation request" is received for a "secure application," the AI calculates a real-time risk score. If the risk score is high, the "second application behavior" (e.g., mandatory re-authentication, data encryption, restricted network access) is strictly enforced. If the risk score is low, the "first application behavior" (normal functionality) is permitted with fewer restrictions. The AI dynamically fine-tunes the balance between security and usability based on perceived risk.

  flowchart TD
      A[Activation Request] --> B(AI Risk Assessment Engine);
      B -- User Behavior, System Telemetry, Threat Intel --> C[Calculate Real-time Risk Score];
      C --> D{Risk Score High?};
      D -- Yes --> E[Force Second Behavior (High Security)];
      E --> F[Execute Strict Policies];
      D -- No --> G[Evaluate Predetermined Criteria (Lower Risk)];
      G -- Criteria Met --> H[Permit First Behavior (Normal Ops)];
      G -- Criteria Not Met --> E;
  

7. Integration with Emerging Tech: IoT Biometric Sensor-Enhanced Policy Enforcement

• Enabling Description: The "predetermined criteria" for selectively permitting the "first application behavior" are directly tied to biometric data from integrated IoT sensors. For example, a "secure application" might perform critical financial transactions. The "first application behavior" allows a quick, single-factor authentication. However, the "second application behavior" enforces multi-factor authentication (MFA) including fingerprint or facial recognition from an embedded biometric sensor. Upon "activation," the default is MFA. The "first behavior" (single-factor) is only permitted if the biometric sensor confirms a "trusted user presence" AND a "calm physiological state" (e.g., heart rate monitor), indicating low stress. If stress is high or identity uncertain, MFA is strictly enforced.

  stateDiagram-v2
      PromptMFA: Secure App Activation (Default MFA)
      BiometricAuth: User Provides Biometric Sample (IoT Sensor)
      PhysiologicalCheck: Heart Rate/Stress Analysis (IoT Sensor)
      TrustedUser: Biometrics Valid, Calm State
      SingleFactorAllowed: First Behavior Permitted
      MFA_Enforced: Second Behavior Enforced
  
      [*] --> PromptMFA
      PromptMFA --> BiometricAuth: User Attempts Access
      BiometricAuth --> PhysiologicalCheck: Biometric Match
      PhysiologicalCheck --> TrustedUser: Calm State Confirmed
      TrustedUser --> SingleFactorAllowed: Predetermined Criteria Met
      SingleFactorAllowed --> ExecuteTransaction: Perform Transaction (First Behavior)
  
      PhysiologicalCheck --> MFA_Enforced: Non-Calm State OR Biometric Mismatch
      MFA_Enforced --> PromptMFA: Re-attempt MFA
  

---

Derivatives for Claim 35 (System for generating a secure application)

• Claim 35: A system for generating a secure application, comprising: a disassembler that is configured to receive and decompose a target application into original files that contain predictable instructions; and a securitization agent that is configured to: identify one or more predictable instructions in the original files of the target application; modify the target application to create the secure application by binding one or more intercepts to the target application such that the behavior of the secure application is capable of being different from that of the target application, wherein the securitization agent is configured to modify the target application without access to the source code of the target application, and the bound intercepts are integrated with the original files; preserve operating system interactions that were originally defined for the target application and an operating system for which the target application was designed; and impose a secure and unpredictable namespace on the interprocess communications of the target application to prevent unauthorized access to the interprocess communications of the secure application.

1. Material & Component Substitution: Quantum-Resistant Cryptographic Securitization Agent

• Enabling Description: The "securitization agent" and associated components (disassembler, IPC namespace imposer) are upgraded to utilize quantum-resistant cryptographic primitives (e.g., lattice-based cryptography, hash-based signatures) for all integrity checks, code signing, and secure namespace generation. The "disassembler" operates within a post-quantum secure enclave, ensuring that the predictable instructions themselves are not tampered with during analysis. The "intercepts" injected by the securitization agent are themselves signed using quantum-resistant algorithms, and the "unpredictable namespace" for IPC is generated using a quantum-random number generator (QRNG) and further obfuscated with quantum-resistant encryption. This preemptively defends against future quantum computing attacks.

  flowchart TD
      A[Target Application] --> B(Post-Quantum Secure Enclave);
      B --> C[Disassembler (PQC-enabled)];
      C --> D{Predictable Instructions};
      D --> E[Securitization Agent (PQC-enabled)];
      E -- Bind PQC-Signed Intercepts --> F[Modified App];
      F -- Integrate PQC-Signed Intercepts --> G[Repackaged Secure Application];
      G -- PQC-Obfuscated Namespace (QRNG) --> H[Secure IPC Framework];
      H --> I[PQC-Protected OS Interaction];
  

2. Operational Parameter Expansion: Hyper-Scale Distributed Securitization Grid

• Enabling Description: The "system" operates as a geographically distributed, hyper-scale grid for parallel securitization of millions of target applications. The "disassembler" function is stateless and containerized, deployed across thousands of compute nodes. The "securitization agent" is implemented as a microservice architecture, allowing different policy sets and intercept injection strategies to be applied concurrently to vast numbers of applications. The "unpredictable namespace" generation is coordinated by a global synchronization service, ensuring uniqueness across the entire grid. This system can handle application loads from entire software ecosystems (e.g., all apps in a major app store) efficiently, applying security policies dynamically based on regional compliance or market demands.

  graph TD
      A[Target Application Stream (Millions)] --> B(Load Balancer);
      B --> C[Distributed Disassembler Pool (Containerized)];
      C --> D[Microservice-based Securitization Agent Pool];
      D -- Parallel Intercept Injection + Policy App --> E[Secure App Assembly Pipeline];
      E --> F[Global Namespace Registry];
      E --> G[Secure Application Repository (Distributed)];
      F -- Unique Namespace Gen/Sync --> D;
  

3. Cross-Domain Application: Spacecraft Flight Software Hardening System

• Enabling Description: The "system" is deployed at a spacecraft mission control center for hardening flight software. The "target application" is a compiled flight control module or an onboard diagnostic program. The "disassembler" is specifically designed for real-time operating systems (RTOS) used in space (e.g., VxWorks, FreeRTOS). The "securitization agent" identifies mission-critical instructions (e.g., thruster firing, antenna deployment) and binds intercepts to enforce radiation-hardened memory zones, fault-tolerant execution, and strict command validation. The "secure/unpredictable namespace" is imposed on inter-process communications between flight software components to prevent single-event upsets (SEUs) or malicious commands from cascading. The system integrates these intercepts without re-compiling the original flight-qualified source code.

  flowchart TD
      A[Flight Control Module (Target App)] --> B(Space-RTOS Disassembler);
      B --> C{Mission-Critical Instructions};
      C --> D[Securitization Agent (Aerospace-Hardened)];
      D -- Bind Radiation-Hardened Intercepts --> E[Modified Flight Software];
      E -- Integrate/Verify --> F[Flight Software Image];
      F -- Deploy to Spacecraft --> G[Onboard RTOS];
      G -- Secure IPC (Unpredictable Namespace) --> H[Other Flight Software Components];
  

4. Cross-Domain Application: Biomanufacturing Process Control System

• Enabling Description: The "system" is used in a biomanufacturing facility to secure process control software for bioreactors or purification systems. The "target application" is a compiled control algorithm for regulating temperature, pH, or nutrient flow. The "disassembler" handles proprietary industrial control language binaries. The "securitization agent" identifies critical control loop instructions and binds intercepts to enforce strict safety limits, prevent unauthorized parameter changes, and ensure immutable logging of all process deviations. The "secure/unpredictable namespace" is imposed on inter-module communications within the control system (e.g., between a sensor data acquisition module and an actuator control module) to prevent contamination or batch integrity breaches.

  sequenceDiagram
      ProcessControlApp->>+Disassembler: Decompose Control Algorithm
      Disassembler->>SecuritizationAgent: Predictable Instructions (Control Opcodes)
      SecuritizationAgent->>SecuritizationAgent: Identify Critical Instructions
      SecuritizationAgent->>+InterceptBinder: Bind Safety/Audit Intercepts
      InterceptBinder->>SecuritizationAgent: Modified App
      SecuritizationAgent->>Repackager: Repackage & Sign (Integrate Intercepts)
      Repackager->>SecureProcessControlApp: Secure Bioreactor Control App
      SecureProcessControlApp->>+IPC_Module: Secure/Unpredictable Namespace for IPC
      IPC_Module->>ActuatorControlModule: Secured Communication
  

5. Cross-Domain Application: Digital Twin Simulation Security

• Enabling Description: The "system" is used to create secure digital twin simulations for critical infrastructure (e.g., power plants, smart cities). The "target application" is a physics-based simulation engine or a data ingestion module for the digital twin. The "disassembler" extracts predictable computational instructions and data flow patterns. The "securitization agent" binds intercepts to ensure that simulation parameters are within safe operational envelopes, prevent injection of malicious fault scenarios, and control data exchange with real-world IoT sensors. The "secure/unpredictable namespace" is imposed on IPC between different simulation modules (e.g., structural integrity model, environmental impact model) to ensure data integrity and prevent cross-contamination of simulation results.

  graph LR
      A[Simulation Engine/Data Ingestion (Target)] --> B(Disassembler);
      B --> C{Computational/Data Flow Instructions};
      C --> D[Securitization Agent (Digital Twin Specific)];
      D -- Bind Simulation Policy Intercepts --> E[Secured Digital Twin Module];
      E -- Integrate Intercepts --> F[Secure Digital Twin Platform];
      F -- Secure IPC (Obfuscated Namespace) --> G[Other Secure Simulation Modules];
      F -- Preserve OS Interactions --> H[Underlying OS];
  

6. Integration with Emerging Tech: AI-Automated Securitization Pipeline

• Enabling Description: The "securitization agent" is largely autonomous, leveraging AI for all stages. An AI agent (e.g., a Reinforcement Learning agent) is responsible for identifying "predictable instructions" by learning from vast datasets of application binaries and known vulnerabilities. It then automatically determines the optimal "intercepts" to bind, generating custom security policies and even writing the intercept code. The AI also orchestrates the "repackaging" and the generation of the "secure and unpredictable namespace," dynamically adapting the obfuscation based on real-time threat intelligence. This allows for continuous, high-speed securitization of evolving applications without human intervention, identifying and patching vulnerabilities much faster than manual processes.

  flowchart TD
      A[Target App Queue] --> B(AI-Powered Disassembler);
      B --> C[AI Instruction Identifier];
      C --> D[AI Intercept Generator (Policy Learning)];
      D -- Custom Intercepts & Policies --> E[AI Binder/Integrator];
      E --> F[AI Namespace Generator (Dynamic Obfuscation)];
      F --> G[AI Repackager/Signer];
      G --> H[Secure Application Repository];
      I[Real-time Threat Intel] --> D;
  

7. Integration with Emerging Tech: IoT Hardware-Assisted Policy Attestation

• Enabling Description: The "system" integrates IoT-enabled hardware components to attest the integrity of the securitized application and its policy enforcement. The "securitization agent" not only modifies the target application but also embeds cryptographic "attestation agents" within it. These agents, at runtime, periodically communicate with a trusted IoT gateway or a secure hardware module (e.g., TPM/TEE) on the computing device. This communication includes cryptographic proofs (e.g., hash of current application state, active policy rules, logs of intercepted calls). The IoT gateway verifies these proofs against expected values. If a discrepancy is found (indicating tampering with intercepts or policies), the system can trigger a lockdown, alert, or remote wipe.

  sequenceDiagram
      TargetApp->>+SecuritizationAgent: Submit
      SecuritizationAgent->>SecureApp: Generate (Intercepts + Attestation Agent)
      SecureApp->>+IoT_Gateway: Periodic Attestation Request
      IoT_Gateway->>SecureHardwareModule: Verify Proof (Hash of App State, Policies, Logs)
      SecureHardwareModule-->>IoT_Gateway: Attestation Result (Pass/Fail)
      alt Attestation Failed
          IoT_Gateway->>SecureApp: Trigger Lockdown/Alert
      else Attestation Passed
          IoT_Gateway->>SecureApp: Continue Normal Operation
      end
  

---

Combination Prior Art Scenarios (Open-Source Standards)

1. US9135418 + Android Open Source Project (AOSP) Application Sandbox:

   • Description: The concepts of US9135418 regarding securitizing applications (Claims 1, 12, 18, 35) by injecting intercepts and imposing secure namespaces for IPC can be combined with the existing Android application sandbox model. AOSP natively isolates apps using Linux user IDs and process separation. However, applications within the same user ID or sharing certain permissions can still communicate. By integrating the securitization agent into the AOSP build toolchain, all applications could have enhanced intercepts (e.g., dynamic bytecode injection for Dalvik/ART bytecode, or native library hooking for NDK apps) and fine-grained, cryptographically obfuscated namespaces applied at compile/install time. This would elevate the default security posture of all Android applications, making lateral movement between apps in the same security context significantly harder. The intercepts could, for example, enforce policies on permission usage at runtime or restrict data access based on enterprise policies, even for seemingly benign applications.
   • Open-Source Standard: Android Open Source Project (AOSP) and its application sandbox architecture.

2. US9135418 + eBPF (extended Berkeley Packet Filter) for Kernel-Level Interception:

   • Description: The methods of US9135418 for identifying "predictable instructions" and binding "intercepts" (Claims 1, 12, 18, 35) can be significantly enhanced by utilizing eBPF, an open-source Linux kernel technology. Instead of modifying application binaries directly at the user space or library level, eBPF programs can be injected into the kernel to intercept system calls, network events, and other kernel functions on behalf of the secure application. The securitization agent would analyze the target application, identify critical system calls (e.g., open, read, write, sendmsg, recvmsg), and generate eBPF programs that act as dynamic intercepts. These eBPF programs would then enforce policies (e.g., encrypting specific file writes, filtering network traffic based on policy, obfuscating IPC socket names) at the kernel boundary, providing a highly performant, flexible, and tamper-resistant interception layer without altering the application's bytecode or native code directly. The "secure and unpredictable namespace" (Claim 1) for IPC could be managed by eBPF programs dynamically re-mapping socket names.
   • Open-Source Standard: eBPF (extended Berkeley Packet Filter) within the Linux kernel.

3. US9135418 + Open Container Initiative (OCI) Runtime Specification for Container Security:

   • Description: The system and methods of US9135418 (Claims 1, 12, 18, 35) can be applied to secure containerized applications. A "target application" would be the application binary and its dependencies packaged within a container image (e.g., Docker, runc). The "disassembler" and "securitization agent" could operate on the application within the container image before runtime. Intercepts would be injected into the containerized application's binaries or runtime environment to enforce granular policies (e.g., mandatory encryption for data written to container volumes, restricted network egress rules for specific ports, or limiting system calls available to the application). The "secure and unpredictable namespace" for IPC could be applied to inter-container communication, ensuring that only securitized containers adhering to specific naming conventions and policies can communicate, even if running on the same host and sharing a network namespace. This provides an additional layer of security beyond standard container isolation mechanisms.
   • Open-Source Standard: Open Container Initiative (OCI) Runtime Specification and image format.