Patent 8510543

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure for US Patent 8510543: Firmware Supporting Multiple Boot Paths

Current Date: April 26, 2026

This document details derivative works and extensions of the technologies described in US Patent 8510543, "Firmware Supporting Multiple Boot Paths." The aim is to defensively publish these concepts, rendering future incremental improvements by competitors obvious or non-novel to a Person Having Ordinary Skill in the Art (PHOSITA). This disclosure focuses on extending the core inventive concept of a BIOS firmware dynamically adjusting its initialization process based on a selected operating system's specific requirements, leveraging a boot path indicator and configuration information.

Derivative Variations and Technical Disclosures

1. Material & Component Substitution

Derivative 1.1: MRAM/PRAM for Dynamic Configuration Storage

Enabling Description:
The core mechanism of storing boot path configuration information (configuration table 150) is enhanced by substituting traditional non-volatile random-access memory (NVRAM) or flash memory with Magnetoresistive Random-Access Memory (MRAM) or Phase-Change Memory (PRAM). These emerging non-volatile memory technologies offer significantly faster write speeds, higher endurance, and lower power consumption compared to NAND flash, enabling rapid updates to boot path configurations, dynamic re-prioritization of boot paths, and more frequent logging of boot events or failures without performance degradation. A dedicated MRAM/PRAM module, integrated via an SPI or I2C bus with the South Bridge (426) or directly with the CPU (422) through a dedicated memory controller, would store the boot path indicator (130) and configuration tables (150). The BIOS firmware (110) would be modified to utilize specific read/write drivers optimized for MRAM/PRAM access, allowing for near-instantaneous retrieval and modification of boot path parameters. This enables scenarios such as real-time boot path adjustments based on external stimuli or rapid switching between diagnostic configurations.

classDiagram
    class CPU_422 {
        +executeFirmware()
        +MRAM_PRAM_Controller
    }
    class SouthBridge_426 {
        +SPI_I2C_Interface
    }
    class BIOS_Firmware_110 {
        +bootPathSelector_115()
        +MRAM_PRAM_Driver
        +retrieveConfigInfo()
        +generateConfiguration()
        +performConfiguration()
        +launchOS()
    }
    class MRAM_PRAM_Module {
        +storeBootPathIndicator(130)
        +storeConfigTables(150)
        +readData()
        +writeData()
    }
    class Components_112 {
        +initComponent()
    }
    class OperatingSystem_160 {
        +boot()
    }

    CPU_422 -- BIOS_Firmware_110 : executes
    CPU_422 -- MRAM_PRAM_Module : via controller
    SouthBridge_426 -- MRAM_PRAM_Module : via interface
    BIOS_Firmware_110 --> MRAM_PRAM_Module : reads/writes config
    BIOS_Firmware_110 --> Components_112 : initializes
    BIOS_Firmware_110 --> OperatingSystem_160 : launches
    MRAM_PRAM_Module -- Configuration_Data : stores

Derivative 1.2: FPGA-based Reconfigurable Firmware Modules

Enabling Description:
Instead of merely including or excluding pre-compiled firmware modules (112), this derivative proposes dynamically instantiating or reconfiguring firmware logic using Field-Programmable Gate Arrays (FPGAs). A portion of the BIOS firmware's functionality, particularly for device initialization routines (e.g., specific peripheral controllers, complex sensor interfaces), would be implemented as reconfigurable logic blocks within an FPGA co-processor integrated onto the motherboard. The configuration information (150) associated with a selected boot path would now include not only flags for inclusion/exclusion but also bitstream files or configuration parameters (e.g., register settings for a soft-core processor, I/O pin assignments, clock frequencies) that are loaded onto the FPGA during the "generating a configuration" (330) phase. This allows for highly flexible and optimized hardware-level initialization, tailoring the exact digital logic of components to the needs of the operating system. For example, a "fast-boot" path might load a simplified FPGA configuration for a USB controller, while a "full-diagnostic" path loads a comprehensive one with additional debug hooks. This provides a finer granularity of hardware initialization control, reducing power consumption and silicon footprint by only enabling the necessary logic.

flowchart TD
    A[Receive Boot Path Indicator 130] --> B{Boot Path Selector 115};
    B --> C{Retrieve Configuration Information 150};
    C -- includes FPGA bitstreams/parameters --> D[Generate Configuration 120];
    D -- if FPGA-enabled component --> E[Load FPGA Bitstream/Config];
    E --> F[Perform Firmware Configuration 120];
    F -- dynamically instantiated/reconfigured --> G[Initialize FPGA-based Component Logic 112];
    G --> H[Launch Operating System 160];

    subgraph BIOS Firmware 110
        B --- C --- D --- E --- F
    end
    subgraph FPGA Co-processor
        E --- G
    end

2. Operational Parameter Expansion

Derivative 2.1: Nanoscale Embedded System Boot Paths

Enabling Description:
Applying the multiple boot path concept to nanoscale embedded systems, such as those found in smart sensors or bio-implants. The "computer" (100) here is a System-on-Chip (SoC) operating at sub-millimeter scales. The boot path indicator (130) could be triggered by ambient conditions (e.g., temperature, light), remaining battery power, or external wireless signals. Boot paths (117) would correspond to modes like "ultra-low power sleep," "sensor data acquisition," or "active processing." The "configuration information" (150) would precisely define which nanometer-scale circuitry blocks, memory regions, and power gates are activated, and at what clock frequencies. For example, a "sleep" boot path might only initialize a timer and a minimal communication module, operating at pJ/cycle, while a "data acquisition" path activates specific analog-to-digital converters and on-chip memory buffers, carefully managing leakage currents to extend operational life in power-constrained environments. The initialization of firmware modules (112) would involve activating specific IP cores and setting their power states and clock domains.

stateDiagram
    [*] --> Off
    Off --> Awaiting_Indicator : Power_On

    state Awaiting_Indicator {
        Awaiting_Indicator --> Low_Power_Boot : LowPowerSignal
        Awaiting_Indicator --> Data_Acq_Boot : SensorEvent
        Awaiting_Indicator --> Active_Proc_Boot : ExternalCommand
    }

    state Low_Power_Boot {
        Low_Power_Boot --> Initialize_Minimal_Circuitry : Entry
        Initialize_Minimal_Circuitry --> Set_Low_Frequency_Clocks
        Set_Low_Frequency_Clocks --> Enter_Low_Power_OS : OS_Launch
    }

    state Data_Acq_Boot {
        Data_Acq_Boot --> Initialize_Sensor_ADCs : Entry
        Initialize_Sensor_ADCs --> Configure_Memory_Buffers
        Configure_Memory_Buffers --> Launch_Sensor_OS : OS_Launch
    }

    state Active_Proc_Boot {
        Active_Proc_Boot --> Initialize_All_Cores : Entry
        Initialize_All_Cores --> Full_Peripherals_Init
        Full_Peripherals_Init --> Launch_Full_OS : OS_Launch
    }

    Low_Power_Boot --> [*]
    Data_Acq_Boot --> [*]
    Active_Proc_Boot --> [*]

Derivative 2.2: High-Frequency Trading (HFT) Server Boot Path Optimization

Enabling Description:
In a high-frequency trading environment, every nanosecond of boot time and operational latency is critical. This derivative utilizes multiple boot paths for HFT servers, focusing on picosecond-level latency reduction during system initialization. The boot path indicator (130) could be selected based on the specific trading strategy to be deployed (ee.g., ultra-low latency market-making, arbitrage, or data analysis). Configuration information (150) for ultra-low latency boot paths would specify the exclusion of virtually all non-essential firmware modules (112) such as USB device initialization (432), SATA drive (438) enumeration beyond the boot drive, sound adapter (446), and even complex network adapter (428) features not directly required for the trading application. The BIOS firmware (110) would be optimized to perform only the absolute minimal CPU (422) and memory (454) initialization, directly setting up the network interface card (NIC) for kernel bypass (e.g., using technologies like Solarflare's OpenOnload or Mellanox's VMA) and loading a stripped-down, real-time operating system (RTOS) or a custom bare-metal application. This boot path would actively avoid any microcode updates, firmware patches, or diagnostic checks that introduce even minute delays, ensuring the fastest possible time-to-trading-state.

flowchart TD
    A[Start Server Boot] --> B{Boot Path Indicator 130 Received (e.g., HFT-LowLatency)};
    B --> C[BIOS Firmware 110];
    C -- Retrieve Configuration (HFT-LL) --> D{Configuration Table 150 (HFT-LL)};
    D -- Specify Exclusions --> E[Exclude: USB, SATA, Sound, Non-Critical NIC Features];
    D -- Specify Inclusions --> F[Include: CPU Core Init, Minimal Memory, Direct NIC Setup];
    E & F --> G[Generate Firmware Configuration 120 (HFT-LL)];
    G --> H[Perform Configuration (Fast Path)];
    H -- Minimal Initialization --> I[Bypass Standard POST/Device Enumeration];
    H -- Direct Hardware Setup --> J[Configure NIC for Kernel Bypass];
    J --> K[Launch RTOS/Bare-Metal App 160];
    K --> L[Trading Application Live (Minimal Latency)];

3. Cross-Domain Application

Derivative 3.1: Automotive Electronic Control Unit (ECU) Boot Paths

Enabling Description:
The multiple boot path system is integrated into an Automotive Electronic Control Unit (ECU), a critical component in vehicles. The boot path indicator (130) could be derived from vehicle state, a diagnostic tool input, or a telematics command. For instance, boot paths (117) could include:

  1. "Normal Operation": Initializes all engine, transmission, braking, and infotainment sub-systems.
  2. "Diagnostic Mode": Initializes only minimal vehicle controls and diagnostic ports (e.g., OBD-II interface, CAN bus monitoring modules), suppressing non-essential features and potentially providing a stripped-down OS for technicians.
  3. "Valet Mode": Limits engine power, restricts speed, and disables certain advanced driver-assistance systems (ADAS) or connected features by initializing a specific subset of powertrain and safety modules with restricted parameters.
  4. "Autonomous Driving Mode": Prioritizes initialization of LiDAR, radar, camera sensors, and high-performance computing (HPC) modules for perception and path planning, ensuring these critical components are online and fully calibrated before other non-safety-critical systems.
    The BIOS-like firmware (often a Boot ROM or Secure Bootloader) would retrieve configuration information (150) specific to these modes, initializing only the necessary sensors, actuators, communication buses (CAN, LIN, FlexRay, Automotive Ethernet), and computational cores (112) as required for the chosen operational state. This ensures tailored performance, resource allocation, and security for diverse automotive use cases.
stateDiagram-v2
    direction LR
    [*] --> Power_On

    state Power_On {
        Power_On --> Boot_Indicator_Reception
        Boot_Indicator_Reception --> Validate_Indicator : Indicator_Received
    }

    state Boot_Path_Selection {
        Validate_Indicator --> Normal_Operation_Path : "Normal"
        Validate_Indicator --> Diagnostic_Mode_Path : "Diagnostic"
        Validate_Indicator --> Valet_Mode_Path : "Valet"
        Validate_Indicator --> Autonomous_Mode_Path : "Autonomous"
    }

    state Normal_Operation_Path {
        Normal_Operation_Path : Init Engine, Trans, Brake, Infotainment
    }
    state Diagnostic_Mode_Path {
        Diagnostic_Mode_Path : Init OBD-II, CAN Bus, Minimal Controls
    }
    state Valet_Mode_Path {
        Valet_Mode_Path : Limit Power/Speed, Disable ADAS
    }
    state Autonomous_Mode_Path {
        Autonomous_Mode_Path : Prioritize LiDAR, Radar, Cameras, HPC
    }

    Normal_Operation_Path --> OS_Launch_Normal : Config_Done
    Diagnostic_Mode_Path --> OS_Launch_Diagnostic : Config_Done
    Valet_Mode_Path --> OS_Launch_Valet : Config_Done
    Autonomous_Mode_Path --> OS_Launch_Autonomous : Config_Done

    OS_Launch_Normal --> Running_Normal
    OS_Launch_Diagnostic --> Running_Diagnostic
    OS_Launch_Valet --> Running_Valet
    OS_Launch_Autonomous --> Running_Autonomous

    Running_Normal --> [*]
    Running_Diagnostic --> [*]
    Running_Valet --> [*]
    Running_Autonomous --> [*]

Derivative 3.2: Smart Home Hub with Adaptive Boot Paths

Enabling Description:
Applying the multi-boot path concept to a smart home hub. The boot path indicator (130) for the hub's firmware (e.g., UEFI or custom bootloader) could be triggered by:

  1. Time of day/Week: e.g., "Night Mode" or "Weekend Mode."
  2. Occupancy status: Detected by motion sensors or integrated user presence data.
  3. User selection: Via a mobile app or local control panel.
    Boot paths (117) would correspond to different operational profiles. For example:
  • "Energy Saving Mode": Initializes only essential network connectivity (e.g., Wi-Fi, Zigbee for critical devices), core processing, and a minimal set of environmental sensors (e.g., temperature). It might disable Bluetooth, Z-Wave, and other high-bandwidth or less critical radios and services to conserve power.
  • "Full Functionality Mode": Initializes all radios, sensor arrays, voice assistants, and local processing capabilities, preparing for full user interaction and automation.
  • "Guest Mode": Initializes a limited subset of smart devices and features, excluding personal data access or high-security functions, to provide basic smart home services for visitors.
    The firmware would retrieve configuration information (150) that dictates which communication modules, local processing units, power management ICs, and sensor interfaces (112) are initialized, enabling a dynamic and resource-optimized response to various home scenarios.
sequenceDiagram
    participant User/SystemEvent
    participant SmartHomeHub
    participant Bootloader
    participant Firmware_Modules
    participant OS

    User/SystemEvent->>Bootloader: Provide Boot Path Indicator (e.g., "EnergySave")
    Bootloader->>Bootloader: Receive Boot Path Indicator 130
    Bootloader->>Firmware_Modules: Retrieve Config Table 150 (EnergySave)
    Firmware_Modules-->>Bootloader: Configuration Data (e.g., Enable WiFi, Temp Sensor; Disable Bluetooth, Z-Wave)
    Bootloader->>Bootloader: Generate Configuration 120
    Bootloader->>Firmware_Modules: Perform Configuration (Init selected modules)
    Firmware_Modules->>Firmware_Modules: Initialize Network (WiFi), Temp Sensor
    Firmware_Modules->>Firmware_Modules: Skip Bluetooth, Z-Wave Initialization
    Bootloader->>OS: Launch EnergySave OS 160
    OS->>SmartHomeHub: Enter Energy Save Mode

Derivative 3.3: Agricultural Robotics Firmware Boot Paths

Enabling Description:
The multiple boot path system is applied to autonomous agricultural robots. The boot path indicator (130) could be selected based on the robot's scheduled task, environmental conditions (e.g., detected soil moisture, crop health), or remote operator command. Boot paths (117) could include:

  1. "Field Mapping Mode": Prioritizes initialization of GPS-RTK modules, LiDAR/camera-based mapping sensors, and short-range communication for data upload, while minimizing power to actuators.
  2. "Pest/Disease Detection Mode": Activates specific hyperspectral imaging sensors, AI inference engines for plant analysis, and precision spray nozzles (if applicable), while limiting navigation to survey patterns.
  3. "Harvest Mode": Fully initializes high-power drive motors, robotic arm controls, cutting/picking mechanisms, and heavy-duty communication for coordination, de-prioritizing detailed mapping sensors.
  4. "Maintenance/Diagnostic Mode": Initializes internal self-diagnostic sensors, logging mechanisms, and wireless interfaces for remote technician access, disabling all field operation capabilities.
    The robot's boot firmware would retrieve configuration information (150) corresponding to the selected mode, enabling only the necessary navigation, sensing, communication, and actuation modules (112), optimizing power consumption, and ensuring mission-specific readiness.
graph TD
    A[Robot Power On] --> B(Receive Boot Path Indicator 130);
    B -- "Field Mapping" --> C1[Init GPS-RTK, LiDAR, Cameras];
    B -- "Pest/Disease Detection" --> C2[Init Hyperspectral, AI Engine, Nozzles];
    B -- "Harvest" --> C3[Init Drive Motors, Arm Controls, Cutting Mech];
    B -- "Maintenance" --> C4[Init Self-Diagnostics, Logging, Remote Access];

    C1 --> D1{Generate Mapping Config};
    C2 --> D2{Generate Detection Config};
    C3 --> D3{Generate Harvest Config};
    C4 --> D4{Generate Maintenance Config};

    D1 --> E1[Perform Mapping Configuration];
    D2 --> E2[Perform Detection Configuration];
    D3 --> E3[Perform Harvest Configuration];
    D4 --> E4[Perform Maintenance Configuration];

    E1 --> F1[Launch Mapping OS 160];
    E2 --> F2[Launch Detection OS 160];
    E3 --> F3[Launch Harvest OS 160];
    E4 --> F4[Launch Maintenance OS 160];

    subgraph BIOS Firmware 110
        B --- C1, C2, C3, C4 --- D1, D2, D3, D4 --- E1, E2, E3, E4
    end

4. Integration with Emerging Technologies

Derivative 4.1: AI-Driven Adaptive Boot Path Optimization

Enabling Description:
The boot path selector (115) is augmented with an embedded Artificial Intelligence (AI) agent. This AI agent analyzes historical boot performance data, current hardware telemetry (e.g., temperature, fan speed, power draw from IoT sensors), predicted workload patterns, and available network resources to dynamically determine the optimal boot path (117) without explicit user input. For example, if the system consistently boots to a specific operating system (160) for a computationally intensive task, the AI agent might suggest or automatically select a "performance-optimized" boot path that prioritizes CPU (422) and memory (454) initialization, potentially de-initializing non-critical peripherals (112). If network latency is critical, it may activate a network-optimized boot path. The AI agent, a lightweight neural network or decision tree model, could run within a secure enclave of the BIOS firmware (110) or be integrated into a system management controller (BMC), receiving input from various system sensors and periodically updating its policy based on observed boot success and performance metrics, stored in NVRAM (448) or MRAM. The "boot path indicator" (130) becomes an internal AI-generated signal.

flowchart TD
    A[System Power On] --> B(Collect System Telemetry);
    B --> C{AI Agent in BIOS/BMC};
    C -- Analyze Workload/Health/Performance --> D(Predict Optimal Boot Path);
    D --> E[Generate AI-Driven Boot Path Indicator 130];
    E --> F[Boot Path Selector 115];
    F --> G[Retrieve Configuration Information 150];
    G --> H[Generate Firmware Configuration 120];
    H --> I[Perform Configuration];
    I --> J[Launch Operating System 160];

Derivative 4.2: IoT Sensor-Triggered Boot Path Selection

Enabling Description:
The boot path indicator (130) is dynamically determined by real-time data from a network of IoT sensors connected to the computer system (100) or its environment. This applies where the computer's role is adaptive to its surroundings. For example, in a data center, temperature sensors (IoT) near a server rack could trigger a "thermal-aware" boot path. If ambient temperature exceeds a threshold, the BIOS firmware (110) selects a boot path (117) that prioritizes fan controller initialization at higher RPMs and reduces clock speeds for certain components during POST, ensuring safe operation, or even selects a "minimum load" OS (160) to prevent thermal runaway. Other examples include:

  • Proximity sensors: If a service technician is detected nearby, trigger a "diagnostic boot path."
  • Power grid sensors: If grid stability is low, activate a "resilient boot path" with enhanced power management and fault tolerance checks.
  • Humidity sensors: In industrial settings, trigger a "hardened boot path" for sensitive electronics.
    The BIOS firmware (110) or an associated system management controller (BMC) would include a lightweight network stack to receive sensor data (e.g., via MQTT, CoAP) and interpret it to generate the boot path indicator (130), allowing the system to reactively configure itself for optimal operation in real-time environmental contexts.
sequenceDiagram
    participant IoT_Sensors
    participant Network_Gateway
    participant BMC/BIOS
    participant BIOS_Firmware
    participant OS

    IoT_Sensors->>Network_Gateway: Send Environmental Data (Temp, Humidity, etc.)
    Network_Gateway->>BMC/BIOS: Forward Sensor Data
    BMC/BIOS->>BMC/BIOS: Interpret Sensor Data
    BMC/BIOS->>BIOS_Firmware: Generate Boot Path Indicator 130 (e.g., "ThermalSafe")
    BIOS_Firmware->>BIOS_Firmware: Receive Boot Path Indicator 130
    BIOS_Firmware->>BIOS_Firmware: Retrieve Configuration Table 150 (ThermalSafe)
    BIOS_Firmware->>BIOS_Firmware: Generate Configuration 120
    BIOS_Firmware->>BIOS_Firmware: Perform Configuration (e.g., Init fans max, limit CPU clock)
    BIOS_Firmware->>OS: Launch Operating System 160
    OS->>OS: Operate under Thermal-Aware Profile

Derivative 4.3: Blockchain-Verified Secure Boot Paths

Enabling Description:
To enhance the security and integrity of the multiple boot path system, blockchain technology is integrated for verification. Each configuration table (150) and the boot path indicator (130) itself, along with checksums or cryptographic hashes of firmware modules (112) comprising a given boot path, are registered as transactions on a private, permissioned blockchain. When a boot path is selected (either by user input or automatically), the BIOS firmware (110) first retrieves the boot path indicator (130) and configuration information (150). Before executing, a secure hardware module (e.g., a Trusted Platform Module (TPM) 2.0 or a Hardware Security Module (HSM)) within the computer (100) queries the blockchain ledger (either locally cached or via a secure network interface) to verify the authenticity and integrity of the selected boot path's configuration data and associated firmware module hashes. This ensures that no unauthorized modifications have occurred to the boot path definitions or the firmware components they initialize. If the blockchain verification fails, the system could default to a "fail-safe" boot path (as in Derivative 5.1) or refuse to boot. This provides an immutable, auditable record of all boot path configurations and changes, crucial for high-security environments or critical infrastructure.

flowchart TD
    A[System Power On] --> B(Receive Boot Path Indicator 130);
    B --> C{BIOS Firmware 110};
    C -- Retrieve Config Table 150 --> D[Configuration Data];
    C -- Get Firmware Module Hashes --> E[Firmware Module Hashes];
    D & E --> F[TPM/HSM];
    F -- Query Blockchain Ledger --> G[Blockchain Ledger (Cached/Network)];
    G -- Verify Integrity/Authenticity --> H{Verification Result?};
    H -- NO --> I[Initiate Fail-Safe Boot/Halt];
    H -- YES --> J[Generate Firmware Configuration 120];
    J --> K[Perform Configuration];
    K --> L[Launch Operating System 160];

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Safe Diagnostic/Recovery Boot Path

Enabling Description:
A dedicated boot path (117) is engineered for "fail-safe" operation, invoked automatically upon detection of critical system failures (e.g., repeated OS crashes, hardware errors detected by POST, secure boot violations) or explicit user input. This "Fail-Safe Diagnostic/Recovery" boot path would prioritize system stability and data integrity over full functionality or speed. Its configuration information (150) would mandate:

  1. Minimal Component Initialization: Only essential components (112) for CPU, minimal memory, a basic display controller (VBIOS), and a specific, secure network interface for remote diagnostics or a single USB port for a recovery drive are initialized. All other peripherals, including complex storage controllers, high-speed network interfaces, and advanced graphics, are explicitly excluded.
  2. Verbose Logging: Activates all available diagnostic logging facilities within the BIOS firmware (110) and potentially to a non-volatile log region in NVRAM (448) or external storage.
  3. No OS Launch (Default): Instead of launching a full operating system (160), it defaults to a minimal, immutable BIOS-level diagnostic shell or a recovery environment bootloader (e.g., from a ROM-based recovery partition), designed to assess system health, reflash corrupted firmware, or initiate data recovery.
  4. Hardware Self-Test Emphasis: Runs extended hardware integrity checks on essential components.
    This ensures that even in a severely compromised state, the system can provide a reliable path for troubleshooting and recovery, preventing further damage or data loss.
stateDiagram-v2
    direction LR
    [*] --> Power_On
    Power_On --> Check_Boot_Indicator : System_Status_OK
    Power_On --> Fail_Safe_Triggered : Critical_Error_Detected
    Power_On --> Fail_Safe_Triggered : User_Invoked

    state Check_Boot_Indicator {
        Check_Boot_Indicator --> Normal_Boot_Path : User_Select_Normal
        Check_Boot_Indicator --> Fast_Boot_Path : User_Select_Fast
    }

    state Fail_Safe_Triggered {
        Fail_Safe_Triggered --> FS_Retrieve_Config : Entry
        FS_Retrieve_Config --> FS_Generate_Config
        FS_Generate_Config --> FS_Perform_Init
        FS_Perform_Init : Initialize Minimal Hardware
        FS_Perform_Init : Enable Verbose Logging
        FS_Perform_Init --> FS_Launch_Diagnostic_Shell
        FS_Launch_Diagnostic_Shell : Diagnostic OS/Shell
    }

    state Normal_Boot_Path {
        Normal_Boot_Path : Full System Init
        Normal_Boot_Path --> Launch_Full_OS
    }

    state Fast_Boot_Path {
        Fast_Boot_Path : Reduced System Init
        Fast_Boot_Path --> Launch_Fast_OS
    }

    FS_Launch_Diagnostic_Shell --> [*]
    Launch_Full_OS --> Running_Full_OS
    Launch_Fast_OS --> Running_Fast_OS
    Running_Full_OS --> [*]
    Running_Fast_OS --> [*]

Derivative 5.2: Ultra-Low Power Resume Boot Path

Enabling Description:
This derivative introduces an "Ultra-Low Power Resume" boot path, designed for systems that frequently enter deep sleep or hibernation states and need to resume operation with minimal power expenditure and maximum speed. The boot path indicator (130) would be internally generated by the power management unit upon waking from a deep sleep state (e.g., S3/S4/S5 power states in ACPI, or custom SoC low-power modes). The configuration information (150) for this path would specify:

  1. Partial Memory Initialization: Instead of a full DRAM re-initialization (which is power-intensive), only the necessary memory regions required for the operating system context restoration are validated and powered up, potentially leveraging self-refresh modes or retained memory controllers.
  2. Selective Device Wake-up: Only the absolute minimum devices (112) required for the operating system (160) to resume execution are powered on and initialized (e.g., CPU, memory controller, necessary I/O for input/display), skipping power-on-self-test (POST) for non-critical components.
  3. Optimized Power Gating: The firmware performs intelligent power-gating, reactivating only the power rails essential for the resumed operation, keeping other system blocks in a deeply sleep state until explicitly requested by the OS.
    This enables extremely fast "instant-on" capabilities from deep power-saving states, extending battery life in mobile devices and improving user experience.
flowchart TD
    A[System in Deep Sleep/Hibernation] --> B(Power Management Unit (PMU) Wakes);
    B -- PMU generates --> C[Ultra-Low Power Resume Boot Path Indicator 130];
    C --> D[BIOS Firmware 110];
    D -- Retrieve Config (ULP-Resume) --> E{Configuration Table 150 (ULP-Resume)};
    E -- Specifies Partial Init --> F[Validate/Power Up Required Memory Regions];
    E -- Specifies Selective Wake-up --> G[Activate Only Essential Devices 112];
    E -- Specifies Optimized Power Gating --> H[Perform Intelligent Power Gating];
    F & G & H --> I[Generate Firmware Configuration 120 (ULP-Resume)];
    I --> J[Perform Configuration (Minimal Power)];
    J --> K[Resume Operating System 160 from Memory Context];
    K --> L[System Live (Low Power Resume)];

Combination Prior Art Scenarios with Open-Source Standards

Here are three scenarios combining US Patent 8510543 with existing open-source standards to demonstrate further prior art:

1. US'543 + UEFI (Unified Extensible Firmware Interface) + ACPI (Advanced Configuration and Power Interface)

  • Scenario Description: A computer system (as per Claim 16 of US'543) implements its multiple boot path functionality using UEFI firmware (as explicitly mentioned in US'543 Description: "The BIOS firmware 110 associated with the computer 100 may be a BIOS, a legacy BIOS, an extensible firmware interface (EFI) firmware, a unified EFI (UEFI) firmware..."). The configuration information (150) for each boot path is not only specified within the UEFI firmware but is dynamically communicated to the operating system using ACPI (Advanced Configuration and Power Interface) tables. Specifically, during the "performing the configuration" phase (Claim 1), the UEFI firmware generates or modifies ACPI tables (e.g., DSDT - Differentiated System Description Table, or SSDT - Secondary System Description Table) to reflect the initialized hardware components and their power states according to the selected boot path. For instance, a "fast-boot" path might generate ACPI tables indicating that USB controllers are initially disabled, and specific power-gated regions are offline, allowing the OS to interact with the hardware as configured by UEFI, consistent with ACPI specifications for power and configuration management. The boot path indicator (130) could even be passed to the OS via a custom ACPI method. This combination clearly outlines how the BIOS firmware configuration influences the OS's perception and management of hardware post-boot.

2. US'543 + CoreBoot/LinuxBoot

  • Scenario Description: The concept of "Firmware supporting multiple boot paths" (Claims 1, 9, 16 of US'543) is implemented using an open-source firmware project like CoreBoot or LinuxBoot. Instead of a traditional proprietary BIOS, the initial boot firmware is CoreBoot. The "boot path indicator" (130) is received by CoreBoot. The "configuration information" (150) is stored within CoreBoot's CBFS (CoreBoot File System) or a similar structure. CoreBoot, during its initialization phase (corresponding to "generating a configuration of the firmware" and "performing the configuration" in US'543), dynamically assembles a payload based on the selected boot path. This payload could be a specific Linux kernel (LinuxBoot) that acts as the initial system firmware. Different boot paths would lead to CoreBoot loading different Linux kernels or different initramfs images, each pre-configured to initialize a distinct subset of hardware components (112) before the main operating system (160) takes over. For example, one CoreBoot path might load a Linux kernel that only initializes critical network hardware for a network boot (PXE), while another loads a kernel that enables extensive diagnostics for all hardware, effectively implementing US'543's principles with fully open-source components.

3. US'543 + Open Firmware (IEEE 1275)

  • Scenario Description: A computing system utilizes Open Firmware (IEEE 1275), an open standard for firmware boot environments, to support the multiple boot paths described in US'543. In this setup, the "boot path indicator" (130) is a user-selectable option presented by the Open Firmware's command-line interface or graphical menu (e.g., "boot-device: /pci@80000000/mac-io@c/ata-4@1/disk@0:1,ofw-diag"). Open Firmware uses a device tree structure to describe system hardware. The "configuration information" (150) for each boot path corresponds to a specific Open Firmware script or device tree overlay that is applied during the "executing the boot path" phase. This script would precisely define which hardware devices (112) are initialized, their operating parameters, and which Open Firmware 'methods' (firmware modules) are invoked, directly matching the "generating a configuration" and "performing the configuration" steps. For instance, a "graphics-lite" boot path would utilize an Open Firmware script that disables specific advanced features of the graphics adapter (462) or only initializes a basic framebuffer, while a "full-graphics" path would execute a script enabling all display capabilities. This demonstrates how a highly extensible, open-standard firmware can implement dynamic, OS-specific hardware initialization.

Generated 7/3/2026, 10:16:12 PM