Program Execution Anomaly Detection Using Acceptable Behavior Models

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional security approaches fail to detect unanticipated or malicious software behavior in real-time, often relying on after-the-fact analysis or requiring knowledge of potential vulnerabilities, and lack precision in identifying deviations from normal program behavior.

Innovation Solution

A system that generates an acceptable behavior model by monitoring a program in a controlled environment, comparing it with operational sequences, and halting or flagging deviations from expected behavior to prevent unanticipated or malicious actions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional security approaches monitor for big picture anomalies such as unusual network traffic, CPU usage, memory access, file usage, and data usage, then security breaches can be detected after they happen, but the detection is too late to prevent the security breach or other erroneous or unanticipated operation from happening

Engineering Contradiction:
Improvesecurity breach detectionVSAvoidresponse time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary action by establishing an acceptable behavior model through supervised learning during a training phase before actual security monitoring begins. The model learns what normal program behavior looks like across multiple dimensions (CPU usage, memory access patterns, file operations, network traffic, registry modifications) so that during runtime, it can immediately compare actual behavior against this pre-established baseline and detect anomalies in real-time, preventing security breaches before they complete rather than detecting them after the fact

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If other conventional approaches provide tools that can be used during software development to analyze the code and identify weaknesses that could potentially be exploited by a malicious actor, then potential vulnerabilities can be identified, but these approaches cannot detect other behavior that is unanticipated, unintended, or potentially a security breach

Engineering Contradiction:
Improvevulnerability identification precisionVSAvoiddetection coverage
Core Design Contradiction:
Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The system applies dynamics by using machine learning models that continuously adapt and learn from observed program behavior rather than relying on static, pre-defined vulnerability signatures. The acceptable behavior model is dynamically updated as the system monitors program execution across different conditions and inputs, allowing it to detect previously unanticipated security breaches and malicious behaviors that deviate from normal patterns, providing both precision in identifying actual anomalies and versatility in covering unknown threat types

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system implements feedback by continuously comparing actual program behavior against the acceptable behavior model and using the results to refine security detection. When anomalies are detected, the system can flag them for analysis and potentially update the model to account for legitimate new behaviors, creating a closed-loop system that improves its detection precision while maintaining adaptability to new threat types and program variations

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20260037632A1Program Execution Anomaly Detection for CyberSecurity
Publication Date: 2026.02.05 PRAEDICTIO AI INC
  • US20260037632A1 patent drawing
  • US20260037632A1 patent drawing
  • US20260037632A1 patent drawing

AI summary

Different versions of a program are executed in a first mode of operation in accordance with normal operations with only expected behavior to generate different acceptable behavior models indicative of behavior of the program. A difference between acceptable behavior models indicates different risk profiles for the different versions of the program. Risk profiles can be generated by a model explainer. An event that attempts to execute remote code or a delayed event can be detected in a second mode of operation if the event or the delayed event is not included in the acceptable behavior model. Different sequences of events in the first or second mode can be instrumented at different levels of instrumentation to generate or use the acceptable behavior model. The sequences of events can be generated from a stacktrace in the first and second modes. The instrumentation can be performed in hardware by intercepting SYSCALLs.