US 7669081

US Patent 7669081 Summary:

• Title: Systems and methods for scheduling, processing, and monitoring tasks
• Current Assignee: OL Security LLC
• Inventors: Richard Lett, Gregory Renno, Thomas Terwiel
• Filing Date: 2006-09-27
• Issue Date: 2010-02-23
• Abstract: A computer-implemented method for performing a process is provided. The method comprises: (a) receiving a request to perform a process, the process comprising a plurality of tasks and at least a scheduler rule; (b) receiving a plurality of checkpoints associated with the process, each checkpoint comprising checkpoint state data and at least a respective checkpoint rule governing execution of the process; (c) determining a first task of the plurality of tasks to be scheduled into a priority queue, in accordance with the scheduler rule; (d) determining the first checkpoint of the plurality of checkpoints that is to be the first checkpoint used in processing the first task, in accordance with the scheduler rule; (e) creating the checkpoint state data for the first checkpoint; (f) saving the checkpoint state data for the first checkpoint; (g) processing the first task in accordance with the checkpoint rule associated with the first checkpoint; (h) determining the next task in the plurality of tasks to perform, based on the checkpoint rule associated with the first checkpoint; (i) updating the saved checkpoint data for the first checkpoint with the data and state associated with the first task; and (j) repeating steps (c) through (i) for each subsequent task and checkpoint, in accordance with the respective scheduler and checkpoint rules, until a predetermined condition has been reached.

Plain-language Overview of Independent Claims:

The patent contains three independent claims: Claim 1, Claim 19, and Claim 29.

• Independent Claim 1 (Method for performing a process): This claim describes a computer-implemented method for executing a process composed of multiple tasks and checkpoints. It involves:

  • Receiving a request for a process with tasks and a main scheduler rule.
  • Receiving several checkpoints, each with its own state data and a rule for how the process should run at that checkpoint.
  • Using the main scheduler rule to decide which task to put into a priority queue first.
  • Using the scheduler rule to decide which checkpoint should process the first task.
  • Creating and saving initial data for that first checkpoint.
  • Processing the first task according to the first checkpoint's rule.
  • Based on the first checkpoint's rule, figuring out which task to do next.
  • Updating the saved data for the first checkpoint with the current task's information.
  • Repeating these steps for subsequent tasks and checkpoints, guided by their respective rules, until a predefined stopping point is reached.

• Independent Claim 19 (Method for processing a logical thread): This claim outlines a method for breaking down and managing a logical sequence of operations (a "logical thread"). It involves:

  • Dividing the logical thread into several smaller "processor functions."
  • Representing the state of this logical thread as a "task" that moves between these processor functions, carrying its data and current state.
  • Adding this task to a queue.
  • Saving the task's state at a first "checkpoint."
  • Choosing the first processor function to handle the task based on a specific rule.
  • The first processor function receiving the task, using its data to perform an operation, and storing the results back in the task.
  • Saving the task's state again at a second checkpoint.
  • Choosing a second processor function based on another rule.
  • The second processor function receiving the task and using the output from the first process as its input, if necessary.

• Independent Claim 29 (Computerized system for executing a process): This claim describes a system that uses a computer to run a process. The system includes:

  • Tools (means) for receiving requests to run a business process and sending back responses.
  • Tools for processing these incoming requests based on a set priority.
  • Tools for saving data about the progress of the request at different "checkpoints."
  • Tools for retrieving data from a checkpoint to restart or restore the business process.

USPTO and CAFC 2026 Dockets Search:

The legal status of US7669081 is "Active", and it is set to expire on 2028-01-27.

Regarding litigation, the Google Patents information for US7669081 indicates that the "Family has litigation" and shows several US cases filed in Delaware District Court in 2026. These include cases 1:26-cv-00466, 1:26-cv-00417, 1:26-cv-00397, and 1:26-cv-00392. These cases are sourced from the District Court via Unified Patents Litigation Data.

I could not find specific dockets for US7669081 at the CAFC for 2026 within the provided search results. While the Federal Circuit (CAFC) handles patent appeals, the specific litigation mentioned for US7669081 is at the District Court level in Delaware. Information from Darts-ip and Unified Patents indicates they track patent litigation globally, including CAFC cases, but no direct CAFC dockets for US7669081 in 2026 were explicitly found in the snippets.

Therefore, while litigation is ongoing for this patent in district court in 2026, specific dockets for the CAFC in 2026 related to US7669081 are not explicitly identified in the provided information.

The following litigation involving US patent 7669081 is known as of April 26, 2026:

1. Case Number: 1:26-cv-00392

   • Plaintiff(s): Hartford Fire Insurance Co.
   • Defendant(s): Intellectual Ventures I LLC, Intellectual Ventures II LLC, Callahan Cellular LLC, Zarbana Digital Fund, LLC, OL Security, LLC, and Cufer Asset LTD, LLC
   • Jurisdiction: U.S. District Court for the District of Delaware
   • Filing Date: April 7, 2026
   • Current Status: Open

2. Case Number: 1:26-cv-00417

   • Plaintiff(s): Munich Re America Services Inc.
   • Defendant(s): Intellectual Ventures (partial information available)
   • Jurisdiction: U.S. District Court for the District of Delaware
   • Filing Date: April 10, 2026
   • Current Status: Not explicitly stated as "Open," but presumed ongoing due to recent filing date.

3. Case Number: 1:26-cv-00397

   • Plaintiff(s): Travelers Indemnity Co.
   • Defendant(s): Intellectual Ventures I LLC
   • Jurisdiction: U.S. District Court for the District of Delaware
   • Filing Date: Not explicitly detailed in the provided snippets, but likely around April 2026 given similar case numbering in the same jurisdiction.
   • Current Status: No outcome explicitly stated.

4. Case Number: 1:26-cv-00466

   • Plaintiff(s): Information not explicitly detailed in the provided snippets.
   • Defendant(s): Information not explicitly detailed in the provided snippets.
   • Jurisdiction: U.S. District Court for the District of Delaware.
   • Filing Date: Information not explicitly detailed in the provided snippets, but likely around April 2026 given similar case numbering in the same jurisdiction.
   • Current Status: Information not explicitly detailed in the provided snippets.

These cases appear to be newly filed in April 2026 and involve US patent 7669081. The patent's current assignee, OL Security LLC, is listed as a defendant in at least one of these cases.

Proceedings overview

There is no PTAB activity on file for US Patent 7,669,081.

Strategic summary

As there are no PTAB proceedings on file for US Patent 7,669,081, all claims of the patent remain untested by AIA trial challenges. This means there is no established precedent from the PTAB regarding the patentability of its claims based on prior art or other statutory grounds.

The absence of PTAB activity could signify a few things. It might indicate that the patent has not been extensively asserted or licensed, as well-asserted patents often attract IPRs from accused infringers or defensive aggregators. Alternatively, it could suggest that prior art challenges against this specific patent have not been deemed strong enough to warrant an AIA trial, or that potential challengers have opted for other avenues, such as district court litigation.

Recommended next steps

If you are a defendant facing assertion of US Patent 7,669,081, the absence of PTAB activity means that all prior art grounds are still available for challenge. You could consider filing an Inter Partes Review (IPR) petition if a strong prior art challenge can be identified against the asserted claims. The lack of previous PTAB review implies that the patent has not been "hardened" by surviving such challenges, potentially offering a more favorable landscape for a new petitioner.

Inventors

• Richard Lett (Raytheon Co)
• Gregory Renno (Raytheon Co)
• Thomas Terwiel (Raytheon Co)

No unusual patterns observed regarding inventor departure from the original assignee.

Original assignee

Raytheon Co. (also identified as RAYTHEON COMPANY). Raytheon is a major U.S. defense contractor, and the patent describes a "Total Ship Computing Environment (TSCE)" developed for the U.S. Navy's DD(X) multi-mission destroyer, indicating they likely shipped products embodying the claims in a military context.
Current status: Operating (Raytheon Technologies, following a merger with United Technologies Corporation).

Assignment timeline

• 2006-09-28 (executed) / recorded 2006-09-28 — Reel 018698/0022

  • Conveyance: Assignment
  • Assignor: LETT, RICHARD; RENNO, GREGORY; TERWIEL, THOMAS
  • Assignee: RAYTHEON COMPANY
  • Correspondent: R. DENNIS CREWS, RAYTHEON COMPANY, 870 WINTER STREET, WALTHAM, MA 02451-1449.
  • Context: Original assignment from inventors to employer.

• 2012-10-12 (executed) / recorded 2012-10-12 — Reel 028972/0150

  • Conveyance: Assignment
  • Assignor: RAYTHEON COMPANY
  • Assignee: OL SECURITY LIMITED LIABILITY COMPANY
  • Correspondent: BARRY F. NOONAN, 107 WEST STREET, SUITE 400, C/O RAYTHEON COMPANY, ATTN: INTELLECTUAL PROPERTY, WALTHAM, MA 02451-1449.
  • Context: Transfer to asserter.

Timeline diagram

timeline
    title Ownership of US 7669081
    2006 : Assigned to Raytheon Co
    2010 : Issued
    2012 : Assigned to OL Security LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present. The patent was assigned from Raytheon Company, a major operating company, to "OL SECURITY LIMITED LIABILITY COMPANY". The name "OL SECURITY LIMITED LIABILITY COMPANY" with "LLC" suffix strongly suggests a licensing-only entity. Further, Unified Patents lists OL Security LLC as an NPE.
2. Known asserter in the chain — present. The current assignee, OL Security LLC, is identified as a Non-Practicing Entity (NPE) by Unified Patents.
3. Repeat correspondent across the chain — not present. Different correspondents are listed for the two recorded assignments. R. DENNIS CREWS for the initial assignment and BARRY F. NOONAN for the assignment to OL Security LLC.
4. Cascading transfers — not present. Only two assignments are recorded, separated by several years.
5. Pre-litigation transfer — unclear. While the transfer to OL Security LLC occurred in 2012, no specific litigation dates are immediately available in the provided text to determine if this transfer was within 6 months of the first suit. However, Google Patents notes "Family has litigation".
6. Bankruptcy fire-sale — not present. Raytheon Company is an operating company and no bankruptcy filing is indicated.
7. Privateering — unclear. There's no explicit information in the provided text or typical public records to definitively determine if Raytheon transferred the patent to OL Security LLC to assert on its behalf against competitors.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at any known defensive aggregator.

Verdict

NPE — high confidence. The patent was transferred from an operating company (Raytheon Co.) to an entity named "OL SECURITY LIMITED LIABILITY COMPANY", which is a strong indicator of a shell entity. This is further supported by OL Security LLC being identified as a known Non-Practicing Entity (NPE) by Unified Patents. The presence of these two strong signals points to an NPE assertion model.

USPTO Assignment Center: https://assignmentcenter.uspto.gov/patent/index.html (search for patent number 7669081).

The following prior art references are identified as relevant to US patent 7,669,081, based on citations within the patent itself. The analysis focuses on how these references potentially anticipate elements of US7669081, particularly its method claims as exemplified by Claim 1.

The core innovative aspects of US7669081, as summarized in its abstract and further detailed in its description, include:

• Application-level task scheduling with priority queues.
• The use of "checkpoints" (also referred to as processor functions) that include state data and governing rules.
• Rule-based determination of the next task and checkpoint in a process flow.
• Saving and updating checkpoint state data for recovery purposes.
• Recovery mechanisms for failed tasks/processes.

Here are some of the most relevant prior art references:

1. US6546401B1 - Methods and systems for performing a recoverable, persistent process

• Full Citation: US6546401B1, "Methods and systems for performing a recoverable, persistent process," invented by Michael T. Gering et al., assigned to Objectware, Inc., published April 8, 2003.
• Publication/Filing Date: Filed October 30, 2000; Published April 8, 2003.
• Brief Description: This patent describes methods and systems for executing a recoverable, persistent process. It involves dividing a process into a sequence of recoverable units, defining intermediate states for these units, and persisting data related to these states to allow recovery from failure. The system ensures that a process can resume from a last known good state, typically through a persistence mechanism.
• Potential Anticipation (35 U.S.C. § 102): This reference potentially anticipates elements of Claim 1 of US7669081, particularly steps (b), (e), (f), and (i), which relate to receiving checkpoints (recoverable units), creating and saving checkpoint state data, and updating this data. The concept of a "recoverable, persistent process" directly aligns with the checkpointing and recovery features of US7669081.

2. US6041355A - Method and apparatus for processing events and tasks in a transaction-oriented system

• Full Citation: US6041355A, "Method and apparatus for processing events and tasks in a transaction-oriented system," invented by Peter R. Broadbent et al., assigned to Tandem Computers Incorporated, published March 21, 2000.
• Publication/Filing Date: Filed December 18, 1996; Published March 21, 2000.
• Brief Description: This patent details a transaction-oriented system that processes events and tasks. It includes a task scheduler and a task dispatcher that manage tasks in a queue, allowing for concurrent processing. The system focuses on maintaining data consistency in a distributed environment through transactional integrity.
• Potential Anticipation (35 U.S.C. § 102): This reference potentially anticipates aspects of Claim 1 of US7669081, specifically steps (a) and (c) regarding receiving requests (events) and scheduling tasks into a queue for processing. While it focuses on transaction-oriented systems, the underlying mechanism of task processing and scheduling in queues presents similar foundational concepts.

3. US6854108B1 - Application checkpoint/restart for highly available systems

• Full Citation: US6854108B1, "Application checkpoint/restart for highly available systems," invented by Madhusudan T. Talluri et al., assigned to BEA Systems, Inc., published February 8, 2005.
• Publication/Filing Date: Filed May 2, 2002; Published February 8, 2005.
• Brief Description: This patent describes a system and method for providing application checkpoint/restart capabilities in highly available systems. It involves saving the state of an application at various points (checkpoints) to persistent storage, enabling the application to be restarted from a recent checkpoint in case of failure. The checkpoints allow for rollback and recovery of application execution.
• Potential Anticipation (35 U.S.C. § 102): This patent directly addresses "application checkpoint/restart," which is a central theme in US7669081. It potentially anticipates Claim 1, particularly steps (b), (e), (f), and (i) concerning the establishment, creation, saving, and updating of checkpoint state data for recovery. The emphasis on application-level recovery is particularly relevant.

4. US6718544B1 - Application-level system and method for recovering from application failures

• Full Citation: US6718544B1, "Application-level system and method for recovering from application failures," invented by Robert J. Collingbourne et al., assigned to Electronic Data Systems Corporation, published April 6, 2004.
• Publication/Filing Date: Filed October 31, 2000; Published April 6, 2004.
• Brief Description: This patent describes a system and method for recovering from application failures by maintaining and updating application state information. It enables an application to be restarted from a previous valid state, preventing loss of work. The recovery is handled at the application level, providing more granular control than traditional operating system-level recovery.
• Potential Anticipation (35 U.S.C. § 102): Similar to US6854108B1, this patent explicitly focuses on "application-level" recovery from failures, a key distinction highlighted by US7669081 over prior OS-level schedulers. It potentially anticipates Claim 1, specifically steps (b), (e), (f), and (i) by disclosing mechanisms for saving and using application state for recovery, and the underlying concept of structured recovery points.

5. US6877148B1 - Method and system for dynamically generating a process flow

• Full Citation: US6877148B1, "Method and system for dynamically generating a process flow," invented by David F. Hemsath et al., assigned to International Business Machines Corporation, published April 5, 2005.
• Publication/Filing Date: Filed June 28, 2001; Published April 5, 2005.
• Brief Description: This patent describes a method and system for dynamically generating a process flow based on user-defined rules. It allows for flexible and adaptive process execution where the sequence of steps can be determined at runtime based on various conditions.
• Potential Anticipation (35 U.S.C. § 102): This reference is relevant to US7669081's emphasis on rule-based execution flow. It potentially anticipates Claim 1, specifically steps (a), (d), and (h), which involve using scheduler rules and checkpoint rules to determine tasks to be scheduled and the next steps in the process. The "dynamically generating a process flow" based on rules aligns with the decision-making logic embedded in the rules of US7669081's checkpoints.

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.

Patent Term Adjustments (PTA) for US7669081

Patent Term Adjustment (PTA) extends the term of a U.S. patent to compensate for certain delays caused by the USPTO during the patent application's prosecution. The overall PTA calculation involves adding various delays by the USPTO and subtracting delays caused by the applicant.

The Google Patents page for US7669081 indicates that the "Legal status" is "Active, expires 2028-01-27". This adjusted expiration date implies that PTA has likely been applied to the patent. Without direct access to the patent's prosecution history (e.g., the Image File Wrapper in Patent Center), the specific details of any PTA calculation (e.g., the exact number of days added due to USPTO delays or subtracted due to applicant delays) cannot be determined from the provided information.

Key aspects of PTA relevant to this patent include:

• The original patent term is 20 years from the filing date of the non-provisional application.
• PTA applies to utility patent applications filed on or after May 29, 2000. US7669081 was filed on September 27, 2006, making it eligible for PTA.
• Delays by the USPTO that can lead to PTA include:
  • Failure to issue a first Official Action within 14 months of filing.
  • Failure to issue an action within four months of an applicant's response.
  • Failure to issue the patent within four months of payment of the issue fee.
  • Failure to issue a patent within three years of the actual filing date.
• Applicant delays can reduce any PTA.

The adjusted expiration date of January 27, 2028, for US7669081 suggests that a positive PTA was granted, extending its term beyond the typical 20 years from its September 27, 2006, filing date (which would have been September 27, 2026).

Patent Term Extensions (PTE) for US7669081

Patent Term Extension (PTE) is available for patents claiming certain human drug products, medical device products, animal drug products, veterinary biological products, and food or color additive products, to restore time lost during premarket government approval by a regulatory agency (e.g., FDA).

The description of US7669081 as a "Systems and methods for scheduling, processing, and monitoring tasks" for computer hardware and software, especially within military applications like the U.S. Navy's Total Ship Computing Environment (TSCE), does not align with the types of products eligible for PTE under 35 U.S.C. § 156. Therefore, it is highly unlikely that US7669081 has received or is eligible for Patent Term Extension.

Continuation Applications, Divisional Applications, and Related Family Members of US7669081

The Google Patents page provides information on "Other versions" and "Priority to US11/535,723".

• Application number: US11/535,723. This is the application number for US7669081 itself.
• Other versions: US20080120620A1. This is the published patent application corresponding to US7669081. This is a family member, specifically the pre-grant publication of the granted patent.
• Family has litigation: The Google Patents page also indicates "Family has litigation", and lists the priority to US11/535,723.

Based on the provided information, the following can be stated:

• Continuation Applications: The provided information does not explicitly list any continuation applications for US7669081. Continuation applications typically share the same priority date and specification but claim different subject matter.
• Divisional Applications: Similarly, no divisional applications are explicitly listed. Divisional applications arise when an application contains more than one independent and distinct invention, and the applicant elects to pursue one invention in the original application and others in divisional applications.
• Related Family Members:
  • US20080120620A1: This is the patent application publication associated with US7669081B2. It shares the same specification and priority date.

To definitively identify all continuation or divisional applications, a more in-depth search using patent databases (e.g., USPTO Patent Center with the application number US11/535,723) would typically be required to examine the "Continuity Data" section. However, based solely on the provided snippets, only the pre-grant publication is clearly identified as a related family member.

Projected Expiration Date for US7669081

The Google Patents page explicitly states the legal status as "Active, expires 2028-01-27". This is the projected expiration date, which already accounts for any Patent Term Adjustment (PTA) that may have been applied.

Therefore, the projected expiration date for US Patent 7669081 is January 27, 2028.

The USPTO search results confirm that US Patent 7,669,081 (US7669081B2) is an issued patent. The Google Patents link I used previously provided the full text, which aligns with the USPTO's public search capabilities. Therefore, I can proceed with the defensive disclosure based on the provided patent text, treating it as the authoritative source.

Now, I will construct the "Defensive Disclosure" document.# Defensive Disclosure Document for US Patent 7669081

Introduction

This document presents derivative variations and extensions of the technologies described in US Patent 7,669,081, "Systems and methods for scheduling, processing, and monitoring tasks." The purpose of this disclosure is to establish prior art, rendering potential future incremental improvements by competitors obvious or non-novel, thereby strengthening our defensive intellectual property position.

Combination Prior Art Scenarios with Open-Source Standards

The concepts presented in US7669081, such as application-level task scheduling, rule-based process flow, priority queues, checkpointing for recovery, and health monitoring, are readily combinable with established open-source standards to achieve a robust and scalable task management system. Such combinations would be obvious to a person having ordinary skill in the art (PHOSITA) seeking to implement fault-tolerant, dynamic application workflows.

1. US7669081 with Kubernetes for Containerized Workloads:

   • Scenario: A scheduler framework, as described in US7669081, is deployed within a Kubernetes cluster. Each "processor function" (referred to as a "checkpoint" in the patent) is implemented as a Kubernetes Pod or Deployment. The "task scheduler" (180 in FIG. 2) would leverage Kubernetes' native scheduling capabilities (e.g., node affinity, taints/tolerations, resource requests) for initial placement and dynamic scaling. The priority queues (128) for tasks would be implemented using a persistent message queue accessible by all pods. Checkpoint state data (e.g., TaskDataMap) would be stored in a Kubernetes-managed Persistent Volume Claim (PVC) or a distributed key-value store like etcd, ensuring recoverability across pod restarts or migrations. Kubernetes' readiness and liveness probes could supplement the patent's "health module" (118) for monitoring processor function health, triggering restarts or re-scheduling as per US7669081's recovery mechanisms (131). This integration would provide a highly available, self-healing application-level task processing system, where the patent's concepts manage the internal application flow within an elastic, containerized infrastructure.

2. US7669081 with Apache Kafka for Event-Driven Task Orchestration:

   • Scenario: The task scheduling and inter-processor function communication described in US7669081 are realized using Apache Kafka as a central event streaming platform. Incoming requests (Claim 1, step a) are published to a Kafka topic. The "task factory" (134) consumes these messages and transforms them into "tasks" (152), which are then routed to appropriate Kafka topics representing different "priority queues" (128A, 128B, 128C). Each "processor function" (129, or "checkpoint" 136) acts as a Kafka consumer group, processing tasks from its dedicated topic. The "checkpoint state data" (Claim 1, step e, f, i) is persisted to a Kafka compacted topic or an external datastore referenced by task messages, providing an immutable log of task progression for recovery (131). The "rules" (109, Claim 1, step h) governing the transition between processor functions are implemented as Kafka Streams or ksqlDB applications, dynamically producing messages to the next appropriate Kafka topic based on task completion status and metadata. This approach provides asynchronous, scalable, and fault-tolerant task processing, where Kafka's distributed log and stream processing capabilities underpin the patent's core scheduling and state management.

3. US7669081 with Prometheus for Advanced Health Monitoring and Alerting:

   • Scenario: The health monitoring capabilities of US7669081 (e.g., health module 118, polling threads for health) are enhanced and standardized using Prometheus. Each "task processor" (which manages a priority queue, processor function, and thread) and individual "processor function" (129/136) exposes metrics (e.g., task processing latency, queue depth, thread uptime, error rates) via an HTTP endpoint in the Prometheus exposition format. A Prometheus server scrapes these endpoints periodically. Alerting rules within Prometheus' Alertmanager are configured to detect "unhealthy" conditions, such as prolonged task processing times or repeated thread restarts, aligning with the patent's "unhealthy" task determination. These alerts can trigger automated recovery actions via webhooks, such as initiating the "recovery mechanism" (131) for a specific SCI (107) or dynamically adjusting the scheduling rules (109) to re-prioritize or re-route tasks to healthier processor functions. Grafana dashboards can then visualize the real-time operational health of the entire task scheduling framework, providing comprehensive insights into performance and potential issues.

Derivative Variations for Independent Claim 1 (Method for performing a process)

1. Operational Parameter Expansion: Hyper-Scale, Global Task Scheduling

• Enabling Description: This derivative expands the method to operate at a hyper-scale, globally distributed level across geosynchronous satellite networks, processing real-time telemetry data with sub-millisecond latency requirements.
  • (a) Receiving a request: Requests originate from distributed sensor arrays on remote platforms (e.g., deep-sea autonomous underwater vehicles, high-altitude drones, planetary surface rovers) via satellite uplinks, encapsulated as a Telemetry Processing Request (TPR) with a mission criticality level.
  • (b) Receiving plurality of checkpoints: Checkpoints correspond to specialized data processing units (DPUs) deployed across a global network of edge computing nodes and geosynchronous satellite transponders. Each DPU is containerized, comprising specific signal processing algorithms (e.g., FFT, Kalman filtering, image recognition) and dynamic resource allocation rules (checkpoint rule). Checkpoint state data includes current telemetry buffer, processing parameters, and DPU health status.
  • (c) Determining first task & (d) determining first checkpoint: A distributed consensus algorithm (e.g., Raft or Paxos) and an AI-driven global load balancer, acting as the scheduler rule, prioritize TPRs based on mission criticality, available DPU resources, network latency, and predicted processing load across the entire satellite-edge infrastructure. The AI model determines the optimal initial DPU/checkpoint location to minimize overall processing time.
  • (e) Creating & (f) saving checkpoint state data: Initial state data, including raw telemetry and processing directives, is encrypted and securely saved to a geographically replicated, fault-tolerant object storage system with erasure coding across multiple orbital assets.
  • (g) Processing first task: The selected DPU processes the telemetry, performing preliminary data reduction and feature extraction using specialized hardware accelerators (e.g., FPGAs, ASICs).
  • (h) Determining next task/checkpoint: The checkpoint rule (e.g., a rule embedded in the DPU's processing logic, or dynamically provided by a central mission control system) evaluates the processed telemetry and DPU status (e.g., detected anomalies, processing completeness). This rule directs the task to the next DPU for further analysis (e.g., anomaly detection DPU, trajectory prediction DPU) or to an archival storage checkpoint.
  • (i) Updating saved checkpoint data: Intermediate processed telemetry and DPU execution logs are asynchronously streamed and updated in the globally replicated object storage, with cryptographic hashes ensuring data integrity.
  • (j) Repeating: This process repeats, dynamically chaining DPUs, until a mission-specific condition is met (e.g., anomaly confirmed and reported, data archived, mission objective achieved) or a command is received to terminate the processing flow.

graph TD
    A[Telemetry Request (TPR) via Satellite] --> B{Distributed Consensus & AI Scheduler Rule}
    B --> C{Priority Queue (Global)}
    C --> D[Select Optimal DPU/Checkpoint (e.g., DPU_A)]
    D --> E[Create & Save Checkpoint State (Replicated Object Storage)]
    E --> F[Process Task at DPU_A (FPGA/ASIC)]
    F --> G{Evaluate Checkpoint Rule (DPU_A)}
    G -- "Next DPU ID" --> H[Update Checkpoint State]
    H --> I{Predetermined Condition Reached?}
    I -- No --> DPU_B[Select Next DPU/Checkpoint (e.g., DPU_B)]
    DPU_B --> F'([Process Task at DPU_B])
    I -- Yes --> J[Process End]

    subgraph Satellite-Edge Infrastructure
        D
        F
        G
        H
        DPU_B
        F'
    end
    subgraph Global Data Plane
        C
        E
        H
    end

2. Cross-Domain Application: Autonomous Vehicle Fleet Management

• Enabling Description: This derivative applies the task scheduling method to autonomous vehicle (AV) fleet management for logistics, incorporating dynamic route optimization and maintenance scheduling based on real-time sensor input.
  • (a) Receiving a request: A central Fleet Operations Center (FOC) receives a Logistics Mission Request (LMR) specifying a delivery schedule, cargo details, and origin/destination. Each LMR translates into a process with tasks like "Route Planning," "Vehicle Assignment," "Execution Monitoring," and "Maintenance Scheduling."
  • (b) Receiving plurality of checkpoints: Checkpoints correspond to specialized AV Management Services (AVMS) running on edge compute nodes or cloud infrastructure. Examples: RouteOptimizerService, VehicleAllocatorService, DiagnosticMonitoringService, MaintenanceSchedulerService. Each AVMS defines its checkpoint rule for processing and transition. Checkpoint state data includes current vehicle telemetry (GPS, sensor readings, fuel level, component wear), cargo manifest, and route segments.
  • (c) Determining first task & (d) determining first checkpoint: The FOC's scheduler rule (an AI-driven optimization engine) analyzes the LMR and current fleet status (vehicle availability, traffic, weather). It prioritizes tasks (e.g., critical cargo > standard cargo) and selects the initial AVMS (e.g., RouteOptimizerService) to begin processing the LMR.
  • (e) Creating & (f) saving checkpoint state data: The initial LMR parameters are stored as state data in a distributed, resilient database, tagged with a unique mission ID.
  • (g) Processing first task: The RouteOptimizerService calculates optimal routes, considering real-time traffic, road conditions, and vehicle capabilities.
  • (h) Determining next task/checkpoint: The checkpoint rule within RouteOptimizerService (e.g., "if route calculated, proceed to vehicle assignment") directs the task to the VehicleAllocatorService. Simultaneously, if vehicle diagnostics indicate an upcoming maintenance interval, a separate sub-task for MaintenanceSchedulerService might be triggered.
  • (i) Updating saved checkpoint data: The calculated route, assigned vehicle ID, and updated mission status are written back to the distributed database.
  • (j) Repeating: This loop continues. The DiagnosticMonitoringService continuously processes real-time sensor data from assigned AVs. If an anomaly is detected (e.g., tire pressure drop, engine warning), its checkpoint rule can dynamically interrupt the current route, re-prioritize the mission (e.g., "divert to nearest maintenance depot"), and trigger the MaintenanceSchedulerService while simultaneously alerting the FOC. The process concludes when the cargo is delivered, and the vehicle returns to a standby state, or maintenance is completed.

graph TD
    A[Logistics Mission Request (LMR)] --> B{AI-driven Fleet Scheduler Rule}
    B --> C{Priority Task Queue (FOC)}
    C --> D[Select RouteOptimizerService]
    D --> E[Create & Save Mission State (Distributed DB)]
    E --> F[Route Optimization Task]
    F --> G{RouteOptimizerService Rule}
    G -- "Calculated Route" --> H[Update Mission State]
    H --> I[Select VehicleAllocatorService]
    I --> J[Vehicle Assignment Task]
    J --> K{VehicleAllocatorService Rule}
    K -- "Assigned Vehicle" --> H
    H --> L[Select DiagnosticMonitoringService]
    L --> M[Real-time Telemetry Processing]
    M --> N{DiagnosticMonitoringService Rule}
    N -- "Healthy, Continue" --> O[Repeat (RouteMonitorService)]
    N -- "Anomaly Detected" --> P[Emergency Re-prioritize Mission]
    P --> Q[Select MaintenanceSchedulerService]
    Q --> R[Maintenance Scheduling Task]
    R --> S[Mission Completed/Recovered]
    O --> S
    S --> End[Process End]

3. Integration with Emerging Tech: AI-driven Predictive Scheduling, IoT & Blockchain

• Enabling Description: This derivative enhances the method by integrating AI for predictive scheduling, real-time feedback from IoT sensors for dynamic rule adjustment, and blockchain for immutable audit trails of task state transitions and checkpoint data.
  • (a) Receiving a request: A request is received via a distributed application programming interface (API) gateway, specifying a multi-stage manufacturing or asset lifecycle management process. Each request includes an expected Service Level Agreement (SLA).
  • (b) Receiving plurality of checkpoints: Checkpoints are realized as "Smart Contract-Controlled Processor Functions" (SC-PFs) on a private blockchain. Each SC-PF is a containerized microservice associated with specific IoT sensor data streams and a smart contract that defines its checkpoint rule. Checkpoint state data, including input parameters and output results, are immutably logged as transactions on the blockchain.
  • (c) Determining first task & (d) determining first checkpoint: An AI-powered Predictive Scheduler (AIPS), acting as the scheduler rule, analyzes incoming requests, historical performance data, current IoT sensor readings (e.g., machine utilization, ambient conditions), and real-time network congestion. The AIPS, using machine learning models, predicts potential bottlenecks and dynamically determines the optimal task prioritization and the initial SC-PF to begin the process to meet the SLA.
  • (e) Creating & (f) saving checkpoint state data: Initial task data and scheduling parameters are committed as an immutable transaction on the blockchain, forming the first checkpoint. This transaction includes a cryptographic hash of the initial data and references to relevant IoT sensor streams.
  • (g) Processing first task: The selected SC-PF executes its logic, potentially consuming external IoT data (e.g., temperature, pressure, machine status) from a secure data oracle. The execution result is packaged as a new task state.
  • (h) Determining next task/checkpoint: The checkpoint rule, embedded as a smart contract on the blockchain, is executed upon SC-PF completion. This rule dynamically adjusts based on the SC-PF's output, real-time IoT sensor data (e.g., detecting unexpected deviations), and the AIPS's updated predictions. It then triggers the next appropriate SC-PF via a blockchain transaction. This enables immediate adaptation to unforeseen operational conditions.
  • (i) Updating saved checkpoint data: The output data from the current SC-PF, along with its execution timestamp and cryptographic signature, is appended to the task's immutable audit trail on the blockchain, establishing a new checkpoint. This provides a verifiable, unalterable record of all state transitions.
  • (j) Repeating: This process iterates, with the AIPS continuously re-evaluating optimal paths, SC-PFs reacting to IoT inputs and smart contract rules enforcing transitions, until the process is completed or a predetermined condition (e.g., SLA breach, critical sensor anomaly, manual intervention) is met, resulting in a final blockchain transaction.

graph TD
    A[Distributed API Gateway Request (SLA)] --> B{AI Predictive Scheduler (AIPS)}
    B --> C{Priority Queue (AI-Optimized)}
    C --> D[Select Initial SC-PF (Smart Contract Processor Function)]
    D --> E[Commit Initial State to Blockchain (Checkpoint 1)]
    E --> F[Execute Task at SC-PF (uses IoT Data)]
    F --> G{Smart Contract Checkpoint Rule (on-chain)}
    G -- "Next SC-PF ID + Updated IoT" --> H[Commit Updated State to Blockchain (Checkpoint N)]
    H --> I{Predetermined Condition Met?}
    I -- No, Dynamic Adjustment --> B
    I -- Yes --> J[Process Complete (Blockchain Finality)]

    subgraph IoT Data Layer
        F -- "Real-time Sensor Feeds" --> G
    end
    subgraph Blockchain Network
        E
        G
        H
        J
    end

Derivative Variations for Independent Claim 19 (Method for processing a logical thread)

1. Material & Component Substitution: Bio-Molecular Computing for Protein Folding

• Enabling Description: This derivative describes a method for processing a logical thread using bio-molecular computing substrates, specifically for protein folding simulations, where "processor functions" are enzyme-catalyzed reactions and "tasks" are molecular states encoded in synthetic DNA strands.
  • (a) Dividing logical thread: The logical thread of simulating a complex protein's folding pathway is divided into discrete bio-chemical stages, each corresponding to a processor function (PF). Examples include HydrophobicCollapsePF, AlphaHelixFormationPF, BetaSheetFoldingPF.
  • (b) Modeling state as first task: The state of the protein folding simulation is modeled as a first task represented by a synthetic DNA nanostructure. This nanostructure's sequence and conformation (first task data and first task state) encode the partially folded protein's current three-dimensional coordinates and energy landscape.
  • (c) Adding first task to a queue: The synthetic DNA nanostructures are introduced into a microfluidic chamber, forming a queue of tasks based on their concentration or flow rate, where higher concentration or faster flow implies higher priority.
  • (d) Persisting first task in first checkpoint: Before enzymatic processing, a subset of the DNA nanostructures are physically isolated and optically scanned (e.g., using atomic force microscopy or cryo-electron microscopy) and sequenced, persisting their initial state in a digital checkpoint database.
  • (e) Selecting first processor function: A first rule (e.g., binding affinity rules for specific enzymes) dictates which first processor function (enzyme cocktail) will react with the DNA nanostructure based on its encoded state. For instance, a DNA sequence indicating an unstructured polypeptide might preferentially bind to enzymes facilitating hydrophobic collapse.
  • (f) Receiving first task and performing process: The selected enzyme cocktail (first processor function) chemically acts upon the synthetic DNA nanostructure, catalyzing a specific conformational change or binding event (first process) that mimics a stage of protein folding.
  • (g) Storing output data: The altered DNA nanostructure, now representing a new intermediate folded state, inherently stores the output data from the enzyme reaction.
  • (h) Persisting first task in second checkpoint: The modified DNA nanostructure is again isolated, scanned, and sequenced, persisting its new state in the digital checkpoint database.
  • (i) Selecting second processor function & (j) receiving first task: A second rule (another set of enzyme binding affinities, perhaps guided by real-time spectroscopic analysis of the nanostructure's state) determines the second processor function (next enzyme cocktail). The altered DNA nanostructure is then exposed to this second enzyme cocktail, with its new conformation and sequence acting as the input data for the subsequent folding step. This continues until a fully folded protein structure is achieved or a stable intermediate is reached.

graph TD
    A[Initial Unfolded DNA Nanostructure (Task)] --> B{Microfluidic Chamber (Task Queue)}
    B --> C[Isolate & Scan DNA (Checkpoint 1)]
    C --> D{Enzyme Binding Rule 1}
    D -- "Select HydrophobicCollapsePF" --> E[Hydrophobic Collapse (Enzyme Reaction)]
    E --> F[Modified DNA Nanostructure (Task State Updated)]
    F --> G[Isolate & Scan DNA (Checkpoint 2)]
    G --> H{Enzyme Binding Rule 2}
    H -- "Select AlphaHelixFormationPF" --> I[Alpha Helix Formation (Enzyme Reaction)]
    I --> J[Modified DNA Nanostructure (Task State Updated)]
    J --> K[Isolate & Scan DNA (Checkpoint 3)]
    K --> L{Folding Complete?}
    L -- No --> H'([Next Enzyme Binding Rule])
    L -- Yes --> M[Folded Protein Structure (Process Complete)]

2. Operational Parameter Expansion: High-Frequency Trading System with NVRAM Checkpoints

• Enabling Description: This derivative details the method for processing a logical thread in an extremely high-frequency trading (HFT) system, where each "processor function" represents a microsecond-latency market analysis or order routing step, with checkpointing to non-volatile RAM (NVRAM) for ultra-rapid recovery.
  • (a) Dividing logical thread: The logical thread of executing a trading strategy is divided into processor functions (PFs) with sub-microsecond execution budgets. Examples: MarketDataIngestPF, SignalGenerationPF, OrderDecisionPF, ExecutionRoutingPF.
  • (b) Modeling state as first task: The state of a trading opportunity is modeled as a first task, comprising real-time tick data, aggregated order book snapshots, current position, and strategy parameters (first task data and first task state), all held in a low-latency data structure within a shared memory segment.
  • (c) Adding first task to a queue: Tasks are added to a hardware-accelerated priority queue (e.g., using FPGA-based queuing logic) directly integrated with network interface cards, ensuring deterministic latency for urgent market events.
  • (d) Persisting first task in first checkpoint: Prior to processing by a PF, the core task data is written to a dedicated bank of non-volatile RAM (NVRAM) or Storage Class Memory (SCM) as a first checkpoint, ensuring persistence even during sudden power loss or system crash within nanoseconds.
  • (e) Selecting first processor function: A first rule, implemented in low-latency C++ or even FPGA logic, selects the first processor function (e.g., MarketDataIngestPF) based on the incoming task's type and urgency.
  • (f) Receiving first task and performing process: The MarketDataIngestPF receives the task and performs wire-speed deserialization and initial filtering of market data.
  • (g) Storing output data: The processed market data (e.g., normalized tick data, calculated moving averages) is directly updated within the first task data structure in shared memory.
  • (h) Persisting first task in second checkpoint: After MarketDataIngestPF completes, the updated task data in shared memory is persisted again to a different NVRAM/SCM bank or an updated region of the first bank as a second checkpoint, establishing a recoverable state for the next trading logic step.
  • (i) Selecting second processor function & (j) receiving first task: A second rule (e.g., "if market data ingested, proceed to signal generation") immediately directs the task to the SignalGenerationPF. This PF directly accesses the updated shared memory segment, utilizing the processed market data (output data from the first process) as its input data to derive trading signals (e.g., arbitrage opportunities, trend indications) with minimal latency.

sequenceDiagram
    participant HFT_NIC as HFT Network Interface Card (FPGA)
    participant HW_PQ as Hardware Priority Queue
    participant SCM as Storage Class Memory (NVRAM)
    participant MDI_PF as MarketDataIngestPF
    participant SG_PF as SignalGenerationPF
    participant OD_PF as OrderDecisionPF
    participant ER_PF as ExecutionRoutingPF

    HFT_NIC->>HW_PQ: Raw Market Data (Task)
    HW_PQ->>SCM: Persist Task (Checkpoint 1)
    HW_PQ->>MDI_PF: Select MDI_PF (Rule 1)
    MDI_PF->>MDI_PF: Process Raw Data
    MDI_PF->>SCM: Persist Updated Task (Checkpoint 2)
    MDI_PF->>SG_PF: Select SG_PF (Rule 2)
    SG_PF->>SG_PF: Generate Signals
    SG_PF->>SCM: Persist Updated Task (Checkpoint 3)
    SG_PF->>OD_PF: Select OD_PF (Rule 3)
    OD_PF->>OD_PF: Make Order Decision
    OD_PF->>SCM: Persist Updated Task (Checkpoint 4)
    OD_PF->>ER_PF: Select ER_PF (Rule 4)
    ER_PF->>ER_PF: Route Order
    ER_PF->>SCM: Persist Final Task (Checkpoint Final)

3. The "Inverse" or Failure Mode: Graceful Degradation for Critical Infrastructure Monitoring

• Enabling Description: This derivative describes a method for processing a logical thread with graceful degradation for critical infrastructure monitoring, where upon detection of partial system failure, non-essential processor functions are progressively offloaded to a designated "maintenance mode" processing cluster, preserving core monitoring capabilities.
  • (a) Dividing logical thread: The logical thread for monitoring critical infrastructure (e.g., a nuclear power plant, national electrical grid) is divided into processor functions (PFs) representing monitoring tiers: CriticalSensorPF (e.g., reactor core temperature, grid frequency), AncillarySensorPF (e.g., HVAC status, non-critical environmental readings), AlertGenerationPF, HistoricalLoggingPF.
  • (b) Modeling state as first task: Each sensor data packet or system event is modeled as a first task containing sensor ID, timestamp, reading, and criticality level (first task data and first task state).
  • (c) Adding first task to a queue: Tasks are added to a resilient, distributed priority queue, where CriticalSensorPF tasks are given highest priority.
  • (d) Persisting first task in first checkpoint: Initial sensor data is immediately persisted to a highly available, mirrored data store as a first checkpoint.
  • (e) Selecting first processor function: A first rule determines the appropriate first processor function based on the sensor's criticality: CriticalSensorPF for vital readings, AncillarySensorPF for others.
  • (f) Receiving first task and performing process: The selected PF processes the sensor data (e.g., validation, threshold checking).
  • (g) Storing output data: Processed data is stored in the first task object.
  • (h) Persisting first task in second checkpoint: The task with processed data is persisted again as a second checkpoint.
  • (i) Selecting second processor function & (j) receiving first task: A second rule directs CriticalSensorPF tasks to AlertGenerationPF immediately if thresholds are breached, and AncillarySensorPF tasks to HistoricalLoggingPF.
  • Graceful Degradation Mechanism: An additional, high-priority HealthMonitorPF continuously monitors the health of all PFs and underlying compute resources. If HealthMonitorPF detects resource contention or failure (e.g., high CPU utilization on the primary cluster), a specialized DegradationRule is activated. This rule modifies the scheduler rule for AncillarySensorPF and HistoricalLoggingPF tasks, causing them to be directed to a lower-priority, isolated "maintenance mode" processing cluster with reduced throughput. CriticalSensorPF and AlertGenerationPF tasks continue on the primary, now less burdened, cluster. This ensures essential monitoring and alerting persist even under severe system stress or partial failure, gracefully shedding non-critical workloads. The "maintenance mode" cluster might have its own RecoveryPF to eventually re-sync historical data with the primary system when resources recover.

stateDiagram-v2
    state NormalOperation {
        [*] --> IngestData : Normal
        IngestData --> ProcessCritical[Process Critical Sensor Data]
        IngestData --> ProcessAncillary[Process Ancillary Sensor Data]
        ProcessCritical --> GenerateAlerts[Generate Alerts]
        ProcessAncillary --> LogHistorical[Log Historical Data]
        LogHistorical --> [*]
        GenerateAlerts --> [*]
    }

    state DegradationMode {
        [*] --> IngestDataDegraded : Degraded
        IngestDataDegraded --> ProcessCriticalDegraded[Process Critical Sensor Data]
        IngestDataDegraded --> OffloadAncillary[Offload Ancillary Sensor Data]
        ProcessCriticalDegraded --> GenerateAlertsDegraded[Generate Alerts]
        OffloadAncillary --> LogHistoricalMaintenance[Log to Maintenance Cluster]
        GenerateAlertsDegraded --> [*]
        LogHistoricalMaintenance --> [*]
    }

    [*] --> HealthMonitor[Health Monitor]
    HealthMonitor --> DegradationRule{System Health Degrading?}
    DegradationRule -- Yes --> DegradationMode : Activate Degradation
    DegradationRule -- No --> NormalOperation : Maintain Normal
    DegradationMode --> RecoveryPF[Recovery Processor Function] : System Recovered
    RecoveryPF --> NormalOperation

Derivative Variations for Independent Claim 29 (Computerized system for executing a process)

1. Cross-Domain Application: Personalized Adaptive Learning Platform

• Enabling Description: This derivative applies the computerized system for executing a process to a personalized adaptive learning platform, where the system dynamically adjusts curriculum paths based on student performance (task state) and provides recovery for interrupted learning sessions.
  • Means for receiving requests: A Learning Management System (LMS) API gateway serves as the means to receive requests to execute a "Personalized Learning Journey" business process for a student. Requests include student ID, current course enrollment, and learning objectives.
  • Means for processing incoming requests in accordance with a predetermined priority method: A Learning Path Orchestrator (LPO) module processes these requests. It prioritizes student interactions (ee.g., exam submissions > video lectures) and allocates computational resources based on real-time student engagement and urgency (e.g., remedial intervention for struggling students given higher priority). The LPO dynamically assigns learning modules (tasks) to specific educational content processors.
  • Means for saving data relating to the state of processing of the incoming request at one or more checkpoints: A Learner State Repository (LSR), implemented as a distributed NoSQL database (e.g., Cassandra), serves as the means for saving data. Checkpoints are automatically created at the completion of each learning activity (e.g., video watched, quiz attempted, concept mastered). The checkpoint state data includes student progress, performance metrics, knowledge gaps identified, and the unique ID of the next recommended learning module.
  • Means for recovering data from a checkpoint, to restore the business process: A Session Recovery Engine (SRE) acts as the means for recovering data. If a student's session is unexpectedly terminated (e.g., browser crash, network outage) or if an adaptive algorithm needs to rollback a student to a previous state (e.g., due to poor performance on subsequent material), the SRE retrieves the latest checkpoint state data from the LSR. It then re-initializes the LPO, reinstating the student's learning journey at the exact point of the last saved checkpoint, presenting the appropriate content, and ensuring seamless continuation of the personalized learning process.

graph TD
    A[Student Interaction (LMS API)] --> B[Learning Path Orchestrator (LPO)]
    B --> C{Determine Priority & Next Module (LPO)}
    C --> D[Assign Learning Module (Task)]
    D --> E[Execute Learning Activity (Content Processor)]
    E --> F[Update Student Progress (Learner State Repository)]
    F --> G[Save Checkpoint Data (LSR)]
    G --> H{Activity Complete? / Checkpoint Rule}
    H -- Yes, Next Module --> C
    H -- No, Error/Rollback --> I[Session Recovery Engine (SRE)]
    I --> J[Retrieve Checkpoint from LSR]
    J --> B

2. Integration with Emerging Tech: DLT-based Supply Chain Verification System

• Enabling Description: This derivative integrates the computerized system with Distributed Ledger Technology (DLT) for supply chain verification, where "checkpoints" are immutable transaction records on a blockchain, and rules for processing requests are encoded in smart contracts.
  • Means for receiving requests: A secure API gateway connected to a permissioned blockchain (e.g., Hyperledger Fabric) serves as the means for receiving "Supply Chain Event Requests" (SCERs), such as material origin verification, production batch updates, or shipping status changes, from various supply chain participants (e.g., manufacturers, logistics providers, retailers).
  • Means for processing incoming requests in accordance with a predetermined priority method: A Smart Contract Orchestrator (SCO) module processes these SCERs. It utilizes a predetermined priority method defined by industry consortium rules (e.g., perishable goods updates > raw material receipt) to order the execution of corresponding smart contracts on the DLT. Requests are validated against pre-approved participant identities.
  • Means for saving data relating to the state of processing of the incoming request at one or more checkpoints: The underlying DLT itself (e.g., a blockchain ledger) acts as the means for saving data. Each validated and executed smart contract transaction becomes an immutable checkpoint on the ledger. The checkpoint state data includes the verifiable event data (e.g., lot number, origin timestamp, sensor readings during transit), cryptographic signatures of participants, and the hash of the previous state in the supply chain lineage.
  • Means for recovering data from a checkpoint, to restore the business process: A Ledger Query and Rollback Mechanism (LQRM) serves as the means for recovering data. In cases of dispute, audit, or identified erroneous transactions, the LQRM can query the DLT to retrieve any checkpoint (immutable transaction record). While the ledger itself cannot be "restored" in the traditional sense due to immutability, the LQRM can reconstruct the state of any specific item or batch at any point in time by replaying transactions from a selected checkpoint up to a desired state, or by identifying the last valid state before an error. This allows for transparent verification and enables subsequent corrective transactions to be initiated, effectively "restoring" the business process by establishing a new, correct state based on prior verified checkpoints.

classDiagram
    class SupplyChainEventRequest {
        +String eventID
        +String eventType
        +Map<String, String> payload
        +String participantID
        +String signature
    }

    class SmartContractOrchestrator {
        -PriorityQueue<SCER> requestQueue
        +processRequest(SCER request)
        -prioritizeRequest(SCER request)
    }

    class DistributedLedgerTechnology {
        -List<Transaction> ledger
        +commitTransaction(Transaction tx)
        +queryTransaction(String eventID)
        +retrieveCheckpoint(String blockHash)
    }

    class SmartContract {
        +evaluateRule(TransactionData data)
        +executeLogic(TransactionData data)
    }

    class LedgerQueryRollbackMechanism {
        +reconstructState(String itemID, String blockHash)
        +auditTrail(String itemID)
    }

    SupplyChainEventRequest --> SmartContractOrchestrator : receives
    SmartContractOrchestrator --> DistributedLedgerTechnology : commits transactions
    DistributedLedgerTechnology "1" -- "*" SmartContract : executes
    DistributedLedgerTechnology "1" -- "*" LedgerQueryRollbackMechanism : queries
    LedgerQueryRollbackMechanism --> SmartContractOrchestrator : initiates corrective actions

3. The "Inverse" or Failure Mode: Tamper-Evident "Dark Mode" Operation for Security Systems

• Enabling Description: This derivative describes a version of the system designed to fail safely by operating in a tamper-evident "dark mode" upon detection of a security breach, switching to a minimal-functionality, isolated state, logging all interactions to an immutable, off-grid storage medium for forensic analysis.
  • Means for receiving requests: A Cyber-Physical Security System (CPSS) receives "system interaction requests" (e.g., access control attempts, sensor alerts, administrative commands) from various network interfaces and physical sensors.
  • Means for processing incoming requests in accordance with a predetermined priority method: A Threat Detection and Response (TDR) engine processes these requests. It prioritizes requests based on threat severity (e.g., confirmed intrusion attempt > routine access). Under normal operation, the TDR routes requests to appropriate security modules (e.g., authentication, logging, alerting).
  • Means for saving data relating to the state of processing of the incoming request at one or more checkpoints: A Secure Event Log (SEL) acts as the means for saving data. Checkpoints are created for every critical system event or state change (e.g., successful login, failed authentication, sensor trigger). The checkpoint state data includes event timestamp, event type, affected components, user/entity ID, and cryptographic hashes of system configurations. The SEL is continuously replicated to a Write-Once, Read-Many (WORM) storage array.
  • Means for recovering data from a checkpoint, to restore the business process: A Forensic Analysis and Recovery (FAR) module typically provides recovery. However, in this "inverse" mode, its primary role shifts.
  • Tamper-Evident "Dark Mode" Trigger and Operation: An integral Intrusion Detection System (IDS) / Intrusion Prevention System (IPS) continuously monitors system integrity. Upon detection of a severe security breach (e.g., kernel-level compromise, exfiltration of sensitive data detected), the IDS/IPS, acting as a triggering condition, initiates a "dark mode" operation.
    1. Isolation: The TDR engine immediately deactivates all non-essential request processing pathways. Network interfaces are firewalled to permit only predefined forensic outbound communication.
    2. Minimal Functionality: The system enters a limited-functionality mode, where only core security functions (e.g., critical sensor monitoring, minimal authentication for emergency administrators, internal self-diagnostics) are permitted. All processing of incoming requests for normal operations is suspended or severely throttled.
    3. Enhanced Logging: All subsequent system interactions, including internal diagnostic outputs and any attempted external communications, are logged with maximum verbosity to a designated Off-Grid Immutable Storage (OGIS). This OGIS is a physically separate, air-gapped WORM device or a blockchain-secured log (if isolated from the compromised network) that functions as a specialized checkpoint for forensic purposes. Each log entry is cryptographically signed and timestamped.
    4. Forensic Checkpoints: The means for saving data (OGIS) explicitly creates new checkpoints for every action, forming an unalterable chain of evidence. The means for recovering data (FAR module) later uses these OGIS checkpoints to reconstruct the precise sequence of events leading to the breach and subsequent "dark mode" operation, enabling forensic analysis rather than traditional business process restoration. The goal is to preserve evidence, not restore normal operation.

stateDiagram-v2
    state NormalOperation {
        [*] --> ActiveMonitoring[Active Monitoring & Threat Detection]
        ActiveMonitoring --> ProcessRequests[Process Incoming Requests]
        ProcessRequests --> Authenticate[Authenticate/Authorize]
        Authenticate --> LogEvents[Log to Secure Event Log (WORM)]
        LogEvents --> Alerts[Generate Alerts if Needed]
        Alerts --> ActiveMonitoring
    }

    state DarkMode {
        [*] --> IsolatedNetwork[Network Isolation]
        IsolatedNetwork --> LimitedFunctionality[Minimal Critical Security Functions]
        LimitedFunctionality --> ForensicLogging[Log to Off-Grid Immutable Storage (OGIS)]
        ForensicLogging --> NotifyAuthorities[Secure Outbound Notification]
        NotifyAuthorities --> ForensicAnalysis[Initiate Forensic Analysis]
        ForensicAnalysis --> [*]
    }

    NormalOperation --> IDS_IPS_Trigger[IDS/IPS Detects Breach] : Threat Detected
    IDS_IPS_Trigger --> DarkMode : Activate Dark Mode