Obviousness

For a US patent to be considered obvious under 35 U.S.C. § 103, the differences between the claimed invention and the prior art must be such that the claimed invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which the subject matter pertains. This analysis often involves combining elements from multiple prior art references, provided there is a motivation to do so.

Here's an analysis of the obviousness of US Patent 7,669,081, focusing on potential combinations of prior art:

Overview of US7669081's Core Innovations

US7669081 primarily focuses on a software architectural framework for application-level task scheduling, processing, and monitoring, particularly in scalable and configurable environments. Key aspects include:

• Application-level scheduling: Providing scheduling capabilities beyond the operating system level, allowing developers to define task flow and conditions.
• Processor functions and tasks: Breaking down logical threads into reusable "processor functions" and modeling the state as a "task" passed between them.
• Rule-based task flow: Using developer-provided rules (strategy patterns) to dictate the selection of the next processor function and control task flow, including conditional branching and revisiting checkpoints.
• Priority queues and threading: Utilizing multiple priority queues, with each queue and processor function having its own thread, and allowing for high-priority task interruption.
• Persistence and recovery: Saving task state data at user/developer-defined checkpoints (before and after processor functions) to persistent storage for robust recovery and failover.
• Health monitoring: Monitoring the health of threads and SCI components, with mechanisms for reporting degraded health, restarting threads, or taking other corrective actions.
• Open Architecture (OA) and TSCE context: Although not limiting, the patent highlights its applicability within an OA environment like the U.S. Navy's Total Ship Computing Environment (TSCE).

Prior Art Landscape

The provided patent text and search results indicate a prior art landscape where:

• Operating system-level schedulers like Unix cron were common but had limitations. cron could handle simple, time-dependent scheduling, but struggled with non-time-dependent conditions, connecting job execution with results of other jobs, or conditional flow changes.
• Mainframe job schedulers offered more features than Unix cron, including some non-time-based triggering (e.g., database shutdown).
• Open Architecture (OA) systems were known and sought after in various industries, including military applications like the U.S. Navy's TSCE, to overcome limitations of "closed" or "stovepiped" systems. TSCE itself aimed to provide a scalable platform for mission capability and utilized an open system architecture.
• Concepts of fault tolerance and recovery were recognized, including creating "restore points" or "snapshots" to save the state of a computer system for later recovery.
• Monitoring application performance in distributed real-time systems was a known concern, especially in defense systems where task functions not getting sufficient resources or being late could lead to life-threatening situations. Open interfaces for measuring performance and dynamically adapting application behaviors were being designed.

Obviousness Combinations

Given this context, a person having ordinary skill in the art (PHOSITA) in 2006, when US7669081 was filed, would likely have been motivated to combine existing technologies to address known limitations in task scheduling, particularly for complex, mission-critical applications within open architectural frameworks.

Combination 1: Unix cron / Mainframe Schedulers + Application-level logic + Fault Tolerance/Recovery

References: Unix cron (explicitly mentioned as prior art limitations in US7669081), Mainframe job schedulers (explicitly mentioned), general knowledge of fault tolerance/recovery systems (explicitly mentioned in US7669081).

Motivation to combine:
The patent itself acknowledges the shortcomings of existing operating system-level schedulers like Unix cron (e.g., inability to handle non-time-dependent conditions or conditional job flow) and mainframe schedulers (which, while better, still operate at the OS level). A PHOSITA would be motivated to overcome these limitations, especially for complex applications where more granular control and dynamic flow based on application-specific conditions are needed. The desire to "save the state of an application or a high level process at user/developer defined points" to improve recovery and failover was a recognized need that existing systems did not adequately address.

Explanation of Obviousness:

• Application-level scheduling and rule-based flow: Given the limitations of OS-level schedulers, it would be obvious to move scheduling logic closer to the application to enable more sophisticated, conditional control. The concept of using "rules" or "strategy patterns" to govern program flow based on data or conditions is a fundamental aspect of software design. Applying such rules to task scheduling, allowing a developer to define how a "logical thread" progresses through "processor functions" based on internal data or external events (as opposed to just time), would be an obvious step for a PHOSITA seeking to build more flexible and robust application workflows.
• Persistence and recovery at checkpoints: The idea of "restore points" or "snapshots" for system recovery was known. Extending this concept to application-level "checkpoints" within a multi-task process, especially when those tasks are broken into discrete "processor functions," would be an obvious design choice to enhance application resilience. Saving the state data at these defined checkpoints, particularly at the beginning and end of processing steps, would directly address the need for recovering from application failures, as discussed in the background of US7669081. This is a predictable variation using known techniques to achieve a desired outcome.

Combination 2: Total Ship Computing Environment (TSCE) + Advanced Scheduling/Monitoring Capabilities

References: Total Ship Computing Environment (TSCE) / TSCE-I (explicitly mentioned in US7669081 as the environment for the invention), general knowledge of application performance monitoring in distributed systems (e.g., N04-223 - Navy SBIR).

Motivation to combine:
The TSCE was a large-scale open architecture system designed to integrate various shipboard computing applications and provide a scalable platform for new mission capabilities, emphasizing reliability, scalability, and availability. The need for robust performance measurement and recovery in such mission-critical, distributed real-time environments was well-established, as evidenced by Navy SBIR topics related to TSCE-I seeking open interfaces for measuring application performance and enabling reactions/recovery. A PHOSITA working on TSCE would be highly motivated to implement advanced scheduling, monitoring, and recovery mechanisms to ensure the stability and continuity of its complex applications.

Explanation of Obviousness:

• Adapting existing concepts to TSCE: While US7669081 describes its invention in the context of TSCE, the core scheduling, checkpointing, and recovery mechanisms are presented as general improvements. A PHOSITA would find it obvious to apply known techniques for robust task management, persistence, and recovery (as identified in Combination 1) to a large-scale, open architecture like TSCE. The distributed nature of TSCE, with services joining and leaving dynamically and the ability to move services upon failure, would make the need for application-level state persistence and controlled task flow even more apparent.
• Thread monitoring and health: The Navy SBIR topic N04-223 explicitly discusses the need for open interfaces to measure application performance and "react/recover otherwise" if requirements are not met, particularly in life-threatening situations within defense systems. This directly implies the need for health monitoring of application components (like threads) and mechanisms to respond to issues. Therefore, implementing thread-level health monitoring, reporting, and recovery (e.g., restarting unhealthy threads) within an application scheduler for a system like TSCE would be an obvious engineering choice for a PHOSITA.

Conclusion on Obviousness

The core advancements of US7669081, such as application-level scheduling with rule-based task flow, granular checkpointing for recovery, and thread-level health monitoring, represent logical evolutions and combinations of existing concepts in software engineering and distributed systems. While the patent describes these features in a specific, integrated framework, the individual components and the motivation to combine them to solve known problems (limitations of OS-level schedulers, need for application-specific recovery, and robust operation in complex environments like TSCE) would likely have been apparent to a PHOSITA at the time of the invention. The invention appears to be a predictable aggregation of known elements, each performing its accustomed function, to achieve a more reliable and flexible application-level task management system.