Obviousness

US patent 7502958 claims a system and method for firmware-recoverable lockstep protection that addresses limitations of prior art by using firmware to orchestrate recovery in cooperation with the operating system (OS) via standard interfaces, such as Advanced Configuration and Power Interface (ACPI). However, several aspects of the independent claims appear to be obvious combinations of known prior art elements.

A person having ordinary skill in the art (PHOSITA) in computer architecture and fault-tolerant systems, at the time of the invention (priority date October 25, 2004), would have been aware of the following:

• Lockstep Processing and Loss of Lockstep (LOL) Detection: The patent itself acknowledges that lockstep processing, where two processors perform identical operations and their outputs are compared (e.g., via an XOR gate) to detect errors, was a known technique for Silent Data Corruption (SDC) detection in processor execution cores. Detection of LOL, including "lockstep mismatch" (outputs not matching) or "precursors to lockstep mismatch" (e.g., data corruption in a cache detected by parity/ECC), was also known. [cite: US7502958 Description]
• Firmware-based Recovery: Firmware's role in detecting processor failures and initiating recovery actions in multiprocessor systems was established. For instance, US6334185B1, titled "Fault tolerant multiprocessor system having system firmware for recovering from processor failures and methods therefor," suggests firmware's involvement in recovery. [cite: US7502958 Citations] The patent also explicitly references US20040006722A1 ("METHOD AND APPARATUS FOR RECOVERY FROM LOSS OF LOCK STEP") as describing techniques for recovery from LOL, albeit one that makes processors unavailable without OS knowledge, potentially leading to system crashes. [cite: US7502958 Description]
• Operating System-Directed Power and Resource Management (ACPI): The ACPI specification, an open industry standard, provided well-defined interfaces for operating systems to manage power, performance, and configuration of devices and processors. This included mechanisms for the OS to put processors into various low-power "idle" or "sleeping" states (C-states). ACPI also defined methods, such as the _STA (status) object, for devices to report their status (e.g., present, enabled, functioning) to the OS, allowing the OS to discover and configure hardware dynamically. The ACPI specification emphasizes that the OS (via OSPM) has "direct and exclusive control over the power management and motherboard device configuration functions," and hardware/firmware "must not manipulate the platform's configuration... independently of OSPM." This points to a cooperative model where firmware provides interfaces and information, but the OS makes policy decisions.
• Hot Spare Processors in Fault-Tolerant Systems: The concept of "hot spares" or redundant processors for fault tolerance, particularly for critical components, was well-known. A hot spare typically mirrors the operation of a primary component and can take over instantly upon failure. Systems like Stratus were known to use lockstep processors and, upon detection of a mismatch, could take a board out of service and later reintroduce it if the fault was transient. Logical removal of a failed module by instructing other units to ignore it was also a known technique.

Obviousness Analysis of Independent Claims:

Independent Claim 1 & 19 (Firmware-Coordinated Recovery for Non-Boot Processors)

Combination: US20040006722A1 (lockstep recovery) + ACPI Specification (OS-firmware interaction for processor management) + General knowledge of fault-tolerant firmware.

Motivation for Combination:
The patent itself highlights the problems with existing LOL recovery methods: either crashing the system or firmware-only recovery that could still lead to crashes if the OS was unaware of the processor's temporary unavailability. A PHOSITA, aiming to improve system availability and robustness without requiring OS-specific code (a burden acknowledged in the patent), would have been motivated to combine known lockstep recovery techniques (like those in US20040006722A1) with the standardized, OS-cooperative mechanisms provided by ACPI.

Specifically, ACPI's provisions for OS-directed processor power management (idling) and device status reporting (_STA method) offered a clear pathway for firmware to:

1. "Trigger an operating system to idle the lockstep pair of processors": Firmware detecting an LOL could logically update a device's status via ACPI-defined mechanisms to indicate a problem (e.g., setting the "functioning properly" bit to '0'), prompting an ACPI-compatible OS to idle or "eject" the problematic processor. [cite: 3, US7502958, Fig 1, Block 103]
2. "Recover lockstep for the lockstep pair of processors": This process itself was known prior art (e.g., US20040006722A1).
3. "Trigger the operating system to recognize the lockstep pair of processors having recovered lockstep": Once recovery was complete, the firmware could update the device's ACPI status (e.g., setting "present, enabled and functioning" bits to '1'), allowing the OS to re-recognize the processor as available and resume scheduling tasks. [cite: US7502958, Fig 1, Block 106]

The determination by firmware of whether LOL is "recoverable" by checking for a "lockstep mismatch" is a design choice within the broader concept of fault-tolerant firmware distinguishing between fault types to determine appropriate responses.

Independent Claim 13 (System with ACPI-Compatible OS and Firmware)

Combination: Standard lockstep processor hardware + ACPI-compatible OS + Firmware for processor failure recovery (e.g., US6334185B1) + ACPI specification for OS-firmware communication.

Motivation for Combination:
The elements of this claim (ACPI-compatible OS, master/slave lockstep processors, and firmware) were all individually known. The motivation for combining them to implement the specific interaction described would be the same as for Claim 1: to leverage the ACPI standard to enable graceful, OS-aware recovery from lockstep errors, thereby achieving higher system availability than previous firmware-only or OS-centric approaches. A PHOSITA would recognize ACPI as the appropriate standardized interface for firmware to communicate processor state changes (idling, reintroduction) to the OS without requiring proprietary OS modifications.

Independent Claim 23 (Hot Spare for Boot Processor in Multi-Processor System)

Combination: Prior art on hot spare processors in fault-tolerant systems (e.g., Stratus systems) + Prior art on lockstep recovery (e.g., US20040006722A1) + ACPI-cooperative recovery (as in Claim 1) + General knowledge of firmware managing processor roles (like boot processor status in a device tree).

Motivation for Combination:
The patent itself states that "problems arise in attempting to idle (or eject) the boot processor from the system," motivating a "different recovery technique." [cite: US7502958 Description] A PHOSITA would recognize that the boot processor is a critical component for which a more immediate and robust fault-tolerance strategy, such as a hot spare failover, would be highly desirable. The general concept of "hot spares" for critical components, involving state copying and role swapping, was a well-established fault-tolerance technique.

Therefore, a PHOSITA would be motivated to:

1. "Establishing... a hot spare processor for a system boot processor": This is a known redundancy strategy for critical components.
2. "Determining if said lockstep pair of processors... is the system boot processor": Firmware's role in managing system configuration and identifying the boot processor (e.g., via a device tree) was a known practice.
3. "If... the system boot processor, copying a state of the system boot processor to the hot spare processor": This is a standard failover procedure for hot spares. The patent also directly cites prior art (US 2004/0006722 A1) that describes state switching techniques. [cite: US7502958 Description]
4. "If... not the system boot processor, then triggering an operating system to a) idle the lockstep pair..., b) attempt to recover lockstep..., and c) if lockstep is successfully recovered..., trigger said operating system to recognize the processors...": This simply applies the ACPI-cooperative recovery method from Claim 1 to non-boot processors, which, as argued above, would have been an obvious combination.

The use of different recovery strategies for a critical boot processor versus other application processors is a logical design optimization in fault-tolerant systems.

In summary, the core aspects of US7502958, particularly the firmware's role in coordinating lockstep recovery with the OS using standard ACPI methods and employing hot spares for critical boot processors, represent obvious combinations of known fault tolerance principles, ACPI capabilities, and existing lockstep recovery techniques, driven by a clear motivation to improve system availability and simplify OS design.