Persistent Servicing Agent Firmware Persistence

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional asset management solutions fail to accurately track and manage remote and mobile computer assets, leading to security threats and regulatory compliance issues due to lack of persistence against tampering and changes in asset configurations.

Innovation Solution

A persistent servicing agent with modular design, capable of residing in firmware or hardware, that loads itself across various operating environments, adapts to system changes, and remains active despite user actions such as reinstallation or hard drive format, ensuring continuous asset tracking and management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional asset management software is installed on computer assets, then basic tracking functionality is provided, but the solution fails to persist across system changes such as reinstallation, hard drive format, or hardware replacement

Engineering Contradiction:
Improvepersistence of tracking agentVSAvoidimplementation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The tracking solution is divided into two segments: a persistent firmware-resident tracking agent that survives system changes, and a separate operating system software component that can be reinstalled. The firmware segment contains the core persistence functionality, while the OS software handles asset management tasks, allowing each to be optimized independently.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A communication interface layer is introduced between the firmware-resident tracking agent and the operating system software. This intermediary enables the firmware agent to persist across system changes while maintaining full bidirectional communication with the OS software for asset management operations, resolving the contradiction between persistence and functionality.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the tracking agent is made persistent across system changes, then asset tracking reliability is improved, but the ease of operation and user control is reduced

Engineering Contradiction:
Improvecontinuity of asset trackingVSAvoiduser control over agent removal
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

Different removal characteristics are applied to different components of the tracking system. The firmware-resident tracking agent is designed to be resistant to removal through standard user actions (formatting, reinstallation), while the operating system software component remains fully removable and controllable by the user. This local differentiation resolves the contradiction between persistence and user control.

Inventive Principle:
Principle #3Local quality

3Reliability

If the tracking agent resides in firmware, then persistence against tampering is achieved, but the adaptability to different operating environments is reduced

Engineering Contradiction:
Improvetamper resistanceVSAvoidcompatibility with operating systems
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

A communication interface layer is introduced between the firmware-resident tracking agent and the operating system software. This intermediary enables the firmware agent to persist across system changes while maintaining full bidirectional communication with the OS software for asset management operations, resolving the contradiction between persistence and functionality.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The firmware-resident tracking agent is designed with universal communication capabilities that work across multiple operating system environments. By implementing standardized communication protocols and interfaces, the firmware agent can adapt to different OS environments without sacrificing its persistence or requiring OS-specific firmware implementations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Reliability

If complete asset tracking functionality is implemented in firmware, then persistence is maximized, but the firmware size and complexity increases

Engineering Contradiction:
Improvepersistence of tracking agentVSAvoidfirmware size
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The tracking solution is divided into two segments: a persistent firmware-resident tracking agent that survives system changes, and a separate operating system software component that can be reinstalled. The firmware segment contains the core persistence functionality, while the OS software handles asset management tasks, allowing each to be optimized independently.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Non-essential tracking functionality and asset management software are extracted from the firmware and placed in the operating system environment. Only the critical persistence and communication core remains in firmware, minimizing firmware size while maintaining persistence. The extracted OS software provides complete tracking functionality when needed.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS8418226B2Persistent servicing agent
Publication Date: 2013.04.09 ABSOLUTE SOFTWARE CORPORATION
  • US8418226B2 patent drawing
  • US8418226B2 patent drawing
  • US8418226B2 patent drawing

AI summary

A tamper resistant servicing Agent for providing various services (e.g., data delete, firewall protection, data encryption, location tracking, message notification, and updating software) comprises multiple functional modules, including a loader module (CLM) that loads and gains control during POST, independent of the OS, an Adaptive Installer Module (AIM), and a Communications Driver Agent (CDA). Once control is handed to the CLM, it loads the AIM, which in turn locates, validates, decompresses and adapts the CDA for the detected OS environment. The CDA exists in two forms, a mini CDA that determines whether a full or current CDA is located somewhere on the device, and if not, to load the full-function CDA from a network; and a full-function CDA that is responsible for all communications between the device and the monitoring server. The servicing functions can be controlled by a remote server.