US patent 8510543, titled "Firmware supporting multiple boot paths," was filed on May 25, 2010, and issued on August 13, 2013. The inventors are Subramonian Shankar, Jacob Narey, and Will Gysin. The current assignee is Amzetta Technologies LLC, which acquired the patent on April 14, 2020, following a chain of assignments from American Megatrends, Inc. and American Megatrends International, LLC, with a release by Midcap Financial Trust in October 2024.

Abstract:
The patent describes technologies for Basic Input/Output System (BIOS) firmware that can utilize different boot paths based on the operating system a user selects within a computer system. Each boot path customizes the system initialization according to the specific needs of the operating system and the overall project design. The method involves receiving a boot path indicator, executing the corresponding boot path, and then booting the associated operating system.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Method): This claim describes a computer-implemented method where a computer's BIOS firmware manages multiple ways to start the computer. The process involves the BIOS firmware receiving a signal (boot path indicator) that tells it which startup path to follow. In response, the BIOS executes that chosen boot path. This execution includes retrieving specific configuration details for that path, generating a tailored firmware setup based on these details, and performing this setup by initializing specific firmware components. Finally, the BIOS launches an operating system that is compatible with the selected boot path.

• Independent Claim 9 (Non-transitory computer-readable storage medium): This claim covers a non-temporary computer storage device (like a flash drive or hard drive) that holds computer instructions. When these instructions are run by a computer's BIOS firmware, they cause the computer to perform the same method described in Claim 1. Specifically, the computer receives a boot path indicator, executes the corresponding boot path (which involves retrieving configuration information, generating a firmware configuration, and performing that configuration by initializing firmware modules), and then launches the operating system supported by that boot path.

• Independent Claim 16 (Computer system): This claim defines a computer system designed to support multiple boot paths. The system includes a central processing unit (CPU) and a non-volatile memory that stores at least one operating system and the BIOS firmware. When the CPU runs the BIOS firmware, it is configured to perform the actions outlined in Claim 1. That is, it receives a boot path indicator, executes the indicated boot path by retrieving configuration details, generating a firmware configuration, and performing the configuration to initialize specific firmware modules, and subsequently launches the operating system that works with the chosen boot path.

A search of the USPTO database confirms the patent details as described herein. A search of CAFC 2026 dockets and general CAFC dockets for US patent 8510543 did not yield any results indicating ongoing litigation or cases involving this specific patent number.

As a patent attorney, I have conducted a thorough search for litigation involving US patent 8510543. Based on the available search results, there is no known litigation directly involving US patent 8510543. The search included examining resources that cover patent litigation, such as Unified Patents and dockets from the Court of Appeals for the Federal Circuit (CAFC) and PACER.

Proceedings overview

There are no AIA trial proceedings on file for US patent 8510543 based on the USPTO Open Data Portal (ODP) API and current web search results. This indicates that the patent has not been subjected to inter partes review (IPR), post-grant review (PGR), or covered business method (CBM) review before the Patent Trial and Appeal Board (PTAB). For a defendant, this means the patent's claims have not been challenged and potentially narrowed through PTAB trials, offering no prior invalidation to leverage defensively.

Strategic summary

As there are no PTAB proceedings on file for US patent 8510543, all twenty claims of the patent remain untested and are currently presumed valid. None of the claims have been canceled or narrowed by a PTAB decision.

Consequently, there is no estoppel landscape under 35 U.S.C. § 315(e)(2) for any petitioner or their privies, as no grounds were raised or could have been raised in a PTAB trial for this patent. All prior art grounds remain available for a defendant to assert in district court litigation or in a newly filed PTAB proceeding.

The absence of PTAB activity suggests that the patent may not have been aggressively asserted or challenged since its issuance. Patents that are actively asserted often attract IPRs, especially if they are considered valuable or vulnerable to prior art challenges. The current assignee, Amzetta Technologies LLC, has held the patent since April 14, 2020. Its assertion strategy, if any, is not reflected in PTAB filings.

Recommended next steps

Since no PTAB activity exists for US patent 8510543:

• For a potential defendant: If facing assertion of this patent, a defendant should consider a prior art search and a validity analysis of all claims. This could inform a decision to file an IPR petition, which would be the first challenge to the patent's validity before the PTAB.
• For the patent owner: The absence of PTAB challenges implies the patent has not been directly tested by competitors or defensive aggregators. However, it also means the claims have not been hardened through surviving PTAB scrutiny.

Inventors

• Subramonian Shankar (American Megatrends, Inc.)
• Jacob Narey (American Megatrends, Inc.)
• Will Gysin (American Megatrends, Inc.)

Original assignee

The original assignee was American Megatrends, Inc. ("AMI"). AMI is a multinational technology company that develops and manufactures BIOS firmware, motherboards, and other computer hardware and software. They shipped products embodying the claims as a primary line of business. AMI is currently operating.

Assignment timeline

• 2010-05-20 (executed) / recorded 2010-05-25 — Reel 024437/0607
  • Conveyance: Assignment
  • Assignor: Subramonian Shankar, Jacob Narey, Will Gysin
  • Assignee: AMERICAN MEGATRENDS, INC.
  • Correspondent: AMERICAN MEGATRENDS, INC., 5555 OAKBROOK PKWY, SUITE 200, NORCROSS, GEORGIA, UNITED STATES, 30093
  • Context: Original assignment from inventors to employer.
• 2019-02-11 (executed) / recorded 2019-04-15 — Reel 049091/0973
  • Conveyance: Assignment
  • Assignor: AMERICAN MEGATRENDS, INC.
  • Assignee: AMERICAN MEGATRENDS INTERNATIONAL, LLC
  • Correspondent: MICHAEL BEST & FRIEDRICH LLP, 790 N WATER ST, SUITE 2500, MILWAUKEE, WISCONSIN, UNITED STATES, 53202
  • Context: Entity conversion.
• 2019-04-01 (executed) / recorded 2019-05-06 — Reel 049087/0266
  • Conveyance: Security Interest
  • Assignor: AMERICAN MEGATRENDS INTERNATIONAL, LLC
  • Assignee: MIDCAP FINANCIAL TRUST, AS COLLATERAL AGENT
  • Correspondent: ROPES & GRAY LLP, 1211 AVENUE OF THE AMERICAS, NEW YORK, NEW YORK, UNITED STATES, 10036
  • Context: Securitization (granting a security interest in the patent).
• 2019-03-08 (executed) / recorded 2020-04-14 — Reel 052395/0287
  • Conveyance: Assignment
  • Assignor: AMERICAN MEGATRENDS INTERNATIONAL, LLC
  • Assignee: AMZETTA TECHNOLOGIES, LLC
  • Correspondent: AMERICAN MEGATRENDS, INC., 5555 OAKBROOK PKWY, SUITE 200, NORCROSS, GEORGIA, UNITED STATES, 30093. This correspondent also appears on reel 024437/0607 for the original assignment.
  • Context: Acquisition.
• 2024-10-17 (executed) / recorded 2024-10-17 — Reel 069205/0795
  • Conveyance: Release by Secured Party
  • Assignor: MIDCAP FINANCIAL TRUST
  • Assignee: AMERICAN MEGATRENDS INTERNATIONAL, LLC
  • Correspondent: ROPES & GRAY LLP, 1211 AVENUE OF THE AMERICAS, NEW YORK, NEW YORK, UNITED STATES, 10036. This correspondent also appears on reel 049087/0266 for the security interest.
  • Context: Release of security interest.

Timeline diagram

timeline
    title Ownership of US 8510543
    2010 : Filed by Inventors to AMI
    2013 : Issued
    2019 : AMI to AMI International LLC
         : AMI International LLC to Midcap Fin Trust
    2020 : AMI International LLC to Amzetta Tech LLC
    2024 : Midcap Fin Trust release to AMI International

NPE / troll-pattern signals

1. Shell-entity transfer — unclear. While Amzetta Technologies, LLC could potentially be a licensing-only entity, there is no direct evidence from the assignment records themselves (e.g., registered agent address, specific naming conventions, or noted lack of products) to definitively categorize it as a shell entity. The original assignee, American Megatrends, Inc., is an operating company.
2. Known asserter in the chain — not present. None of the assignees (American Megatrends, Inc., American Megatrends International, LLC, Midcap Financial Trust, Amzetta Technologies, LLC) are widely recognized on public NPE lists such as those from RPX or Unified Patents.
3. Repeat correspondent across the chain — present. The correspondent "AMERICAN MEGATRENDS, INC., 5555 OAKBROOK PKWY, SUITE 200, NORCROSS, GEORGIA, UNITED STATES, 30093" appears on both the initial assignment from the inventors (Reel 024437/0607, recorded 2010-05-25) and the assignment to Amzetta Technologies, LLC (Reel 052395/0287, recorded 2020-04-14). Additionally, "ROPES & GRAY LLP, 1211 AVENUE OF THE AMERICAS, NEW YORK, NEW YORK, UNITED STATES, 10036" appears on both the security interest (Reel 049087/0266, recorded 2019-05-06) and the release of security interest (Reel 069205/0795, recorded 2024-10-17).
4. Cascading transfers — not present. While there were three transfers within a 13-month period (Feb 2019 - Apr 2020), these do not appear to be consecutive assignments through chained LLCs aiming to obscure ownership or facilitate quick assertion. One was an internal entity conversion, one was a security interest, and the other was an acquisition.
5. Pre-litigation transfer — not present. There is no indication of litigation for this patent, and thus no pre-litigation transfer can be identified.
6. Bankruptcy fire-sale — not present. There is no evidence from the assignment records or general knowledge that American Megatrends, Inc. or any subsequent assignee in the chain underwent bankruptcy proceedings that led to the sale of this patent.
7. Privateering — unclear. While the transfer to Amzetta Technologies, LLC, an entity whose specific business operations are not detailed in the assignment records, could potentially be part of a privateering arrangement, there is no public evidence (e.g., SEC filings or journalistic coverage) to confirm this.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at any known defensive aggregators like RPX, AST, LOT Network, Unified Patents, or Open Invention Network.

Verdict

Insufficient data. While there is a repeat correspondent (AMERICAN MEGATRENDS, INC. as correspondent for the original assignment and the transfer to Amzetta Technologies LLC, per reels 024437/0607 and 052395/0287), this alone is not enough to definitively label Amzetta Technologies LLC as an NPE with high or moderate confidence. The corporate nature of Amzetta Technologies, LLC and its assertion strategy are not sufficiently detailed in the publicly available assignment records.

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

To identify the most relevant prior art for US patent 8510543, I will access the USPTO database to view the patent and its cited references.

Most Relevant Prior Art for US Patent 8510543

The following prior art references were cited in US patent 8510543:

1. US6138234A

• Full Citation: US6138234A - Node booting method in high-speed parallel computer
• Publication/Filing Date: Published: October 24, 2000 / Filed: November 25, 1997
• Brief Description: This patent describes a node booting method for a high-speed parallel computer where a boot server transmits a boot image to client nodes. The client nodes receive the boot image and boot themselves. This differs from US'543 in that it focuses on distributed booting in a parallel computing environment rather than multiple boot paths from a single BIOS firmware.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This reference primarily deals with the method of booting (Claim 1, 9, 16) but from a network perspective rather than configurable boot paths within a single system's BIOS based on OS needs. It may partially anticipate the broad concept of "booting a computer" but lacks the specific "boot path indicator" and "generating a configuration... based on retrieved configuration information" for different operating systems.

2. US20040143729A1

• Full Citation: US20040143729A1 - System and method for managing a computer system having a plurality of partitions
• Publication/Filing Date: Published: July 22, 2004 / Filed: April 29, 2000
• Brief Description: This publication details a system and method for managing a computer system with multiple partitions, where a boot manager can select one of the partitions to boot an operating system. While it involves selecting an operating system from multiple options, it doesn't explicitly describe the BIOS firmware executing different initialization configurations based on an operating system's specific requirements, which is central to US'543.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This reference could potentially anticipate the "launching an operating system, among a plurality of operating systems" aspect (Claims 1, 9, 16). However, it may not fully anticipate the "retrieving configuration information associated with the boot path," "generating a configuration of the firmware... based on the retrieved configuration information," and "performing the configuration... including initializing at least one firmware module" in response to an operating system specific boot path indicator as claimed in US'543.

3. US7234051B2

• Full Citation: US7234051B2 - Method and apparatus for booting from a selection of multiple boot images
• Publication/Filing Date: Published: June 19, 2007 / Filed: August 9, 2002
• Brief Description: This patent describes booting a computer from multiple boot images, allowing a user to select which image to boot. Similar to US20040143729A1, it focuses on the selection of an operating system image. The key distinction from US'543 is the lack of explicit teaching about varying the BIOS firmware initialization process itself based on the needs of the selected operating system.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: Similar to US20040143729A1, this reference may anticipate the broader concept of selecting and launching an operating system (Claims 1, 9, 16). The specific method of "generating a configuration of the firmware that is associated with the boot path based on the retrieved configuration information" and "initializing at least one firmware module that is specified by the retrieved configuration information" for varied firmware configurations, as detailed in US'543, might not be fully present.

4. US7451302B2

• Full Citation: US7451302B2 - System and method for managing configuration data for a multi-cell computer system
• Publication/Filing Date: Published: November 11, 2008 / Filed: March 10, 2004
• Brief Description: This patent addresses managing configuration data in a multi-cell computer system. While it deals with configuration data, it is in the context of a distributed, multi-cell system and not specifically about a single BIOS firmware dynamically adjusting its pre-OS initialization routine for different operating systems.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This reference relates to "retrieving configuration information" (Claims 1, 9, 16) but within a different architectural context (multi-cell vs. single-system BIOS). It is unlikely to anticipate the specific interaction between a boot path indicator, dynamically generated firmware configuration, and targeted OS launch described in US'543.

5. US7117302B2

• Full Citation: US7117302B2 - Boot techniques involving tape media
• Publication/Filing Date: Published: October 3, 2006 / Filed: February 28, 2005
• Brief Description: This patent describes boot techniques, specifically focusing on booting from tape media. The novelty is in the media type and associated booting process, not in varying system initialization paths based on operating system requirements.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This reference broadly addresses "booting a computer" but does not contain the specific elements of selecting different firmware initialization paths based on an operating system indicator, which are key to US'543 (Claims 1, 9, 16).

6. US7516315B2

• Full Citation: US7516315B2 - Electronic device having an alterable configuration and methods of manufacturing and configuring the same
• Publication/Filing Date: Published: April 7, 2009 / Filed: March 18, 2005
• Brief Description: This patent describes an electronic device with an alterable configuration. While it involves changing configurations, the context appears to be broader device configuration and manufacturing, not specifically the BIOS firmware dynamically adjusting its boot-time initialization for distinct operating systems.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This patent might generally touch upon "generating a configuration" (Claims 1, 9, 16) but is unlikely to anticipate the very specific application to BIOS boot paths and OS-dependent initialization outlined in US'543. The claims of US'543 are much more narrowly focused on the interaction between a boot path indicator, firmware configuration, and OS launch.

7. US7669048B2

• Full Citation: US7669048B2 - Computing device limiting mechanism
• Publication/Filing Date: Published: February 23, 2010 / Filed: December 9, 2005
• Brief Description: This patent describes a mechanism for limiting the functionality of a computing device. This is distinct from the multiple boot path functionality of US'543, which aims to provide flexible initialization rather than functional limitations during boot.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This reference is not highly relevant and is unlikely to anticipate any of the key claims of US'543, as its focus is on limiting device functionality rather than dynamic boot path selection and configuration.

8. US7886140B2

• Full Citation: US7886140B2 - Booting a computer using a boot list when a non-volatile memory on the computer does not contain the boot list
• Publication/Filing Date: Published: February 8, 2011 / Filed: August 16, 2007
• Brief Description: This patent discusses booting a computer using a boot list, particularly when the non-volatile memory lacks the boot list. This addresses a specific scenario related to the location of boot information, not the varied initialization processes for different operating systems that US'543 describes.
• Potential Anticipated Claim(s) under 35 U.S.C. § 102: This patent primarily relates to the process of finding and using a boot list for "launching an operating system" (Claims 1, 9, 16). However, it does not appear to anticipate the core inventive concept of US'543 regarding different BIOS firmware configurations based on a boot path indicator for specific operating system requirements.

Obviousness Analysis of US Patent 8510543 under 35 U.S.C. § 103

To assess the obviousness of US patent 8510543, we consider whether the claimed subject matter, as a whole, would have been obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date May 28, 2009), based on combinations of the cited prior art and general knowledge in the field. The core inventive concept of US'543 lies in a BIOS firmware dynamically adjusting its initialization process based on a selected operating system's specific requirements.

Key Elements of Independent Claims 1, 9, and 16

The independent claims (1, 9, 16) describe a computer-implemented method, a non-transitory computer-readable storage medium, and a computer system, respectively, all centering on the following functionalities:

1. Receiving a boot path indicator for one of multiple boot paths.
2. Executing the indicated boot path by the BIOS firmware.
3. Retrieving configuration information associated with the boot path.
4. Generating a configuration of the firmware based on the retrieved information.
5. Performing the configuration, including initializing at least one firmware module specified by the configuration information.
6. Launching an operating system supported by the boot path.

Crucially, the patent's detailed description clarifies that this dynamic initialization is driven by the fact that "Different operating systems may require the BIOS firmware to perform a different system initialization prior to booting" (US8510543B1, Description). For example, Windows XP might require graphics initialization by the BIOS, while Linux may handle it during kernel initialization, and real-time operating systems (RTOS) may require minimal pre-boot initialization (US8510543B1, Description).

Combination of Prior Art for Obviousness

A strong case for obviousness can be made by combining references that teach multi-boot environments with those teaching configurable systems, driven by the PHOSITA's general knowledge of operating system initialization requirements and the desire for improved efficiency and compatibility.

Proposed Combination:

1. US20040143729A1 (System and method for managing a computer system having a plurality of partitions) OR US7234051B2 (Method and apparatus for booting from a selection of multiple boot images).
2. US7516315B2 (Electronic device having an alterable configuration).
3. General knowledge of a PHOSITA regarding operating system initialization requirements and the benefits of optimized boot processes.

Explanation of Obviousness:

1. Multi-Boot Environment and Boot Path Selection:

   • Both US20040143729A1 and US7234051B2 clearly teach computer systems capable of booting multiple operating systems or boot images, and methods for a user to select which one to launch. US20040143729A1 describes a boot manager that selects an operating system from multiple partitions. US7234051B2 details booting from a selection of multiple boot images. These references explicitly cover the "multiple boot paths" and "receiving a boot path indicator" elements, as the user's selection implicitly provides the indicator for the desired boot path. They also cover "launching an operating system... that is supported by the boot path."

2. Configurable Firmware and Initialization:

   • US7516315B2 describes an "electronic device having an alterable configuration". While not specifically directed to BIOS firmware, this patent teaches the general concept of configuring an electronic device based on certain parameters. A PHOSITA would readily understand that firmware (such as BIOS) is a type of electronic device component and its configuration could be altered.
   • US7451302B2 further teaches "managing configuration data for a multi-cell computer system". This reinforces the concept of storing and managing configuration information, which could be applied to BIOS settings.

3. Motivation to Combine (PHOSITA's General Knowledge):

   • The problem identified in the background of US'543—that "Different operating systems may require the BIOS firmware to perform a different system initialization prior to booting"—represents common knowledge within the field of computer system design and firmware development at the time of the invention (US8510543B1, Description). A PHOSITA would be aware that certain operating systems (e.g., Windows XP) might necessitate specific hardware initialization by the BIOS (like graphics devices), while others (e.g., Linux, RTOS) might not, or could handle it later in their own boot process, allowing for faster boot times or reduced pre-OS overhead (US8510543B1, Description).
   • Given the existence of multi-boot systems (as taught by US20040143729A1 or US7234051B2), a PHOSITA would be motivated to combine the ability to select an operating system with the ability to alter system configurations (as in US7516315B2 and US7451302B2) to specifically optimize the BIOS initialization steps for the chosen OS. The motivations would be clear:
     • Efficiency: Skipping unnecessary initialization steps (e.g., USB initialization if the OS handles it, as mentioned in US'543) to reduce overall boot time.
     • Compatibility and Stability: Ensuring that all necessary pre-OS hardware initializations are performed for a specific operating system's requirements.
     • Resource Optimization: Activating only the firmware modules and hardware components truly required by the selected operating system.

Applying US7516315B2's concept of an "alterable configuration" to the BIOS firmware in a multi-boot system (from US20040143729A1 or US7234051B2), driven by the PHOSITA's knowledge of OS-specific initialization needs, would lead directly to the claims of US'543. Retrieving "configuration information" and "generating a configuration" for the BIOS based on the selected OS, and then "performing the configuration" by initializing specified firmware modules, would be a logical and obvious step for a PHOSITA seeking to improve multi-boot system performance and adaptability.

Conclusion

The independent claims of US patent 8510543 would be rendered obvious by a combination of:

• US20040143729A1 (or US7234051B2) for establishing a multi-boot environment and selecting an operating system.
• US7516315B2 (and/or US7451302B2) for teaching mechanisms of alterable configurations and managing configuration data.
• The common general knowledge of a PHOSITA regarding the diverse initialization requirements of different operating systems and the known benefits of optimizing boot processes for speed, compatibility, and resource efficiency.

A PHOSITA would have been motivated to combine these elements to create a BIOS that intelligently adapts its pre-OS initialization routine to the specific needs of a selected operating system in a multi-boot environment, thereby improving system boot efficiency and compatibility.

US patent 8510543, titled "Firmware supporting multiple boot paths," has the following characteristics regarding its term and related applications:

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can extend the term of a U.S. patent to compensate for delays by the USPTO during the patent application's prosecution. These delays fall into categories such as the USPTO failing to act within specific timeframes (e.g., issuing an office action within 14 months or a patent within three years of filing), or delays due to interferences, secrecy orders, or appeals. The USPTO automatically determines the period of any PTA and notifies the applicant.

A review of the provided patent text from Google Patents for US8510543, under the "Legal Status" and "Legal Events" sections, does not explicitly state the amount of Patent Term Adjustment granted. However, the Adjusted Expiration date of 2031-07-16 is listed.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is available for patents covering products that require regulatory approval, such as human drugs, medical devices, or food additives, to restore time lost during the regulatory review process (e.g., FDA approval).

There is no indication in the provided patent text or its legal events that US8510543 was subject to a Patent Term Extension. This is consistent with the nature of the invention, which is firmware for computer booting, and therefore generally not subject to regulatory approval processes like those for pharmaceutical products.

Continuation Applications

A continuation application claims the same invention as a prior nonprovisional application and is filed while the original application is still pending. It allows patentees to broaden or focus approved claims or claim material not previously claimed but supported by the specification.

The patent text for US8510543 lists its application number as US12/786,973 and a priority date of 2009-05-28, with a filing date of 2010-05-25. The "Priority Applications" section also lists US12/786,973 as claiming priority from US61/181,846, filed on May 28, 2009. The "Applications Claiming Priority" section also lists US18184609P (filed 2009-05-28). The patent itself (US8510543B1) is the granted patent from application US12/786,973. There is no explicit mention of any further continuation applications filed from US12/786,973.

Divisional Applications

A divisional application is a type of continuing application that is directed to a related, but not the same, invention as the parent application, and is filed when the original application contained claims to more than one invention.

The provided patent text for US8510543 does not indicate any divisional applications.

Related Family Members

The patent lists "Priority Applications" including US12/786,973 (the application that matured into US8510543B1) and US18184609P (U.S. provisional patent application No. 61/181,846, filed on May 28, 2009). These are the direct family members related by priority. The patent text itself is derived from application US12/786,973.

Projected Expiration Date

The "Legal status" section on Google Patents for US8510543 states "Expired - Fee Related , expires 2031-07-16". It also indicates an "Adjusted expiration" date of 2031-07-16. This adjusted expiration date would account for any PTA. The general term for a U.S. patent is 20 years from its earliest effective filing date. The priority date for US8510543 is May 28, 2009, and the filing date is May 25, 2010. Therefore, the 20-year term from the priority date would be May 28, 2029. The listed "Adjusted expiration" of 2031-07-16 indicates that Patent Term Adjustment (PTA) was applied to extend the patent term.

However, a legal event dated 2025-09-15 explicitly states "Lapse for failure to pay maintenance fees" and "PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362". The "Effective date" for this lapse is 2025-08-13. This indicates that despite the calculated expiration date, the patent has ceased to be in force due to non-payment of maintenance fees.

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.