US 12143425

US patent 12143425, titled "Rapid predictive analysis of very large data sets using the distributed computational graph," was invented by Jason Crabtree and Andrew Sellers. The application was filed on July 21, 2024, and the patent was granted/issued on November 12, 2024. The current assignee is Qomplx Inc.

Abstract:
The patent describes a system for the predictive analysis of very large datasets using a distributed computational graph. It includes a data receipt software module for receiving streaming data from various sources. In a batch data pathway, a data formalization module formats the input data for storage. A batch event analysis server then inspects this stored data for trends, patterns, or knowledge, and aggregates the data for a message handler. In parallel, a streaming pathway utilizes a transformation pipeline software module to manipulate the data stream. A system sanity software module monitors system performance, receives status updates from the message handler, optimizes the system, and retrains the transformation pipeline based on insights from both streaming and batch analysis.

Plain-language overview of independent claims:

The patent describes both a system and a method for rapid predictive analysis of large datasets using a distributed computational graph.

Independent System Claim:
The system is designed for rapid predictive analysis of very large data sets. It comprises several software modules working together:

1. Data Receipt Module: Gathers incoming data streams from various sources.
2. Data Filter Module: Cleans the incoming data by removing incomplete, damaged, or incongruent records, then splits the clean data into two identical streams. One stream goes to data formalization, and the other to the transformation pipeline.
3. Data Formalization Module: Formats the data stream for consistent storage.
4. Input Event Data Store: Stores the formatted data for long-term access, retrieval, and analysis.
5. Batch Event Analysis Server: Analyzes the stored data for trends, historical events, or cause-and-effect relationships, summarizing these findings and interacting with the messaging module.
6. Transformation Pipeline Module: Processes the real-time data stream received from the filter, applying various functions and providing results back to the system, while also receiving directives for modification from the system sanity and retrain module.
7. Messaging Software Module: Acts as a central communication point, receiving administrative directives, summaries from batch analysis, and results from the transformation pipeline, and sends status and execution directives to the system sanity and retrain module.
8. System Sanity and Retrain Module: Monitors the system's stability and progress, comparing information against set parameters. It adjusts the operational behavior of other modules to maintain required function, issues alerts for degraded status, and implements administrative changes.
9. Output Module: Prepares and routes analyzed information to external destinations for further action.

Independent Method Claim:
The method for predictive analysis of large data sets involves the following steps:

1. Receive Streaming Input: Obtain continuous data from multiple sources.
2. Filter Data: Clean the received data by removing anything incomplete, misconfigured, or damaged.
3. Formalize Input Data: Standardize the format of the data for both batch processing (historical analysis) and streaming analysis.
4. Perform Data Transformations: Apply one or more functions to the formalized data.
5. Perform Sanity Checks and Retraining: Validate the results from the real-time transformation pipeline and adjust the analysis process based on findings from the batch analysis of historical data.
6. Output Results: Present the final analysis results in a predefined format.

As of April 26, 2026, no specific dockets for patent number 12143425 were found in the CAFC 2026 dockets.

As a patent attorney, I've searched for litigation related to US patent 12143425.

Based on the information available as of April 26, 2026, the Google Patents entry for US12143425B1 indicates that the "Family has litigation". Specifically, it notes:

• "First worldwide family litigation filed"
• "US case filed in Texas Western District Court" with case number "1:25-cv-01383"
• "US case filed in Texas Eastern District Court" with case number "2:25-cv-00913"

However, the provided search results do not include details on the plaintiffs, defendants, filing dates, or outcomes/current status for these cases. Additional information from a more comprehensive litigation database would be needed to provide a complete overview of these cases.

Proceedings overview

There is currently one AIA trial proceeding on file for US patent 12143425, which is IPR2026-00371. This proceeding is pending, offering a potential defensive avenue for a defendant.

IPR2026-00371 — Palo Alto Networks, Inc. v. Qomplx Inc.

• Type: Inter Partes Review
• Filed: 2026-05-26
• Status: Pending. The petition has been filed and is awaiting preliminary review by the PTAB.
• Judge panel: Not yet assigned or made public.
• Petition grounds: Not yet public.
• Institution decision: Not yet issued. The deadline for the institution decision is not yet known but typically falls within six months of the preliminary response or waiver thereof.
• Final Written Decision: Not yet issued.
• Settlement / termination: No settlement or termination has occurred as the proceeding is in its early stages.
• Appeal: Not applicable at this stage.
• Defensive value: This active IPR provides a potential challenge to the patentability of claims in US12143425. If instituted and successful, it could invalidate claims, weakening any assertion based on those claims. Conversely, if institution is denied or the patent owner prevails, it would strengthen the patent's validity.

Strategic summary

Currently, all claims of US patent 12143425 are UNTESTED by a final written decision from the PTAB. The single pending IPR (IPR2026-00371) initiated by Palo Alto Networks, Inc. is in its very early stages, meaning no claims have been canceled or sustained through an AIA trial proceeding.

Regarding the estoppel landscape, since there are no final written decisions, the estoppel provisions of § 315(e)(2) do not yet apply. This means that a defendant facing assertion of this patent still has all prior-art grounds available for challenging the patent's validity.

There are no apparent pattern signals such as multiple IPRs from the same petitioner or aggressive PTAB appeals by the patent owner at this time, given the single, recent filing.

Recommended next steps

For a defendant facing assertion of this patent, it is crucial to monitor the progress of IPR2026-00371. The key upcoming milestone will be the institution decision, which is typically due around six months from the patent owner's preliminary response (or waiver thereof). If the IPR is instituted, it will provide insights into the strength of the petitioner's prior art arguments and the PTAB's initial assessment of the claims' patentability.

If the IPR proceeds to a Final Written Decision, that decision will be publicly available on the USPTO PTAB Decisions website.

Inventors

The inventors named on US patent 12143425 are Jason Crabtree and Andrew Sellers. At the time of filing (priority date October 28, 2015, and application filing date July 21, 2024), the application was filed by Qomplx Inc., suggesting they were employed by or had assigned their rights to Qomplx Inc. or a related entity. There is no information to suggest unusual patterns regarding their departure from the original assignee within 12 months of filing.

Original assignee

The entity named as the current assignee on the issued patent US12143425 is Qomplx Inc., as indicated by the "Application filed by Qomplx Inc." event on July 21, 2024, and subsequent reassignment to QOMPLX LLC. Qomplx Inc. (and later QOMPLX LLC) appears to be an operating company in the field of cybersecurity and data analytics, which aligns with the patent's focus on "Rapid predictive analysis of very large data sets using the distributed computational graph." The subsequent reassignments suggest internal corporate restructuring or changes in legal entity names rather than a divestiture of assets to a separate licensing entity. QOMPLX LLC is the ultimate assignee in the described chain.

Assignment timeline

The provided patent information indicates the following assignment chain:

• 2024-07-21 (filed) / recorded 2024-07-21 — Reel N/A
  • Conveyance: Initial Assignment (implied by application filing)
  • Assignor: Jason Crabtree, Andrew Sellers (Inventors)
  • Assignee: Qomplx Inc.
  • Correspondent: Not available in provided patent text.
  • Context: Initial assignment from inventors to the company filing the patent application.
• 2024-08-06 (executed) / recorded 2024-08-06 — Reel N/A
  • Conveyance: Reassignment (ASSIGNMENT OF ASSIGNORS INTEREST)
  • Assignor: Jason Crabtree, Andrew Sellers
  • Assignee: Fractal Industries, Inc.
  • Correspondent: Not available in provided patent text.
  • Context: Transfer of inventor's interest to an initial corporate entity.
• 2024-08-19 (executed) / recorded 2024-08-19 — Reel N/A
  • Conveyance: Reassignment (ASSIGNMENT OF ASSIGNORS INTEREST)
  • Assignor: Fractal Industries, Inc.
  • Assignee: QOMPLX, INC.
  • Correspondent: Not available in provided patent text.
  • Context: Transfer of patent rights from an intermediate entity to QOMPLX, INC.
• 2024-08-20 (executed) / recorded 2024-08-20 — Reel N/A
  • Conveyance: Reassignment (ASSIGNMENT OF ASSIGNORS INTEREST)
  • Assignor: QOMPLX, INC.
  • Assignee: QPX LLC
  • Correspondent: Not available in provided patent text.
  • Context: Transfer from one corporate entity to another, likely an internal restructuring or renaming.
• 2024-09-18 (executed) / recorded 2024-09-18 — Reel N/A
  • Conveyance: Reassignment (CHANGE OF NAME)
  • Assignor: QPX LLC
  • Assignee: QOMPLX LLC
  • Correspondent: Not available in provided patent text.
  • Context: Official change of name for the assignee entity.

The provided patent text does not contain specific reel/frame numbers or correspondent information for these recorded assignments.

Timeline diagram

timeline
    title Ownership of US 12143425
    2024 : Filed by Qomplx Inc
         : Assigned to Fractal Industries
         : Assigned to QOMPLX INC
         : Assigned to QPX LLC
         : QPX LLC name changed to QOMPLX LLC
         : Patent granted

NPE / troll-pattern signals

1. Shell-entity transfer — Unclear. The entities like "Fractal Industries, Inc.", "QOMPLX, INC.", "QPX LLC", and "QOMPLX LLC" appear in quick succession. While "LLC" suffixes can indicate shell entities, the "CHANGE OF NAME" from QPX LLC to QOMPLX LLC suggests these might be related operating company entities undergoing internal restructuring or re-naming rather than transfers to dedicated licensing shells. Without information on their primary line of business, product shipment, or registered-agent addresses, it's difficult to confirm if they are shell entities.
2. Known asserter in the chain — Not present. None of the assignees (Fractal Industries, Inc., QOMPLX, INC., QPX LLC, QOMPLX LLC) match publicly known NPEs or high-frequency plaintiffs based on the provided data.
3. Repeat correspondent across the chain — Unclear. Correspondent information (attorney name, firm, address) is not provided in the patent text for any of the assignment records, so this signal cannot be assessed.
4. Cascading transfers — Present. There are multiple consecutive assignments within a very short period (August to September 2024). Specifically, from August 6, 2024 (inventors to Fractal) to August 19, 2024 (Fractal to QOMPLX, INC.), to August 20, 2024 (QOMPLX, INC. to QPX LLC), and then a name change on September 18, 2024 (QPX LLC to QOMPLX LLC). This rapid sequence of transfers, particularly before the patent was granted on November 12, 2024, could indicate internal restructuring or preparation for assertion.
5. Pre-litigation transfer — Unclear. The Google Patents record indicates litigation filed in the Texas Western District Court (1:25-cv-01383) and Texas Eastern District Court (2:25-cv-00913), both with case numbers suggesting a 2025 filing year. The assignments occurred in August-September 2024. This timing (assignments in late 2024, litigation in 2025) could potentially align with a pre-litigation transfer depending on the exact filing dates of the lawsuits, but the precise dates of litigation filing are not provided in the extract to confirm if they fall within 6 months after the last assignment.
6. Bankruptcy fire-sale — Not present. There is no indication in the patent text that the original assignee or any subsequent assignor filed for bankruptcy.
7. Privateering — Not present. There is no information in the patent text or the provided context that suggests an operating company transferred the patent to an NPE to assert on its behalf against competitors.
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

NPE — moderate confidence

The presence of cascading transfers in quick succession (August-September 2024) before patent issuance, combined with the lack of detailed information regarding the business activities of Fractal Industries, Inc., QPX LLC, and the specific nature of the litigation filings, raises moderate confidence of an NPE assertion pattern. While Qomplx Inc. and QOMPLX LLC appear to be operating companies, the rapid internal transfers involving different corporate names warrant closer scrutiny. The absence of correspondent information and detailed litigation dates prevents a higher confidence assessment.

USPTO Assignment Center Search: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 12143425, I need to access the full patent document from the USPTO database, which would list the "References Cited" by the examiner. Since I cannot directly access or browse the USPTO Patent Public Search database for the specific patent number and its cited references through my current tools, I cannot provide a detailed list of prior art citations with publication/filing dates, descriptions, and potentially anticipated claims under 35 U.S.C. § 102.

To perform this task, I would typically navigate to the USPTO Patent Public Search tool, enter the patent number "12143425", and then examine the "References Cited" section within the patent document. This section directly lists the prior art documents considered by the patent examiner during prosecution.

Once I could access that information, for each cited reference, I would:

• Extract the full citation (patent number, inventor, issue date, etc.).
• Note the publication or filing date as relevant for prior art determination (e.g., under 35 U.S.C. § 102).
• Read the abstract and, if necessary, relevant portions of the description and claims of the cited patent to formulate a brief description of its teachings.
• Compare the teachings of the prior art reference to the claims of US12143425 to identify which claims, if any, the prior art potentially anticipates. Anticipation under 35 U.S.C. § 102 requires that every element of the claimed invention is disclosed in a single prior art reference.

Obviousness Analysis (35 U.S.C. § 103) for US12143425

Legal Standard for Obviousness

Under 35 U.S.C. § 103, a patent for a claimed invention cannot be obtained if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art (PHOSITA) to which the claimed invention pertains. Obviousness is determined by considering:

1. The scope and content of the prior art.
2. The differences between the prior art and the claims at issue.
3. The level of ordinary skill in the pertinent art.
4. Secondary considerations of non-obviousness (e.g., commercial success, long-felt but unsolved needs, failure of others).

An obviousness rejection typically relies on disclosures that qualify as prior art under 35 U.S.C. § 102. For a combination of references to render a claim obvious, there must be some teaching, suggestion, or motivation in the prior art that would have led a PHOSITA to combine the references in the way claimed, with a reasonable expectation of success.

Identifying Prior Art for Obviousness Analysis

As stated in the "Prior Art" section, I cannot directly access the "References Cited" section of US patent 12143425 from the USPTO database with my current tools. Therefore, I cannot provide specific combinations of prior art references (e.g., Patent A, Publication B) that would render the claims obvious, nor can I explain the specific motivation to combine them.

The Google Patents entry for US12143425B1 does list "Prior art keywords" as "data," "transformation," "pipeline," "computer system," and "software instructions." While these keywords broadly describe the field, they do not constitute specific prior art references that can be analyzed for obviousness.

General Discussion of Potential Obviousness Arguments (Hypothetical)

Given the patent's focus on "rapid predictive analysis of very large data sets using the distributed computational graph" and "transformation pipelines," a hypothetical obviousness argument might involve combining existing technologies.

A PHOSITA in the field of data analytics, distributed computing, and machine learning, with knowledge of handling large datasets, would likely be aware of:

• Existing data pipeline architectures (linear): The patent itself notes that "Data pipelines... have all been linear in configuration which precludes their use for analysis and conclusion or action discovery in a majority of complex situations where branching or even recurrent modification is needed." This explicitly states that linear data pipelines were known prior art.
• Distributed computational graphs: The patent's title and description heavily rely on the concept of a "distributed computational graph." Such graph-based processing for large datasets, for instance, using frameworks like Apache Spark's Resilient Distributed Datasets (RDDs) or TensorFlow's computational graphs, were known or emerging technologies around the priority date of October 28, 2015.
• Batch processing and real-time streaming analysis: The combination of batch processing for historical context and real-time streaming for current data is a common architectural pattern in big data analytics.
• Self-optimizing and adaptive systems: Concepts of system monitoring, self-correction, and machine learning for optimizing operational behavior in software systems were also established.

Hypothetical Combinations and Motivation:

If specific prior art references (e.g., Patent X describing linear data pipelines in a distributed environment, and Publication Y detailing a graph-based computational model for large-scale data processing) were available, an obviousness argument might be constructed as follows:

1. Combining Linear Pipelines with Distributed Graph Processing: A PHOSITA would likely be motivated to apply distributed computational graph principles (from Publication Y) to existing linear data pipelines (from Patent X) to improve scalability and performance when dealing with "very large data sets." The distributed computational graph offers a more flexible and robust way to manage complex data flows and transformations.
2. Introducing Non-Linearities (Branching, Cyclical) to Data Pipelines: Once a distributed computational graph model is adopted for data pipelines, the motivation to move beyond purely linear configurations (as noted in the patent's background as a limitation of prior art) would be strong. A PHOSITA would recognize the benefits of branching (e.g., for parallel processing of different analyses on the same data) or cyclical structures (e.g., for iterative algorithms, feedback loops, or recurrent modifications) to handle more "complex situations where branching or even recurrent modification is needed." This would be a logical extension of using graph theory for data flow.
3. Integrating System Sanity and Retraining: Given the complexity of "very large data sets" and distributed systems, a PHOSITA would foresee the need for robust monitoring and adaptation. The integration of a "system sanity and retrain software module" to monitor, optimize, and retrain the data filter, formalization, batch analysis, and transformation pipeline (as described in US12143425) would be an obvious step to ensure system stability and improve the accuracy and efficiency of predictive analysis. The motivation would stem from the inherent challenges of managing large, dynamic data processing environments.

Without specific prior art references, however, this remains a conceptual discussion. To perform a thorough obviousness analysis, the "References Cited" from the patent document are essential.

Conclusion on Obviousness

Due to the inability to access the "References Cited" from the USPTO database for US12143425B1, a detailed obviousness analysis under 35 U.S.C. § 103 cannot be provided at this time. Such an analysis requires concrete prior art documents to identify specific combinations and articulate the motivation for a PHOSITA to combine them.

Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) is granted to compensate patent applicants for certain delays incurred by the USPTO during the prosecution of a utility or plant patent application. This adjustment adds time to the standard 20-year patent term from the earliest nonprovisional filing date. The USPTO automatically calculates PTA and provides this information to the applicant.

As of the current date, April 26, 2026, the specific amount of Patent Term Adjustment (PTA) for US patent 12143425 is not available in the provided information. This information is typically found in the issue notification letter sent by the USPTO after the issue fee is paid and before the patent issues, or on the patent document itself.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is a different mechanism from PTA, primarily designed for patents covering certain products (e.g., human drugs, medical devices, food additives) that require premarket regulatory approval from agencies like the FDA. The extension compensates for time lost during this regulatory review process.

There is no indication in the provided patent text or search results that US patent 12143425 is for a product that requires regulatory approval from agencies like the FDA. Therefore, it is highly unlikely to be eligible for Patent Term Extension (PTE).

Continuation and Divisional Applications

The patent text indicates a complex priority chain with numerous continuation-in-part (CIP) applications. A continuation application is a second application for the same invention claimed in a prior nonprovisional application and is filed before the patenting or abandonment of or termination of proceedings on the first application. A divisional application typically arises when a patent examiner requires restriction of an application to one of two or more independent and distinct inventions claimed in one application. The divisional application is then entitled to the benefit of the filing date of the original application. A CIP application includes new matter not present in the original application.

US patent 12143425 lists the following related applications in its cross-reference section, many of which are designated as "continuation-in-part" of others, indicating a complex family tree:

• This application is a continuation of U.S. patent application Ser. No. 18/581,375, filed Feb. 20, 2024.
• which is a continuation of U.S. patent application Ser. No. 17/189,161, filed Mar. 1, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 17/061,195, filed Oct. 1, 2020, now issued as U.S. Pat. No. 11,570,214 on Jan. 31, 2023.
• which is a continuation-in-part of U.S. patent application Ser. No. 17/035,029, filed Sep. 28, 2020, now issued as U.S. Pat. No. 11,546,380 on Jan. 3, 2023.
• which is a continuation-in-part of U.S. patent application Ser. No. 17/008,276, filed Aug. 31, 2020, now issued as U.S. Pat. No. 11,323,484 on May 3, 2022.
• which is a continuation-in-part of U.S. patent application Ser. No. 17/000,504, filed Aug. 24, 2020, now issued as U.S. Pat. No. 11,477,245 on Oct. 18, 2022.
• which is a continuation-in-part of U.S. patent application Ser. No. 16/855,724, filed on Apr. 22, 2020, now issued as U.S. Pat. No. 11,218,510 on Jan. 4, 2022.
• which is a continuation-in-part of U.S. patent application Ser. No. 16/836,717, filed on Mar. 31, 2020, now issued as U.S. Pat. No. 10,917,428 on Feb. 9, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/887,496, filed Feb. 2, 2018, now issued as U.S. Pat. No. 10,783,241 on Sep. 22, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/823,285, filed Nov. 27, 2017, now issued as U.S. Pat. No. 10,740,096 on Aug. 11, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/788,718, filed Oct. 19, 2017, now issued as U.S. Pat. No. 10,861,014 on Dec. 8, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/788,002, filed on Oct. 19, 2017.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/787,601, filed on Oct. 18, 2017, now issued as U.S. Pat. No. 10,860,660 on Dec. 8, 2020.
• which claims the benefit of U.S. Provisional Pat. App. No. 62/568,312, filed on Oct. 4, 2017.
• said application Ser. No. 15/787,601 is a continuation-in-part of U.S. patent application Ser. No. 15/616,427, filed on Jun. 7, 2017.
• which is a continuation-in-part of U.S. patent application Ser. No. 14/925,974 (explicitly incorporated by reference in its entirety herein), filed Oct. 28, 2015.
• said application Ser. No. 15/788,002 claims the benefit of U.S. Provisional Pat. App. No. 62/568,305, filed Oct. 4, 2017.
• said application Ser. No. 15/788,718 claims the benefit of U.S. Provisional Pat. App. No. 62/568,307, filed Oct. 4, 2017.
• said application Ser. No. 15/887,496 is a continuation-in-part of U.S. patent application Ser. No. 15/818,733, filed Nov. 20, 2017, now issued as U.S. Pat. No. 10,673,887 on Jun. 2, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/725,274, filed Oct. 4, 2017, now issued as U.S. Pat. No. 10,609,079 on Mar. 31, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/655,113, filed Jul. 20, 2017, now issued as U.S. Pat. No. 10,735,456 on Aug. 4, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/616,427, filed Jun. 7, 2017.
• said application Ser. No. 15/655,113 is a continuation-in-part of U.S. patent application Ser. No. 15/237,625, filed Aug. 15, 2016, now issued as U.S. Pat. No. 10,248,910 on Apr. 2, 2019.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/206,195, filed Jul. 8, 2016.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/186,453, filed Jun. 18, 2016.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/166,158, filed May 26, 2016.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/141,752, filed Apr. 28, 2016, now issued as U.S. Pat. No. 10,860,962 on Dec. 8, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/091,563, filed Apr. 5, 2016, now issued as U.S. Pat. No. 10,204,147 on Feb. 12, 2019.
• said application Ser. No. 15/141,752 is a continuation-in-part of U.S. patent application Ser. No. 14/986,536, filed Dec. 31, 2015, now issued as U.S. Pat. No. 10,210,255 on Feb. 19, 2019.
• said application Ser. No. 15/141,752 is a continuation-in-part of U.S. patent application Ser. No. 14/925,974, filed Oct. 28, 2015.
• said application Ser. No. 16/855,724 is a continuation-in-part of U.S. patent application Ser. No. 16/777,270, filed Jan. 30, 2020, now issued as U.S. Pat. No. 11,025,674 on Jun. 1, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 16/720,383, filed Dec. 19, 2019, now issued as U.S. Pat. No. 10,944,795 on Mar. 9, 2021.
• which is a continuation of U.S. patent application Ser. No. 15/823,363, filed Nov. 27, 2017, now issued as U.S. Pat. No. 10,560,483 on Feb. 11, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/725,274, filed Oct. 4, 2017, now issued as U.S. Pat. No. 10,609,079 on Mar. 31, 2020.
• said application Ser. No. 17/000,504 is a continuation-in-part of U.S. patent application Ser. No. 16/412,340, filed May 14, 2019, now issued as U.S. Pat. No. 11,539,663 on Dec. 27, 2022.
• which is a continuation-in-part of U.S. patent application Ser. No. 16/267,893, filed Feb. 5, 2019.
• which is a continuation-in-part of U.S. patent application Ser. No. 16/248,133, filed Jan. 15, 2019.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/849,901, filed Dec. 21, 2017, now issued as U.S. Pat. No. 11,023,284 on Jun. 1, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/835,436, filed Dec. 17, 2017, now issued as U.S. Pat. No. 10,572,828 on Feb. 5, 2020.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/790,457, filed Oct. 23, 2017, now issued as U.S. Pat. No. 10,884,999 on Jan. 5, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/790,327, filed on Oct. 23, 2017, now issued as U.S. Pat. No. 10,860,951 on Dec. 8, 2020.
• which claims the benefit of U.S. Provisional Pat. App. No. 62/568,291, filed Oct. 4, 2017.
• said application Ser. No. 15/790,327 is a continuation-in-part of U.S. patent application Ser. No. 15/616,427, filed Jun. 7, 2017.
• said application Ser. No. 15/790,327 is a continuation-in-part of U.S. patent application Ser. No. 15/141,752, filed Apr. 28, 2016, now issued as U.S. Pat. No. 10,860,962 on Dec. 8, 2020.
• said application Ser. No. 15/790,457 claims the benefit of U.S. Provisional Pat. App. No. 62/568,298, filed Oct. 4, 2017.
• said application Ser. No. 15/849,901 is a continuation-in-part of U.S. patent application Ser. No. 15/835,312, filed Dec. 7, 2017, now issued as U.S. Pat. No. 11,055,451 on Jul. 6, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/186,453, filed Jun. 18, 2016.
• said application Ser. No. 16/248,133 is a continuation-in-part of U.S. patent application Ser. No. 15/813,097, filed Nov. 14, 2017.
• which is a continuation-in-part of Ser. No. 15/616,427, filed Jun. 7, 2017.
• said application Ser. No. 16/248,133 is a continuation-in-part of U.S. patent application Ser. No. 15/806,697, filed Nov. 8, 2017.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/376,657, filed Dec. 13, 2016, now issued as U.S. Pat. No. 10,402,906 on Sep. 3, 2019.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/237,625, filed Aug. 15, 2016, now issued as U.S. Pat. No. 10,248,910 on Apr. 2, 2019.
• said application Ser. No. 15/806,697 is a continuation-in-part of U.S. patent application Ser. No. 15/343,209, filed Nov. 4, 2016, now issued as U.S. Pat. No. 11,087,403 on Aug. 10, 2021.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/237,625, filed Aug. 15, 2016, now issued as U.S. Pat. No. 10,248,910 on Apr. 2, 2019.
• said application Ser. No. 15/343,209 is a continuation-in-part of U.S. patent application Ser. No. 15/229,476, filed Aug. 5, 2016, now issued as U.S. Pat. No. 10,454,791 on Oct. 22, 2019.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/206,195, filed Jul. 8, 2016.
• said application Ser. No. 16/248,133 is a continuation-in-part of U.S. patent application Ser. No. 15/673,368, filed Aug. 9, 2017.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/376,657, filed Dec. 13, 2016, now issued as U.S. Pat. No. 10,402,906 on Sep. 3, 2019.
• said application Ser. No. 17/061,195 is a continuation-in-part of U.S. patent application Ser. No. 15/879,801, filed Jan. 25, 2018.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/379,899, filed Dec. 15, 2016.
• which is a continuation-in-part of U.S. patent application Ser. No. 15/376,657, filed Dec. 13, 2016, now issued as U.S. Pat. No. 10,402,906 on Sep. 3, 2019.
• said application Ser. No. 17/189,161 is a continuation-in-part of U.S. patent application Ser. No. 16/709,598, filed Dec. 10, 2019, now issued as U.S. Pat. No. 11,507,858 on Nov. 22, 2022.
• which is a continuation-in-part of U.S. patent application Ser. No. 14/925,974, filed Oct. 28, 2015.

The ultimate parent application with the earliest priority date appears to be U.S. patent application Ser. No. 14/925,974, filed October 28, 2015.

Related Family Members

The extensive list of continuation-in-part applications detailed above represents numerous related family members. All of these applications share a common priority chain back to U.S. patent application Ser. No. 14/925,974, filed October 28, 2015. Each of the applications that have issued as patents (e.g., U.S. Pat. No. 11,570,214, U.S. Pat. No. 11,546,380, U.S. Pat. No. 11,323,484, etc.) are also considered family members.

Additionally, the Google Patents information shows another published version:

• US20240396943A1 (publication date 2024-11-28)

Projected Expiration Date

The standard patent term for utility patents in the United States is 20 years from the earliest claimed non-provisional filing date. The earliest priority date for US patent 12143425 is October 28, 2015, from U.S. patent application Ser. No. 14/925,974.

Therefore, without any Patent Term Adjustment (PTA) or Patent Term Extension (PTE), the anticipated expiration date would be October 28, 2035.

The Google Patents entry also lists "2035-10-28 Anticipated expiration".

Any PTA would be added to this date. However, as noted, the specific PTA for US12143425 is not available in the provided information.

Defensive Disclosure Document for US Patent 12143425

Introduction

This Defensive Disclosure document is generated in response to US Patent 12143425, titled "Rapid predictive analysis of very large data sets using the distributed computational graph." The purpose of this document is to establish prior art by describing numerous derivative variations of the claimed invention. These detailed technical disclosures are intended to render future incremental improvements or alternative implementations by competitors "obvious" or "non-novel" under 35 U.S.C. § 102 and § 103, by demonstrating a wide array of foreseeable modifications, integrations, and applications across various technological and industrial contexts. This document aims to broaden the public domain knowledge surrounding the core concepts of distributed computational graphs, adaptive data processing pipelines, and integrated batch/streaming analysis.

---

Derivative Variations (for Independent System Claim)

The independent system claim describes a system comprising:

1. Data Receipt Software Module
2. Data Filter Software Module
3. Data Formalization Software Module
4. Input Event Data Store Module
5. Batch Event Analysis Server
6. Transformation Pipeline Software Module
7. Messaging Software Module
8. System Sanity and Retrain Software Module
9. Output Software Module

For clarity and to address the various axes effectively, derivatives are grouped by the functional layers of the system.

---

A. Input Processing Layer (Data Receipt, Data Filter, Data Formalization Modules)

1. Material & Component Substitution

• Derivative A1.1: Hardware-Accelerated Pre-processing Unit for Filtering and Formalization

  Enabling Description: This derivative implements the Data Filter and Data Formalization modules (520, 530 as per FIG. 5) as a dedicated hardware acceleration unit, specifically a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). The FPGA/ASIC is programmed to execute data parsing, validation (e.g., CRC checks, schema enforcement), and reformatting logic directly in hardware. This bypasses traditional software-based processing overhead, significantly reducing latency and increasing throughput for high-volume data streams (e.g., 100+ Gbps network ingress). The FPGA/ASIC interfaces directly with the network interface cards (NICs 110/413) to intercept raw data packets, perform wire-speed filtering (e.g., based on predefined byte patterns, header fields), and then formalize the payload into structured records before buffering them into high-speed local memory (101) for further processing by the software-based transformation pipeline or data store. Customizable logic blocks within the FPGA allow for dynamic updates to filtering rules and formalization schemas, triggered by directives from the System Sanity and Retrain Module (563), without requiring a full hardware redesign.

  flowchart TD
      A[Raw Data Stream Input] --> B(Network Interface Card)
      B --> C{FPGA/ASIC Pre-processing Unit}
      C -- Filter Logic (Hardware) --> D{Filtered Data Stream}
      D -- Formalization Logic (Hardware) --> E[Formalized Data Records]
      E --> F[High-Speed Local Memory Buffer]
      F --> G[Software Data Pipeline / Data Store]
      H[System Sanity & Retrain Module] -- Update Filter/Formalization Logic --> C
  

2. Operational Parameter Expansion

• Derivative A2.1: Extreme-Scale IoT Sensor Data Ingestion System

  Enabling Description: This derivative scales the Input Processing Layer to handle petabytes per second (Pbps) of streaming data from millions of geographically distributed IoT edge devices. The Data Receipt module (510) employs a distributed mesh network of edge gateways utilizing low-power wide-area network (LPWAN) protocols (e.g., LoRaWAN, NB-IoT) for data collection, aggregating inputs from individual sensors. These edge gateways perform preliminary aggregation and time-stamping before transmitting data bursts via secure, encrypted channels (e.g., TLS over MQTT) to regional ingestion clusters. The Data Filter and Formalization modules in these clusters are instantiated as auto-scaling microservices on a Kubernetes platform, dynamically adjusting computational resources (CPU, memory, GPU for tensor processing units if sensor data involves signal processing) based on real-time data ingress rates. Data formalization includes standardized Protobuf schemas for efficient serialization and deserialization across the distributed system, with embedded metadata for origin, sensor type, and trustworthiness.

  graph TD
      A[Millions of IoT Sensors] --> B(Edge Gateways)
      B -- LPWAN/MQTT --> C{Regional Ingestion Clusters}
      C -- Data Receipt Microservice --> D{Data Filter Microservice (Kubernetes Pod)}
      D -- Auto-scaled --> E{Data Formalization Microservice (Kubernetes Pod)}
      E --> F[Distributed Data Stream Processors]
      F -- Configurable Rate Limiting --> G[Transformation Pipeline / Data Store]
  

3. Cross-Domain Application

• Derivative A3.1: Real-time Threat Intelligence Ingestion for Cybersecurity Operations Centers (SOCs)

  Enabling Description: In a Cybersecurity SOC, the Input Processing Layer receives diverse threat intelligence feeds (e.g., STIX/TAXII, OpenIOC, commercial vendor APIs, honeypot telemetry, dark web monitoring) from various sources (511, 514). The Data Receipt module is configured to ingest these feeds via different protocols (HTTPS, SFTP, proprietary APIs). The Data Filter module is specialized to identify and remove irrelevant or noisy indicators of compromise (IOCs), malformed intelligence reports, duplicate entries, and data violating local privacy policies. For instance, it might filter out IP addresses known to belong to internal networks or benign entities. The Data Formalization module then transforms these disparate intelligence formats into a unified, normalized security event schema (e.g., Elastic Common Schema or proprietary JSON schema), enriching the data with geo-location, threat actor profiling (if available), and confidence scores based on source reputation. This formalized threat intelligence then feeds into a real-time correlation engine (Transformation Pipeline) for immediate alert generation or a long-term threat intelligence platform (Input Event Data Store) for historical analysis.

  flowchart TD
      A[STIX/TAXII Feeds] --> DR(Data Receipt Module)
      B[Honeypot Telemetry] --> DR
      C[Commercial Threat APIs] --> DR
      DR --> DF{Data Filter Module (Cybersecurity)}
      DF -- Filtered IOCs, Reports --> DFZ{Data Formalization Module (Security Schema)}
      DFZ -- Normalized Threat Events --> TP[Transformation Pipeline (Real-time Correlation)]
      DFZ --> IEDS[Input Event Data Store (Threat Intel DB)]
  

4. Integration with Emerging Tech

• Derivative A4.1: AI-Driven Adaptive Filtering with Reinforcement Learning

  Enabling Description: This derivative enhances the Data Filter Module (520) with an integrated AI-driven adaptive filtering agent. This agent utilizes reinforcement learning (RL) to continuously optimize filtering parameters based on feedback signals from downstream analysis. The feedback signals could include the rate of false positives/negatives generated by the predictive models in the Transformation Pipeline, the computational load on the system, or the relevance scores of processed data as determined by human analysts interacting with the Output Module (590). The RL agent, running as a dedicated microservice, observes the system state (e.g., input data characteristics, processing load, analysis outcomes), takes actions (e.g., adjusts filtering thresholds, activates/deactivates specific filter rules, modifies sampling rates), and receives rewards (e.g., improved prediction accuracy, reduced processing latency, decreased resource consumption). The System Sanity and Retrain Module (563) oversees the RL agent, providing administrative directives and ensuring stability during learning and deployment of new filter policies.

  graph TD
      A[Raw Data Stream] --> DR(Data Receipt Module)
      DR --> DF{Data Filter Module}
      DF -- Filtered Data --> TP[Transformation Pipeline]
      TP -- Analysis Results --> OM(Output Module)
      OM -- Human Feedback/Metrics --> RL[Reinforcement Learning Agent]
      RL -- Action (Adjust Filter Params) --> DF
      DF -- Filtered Data Characteristics --> RL
      SARM[System Sanity & Retrain Module] -- RL Policy Management --> RL
  

5. The "Inverse" or Failure Mode

• Derivative A5.1: Graceful Degradation to Local Edge Processing with Limited Functionality

  Enabling Description: In this "inverse" mode, when the central distributed computational graph system experiences critical failures (e.g., network partition, major cluster outage, resource exhaustion), the Input Processing Layer gracefully degrades to a local edge processing mode. Edge devices and local gateways are equipped with a "survival mode" Data Filter and Data Formalization software. Instead of streaming all raw data to the central system, these edge components perform essential, pre-configured filtering (e.g., anomaly detection thresholds, critical event identification) and rudimentary formalization locally. Only critical alerts or highly compressed summary data are buffered and stored on local non-volatile memory or transmitted via alternative, resilient communication channels (e.g., satellite, mesh radio) when available. This ensures continuous, albeit limited, operational awareness and immediate response capability at the data source, preventing complete data loss or operational blackout during central system unavailability. Once the central system recovers, buffered local data is backfilled, and full streaming operations resume.

  stateDiagram
      state NormalOperation {
          DR_Normal: Data Receipt (Central)
          DF_Normal: Data Filter (Central)
          DFZ_Normal: Data Formalization (Central)
          DR_Normal --> DF_Normal
          DF_Normal --> DFZ_Normal
          DFZ_Normal --> CentralSystem
          CentralSystem --> DR_Normal : Continue
      }
      state DegradedOperation {
          DR_Edge: Data Receipt (Edge)
          DF_Edge: Data Filter (Edge, Limited)
          DFZ_Edge: Data Formalization (Edge, Limited)
          DR_Edge --> DF_Edge
          DF_Edge --> DFZ_Edge
          DFZ_Edge --> LocalStorage[Local Event Buffer]
          DFZ_Edge --> AltComm[Alternate Communication (Summary/Alerts)]
      }
      NormalOperation --> DegradedOperation: CentralSystem_Failure
      DegradedOperation --> NormalOperation: CentralSystem_Recovery
  

---

B. Transformation Pipeline Software Module (Streaming Analysis Core)

1. Material & Component Substitution

• Derivative B1.1: Quantum-Accelerated Transformation Nodes for NP-Hard Problems

  Enabling Description: For specific computationally intensive transformations within the Transformation Pipeline (561), this derivative proposes the substitution of classical computing resources with quantum processing units (QPUs) or quantum-inspired annealing hardware. This is particularly relevant for transformations involving NP-hard optimization problems, complex pattern matching over vast feature spaces, or Monte Carlo simulations that would otherwise be intractable on classical hardware. A specialized "Quantum Proxy" transformation node acts as an interface, converting classical input data into a quantum-computable format (e.g., qubit states, Ising model representation), offloading the computation to an attached QPU via a quantum API (e.g., Qiskit, Cirq). Once the quantum computation yields a result, the Quantum Proxy translates it back into a classical data stream for subsequent transformations. This allows the distributed computational graph to leverage the unique strengths of quantum computation for discrete, highly complex steps.

  flowchart LR
      A[Data Filter Output] --> TP1(Transformation Node 1)
      TP1 --> QP_Node{Quantum Proxy Node}
      QP_Node -- Convert & Send --> QPU[Quantum Processing Unit]
      QPU -- Process Result --> QP_Node
      QP_Node -- Convert & Send --> TP2(Transformation Node 2)
      TP2 --> E[Messaging Module]
  

2. Operational Parameter Expansion

• Derivative B2.1: Hyper-Temporal Granularity Processing for Event-Stream Causality

  Enabling Description: This derivative expands the operational parameters of the Transformation Pipeline (561) to support hyper-temporal granularity, processing events with nanosecond (ns) or even picosecond (ps) resolution for precise causality analysis. This requires specialized time-synchronization protocols (e.g., PTP - Precision Time Protocol IEEE 1588) across all distributed nodes and highly optimized event-queuing mechanisms that maintain strict temporal ordering. Each transformation node is designed with a time-aware processing window that can ingest events based on event-time (not processing-time), handling out-of-order and late-arriving data deterministically. This enables the detection of subtle, high-frequency causal relationships between data points, crucial for applications like network intrusion detection at hardware speeds or particle physics data analysis. The messaging software module (562) and system sanity/retrain module (563) are augmented to monitor and adjust for potential temporal drifts and ensure strict adherence to event-time processing guarantees.

  sequenceDiagram
      participant Sensor
      participant TP_Node_1 as Transformation Node 1 (Time-Aware)
      participant TP_Node_2 as Transformation Node 2 (Time-Aware)
      participant Messaging as Messaging Module
      Sensor->>TP_Node_1: Event A (Timestamp T1)
      Sensor->>TP_Node_1: Event B (Timestamp T1 + 5ns)
      TP_Node_1->>TP_Node_2: Processed Event A' (T1, T1+N)
      Sensor->>TP_Node_1: Event C (Timestamp T1 + 2ns, Late)
      TP_Node_1->>TP_Node_2: Processed Event C' (T1+2ns, T1+M)
      TP_Node_2->>Messaging: Causal Result (A', C', B')
      Note right of Messaging: Strict Event-Time Ordering Maintained
  

3. Cross-Domain Application

• Derivative B3.1: Real-time Dynamic Route Optimization in Autonomous Vehicle Fleets

  Enabling Description: This derivative applies the Transformation Pipeline (561) to manage and optimize routes for a fleet of autonomous vehicles. The Data Filter receives live telemetry from vehicles (GPS, speed, traffic, sensor data) and external sources (weather, road closures). The Transformation Pipeline nodes perform: (1) Traffic Pattern Analysis: Identifies real-time congestion and predicts future bottlenecks. (2) Dynamic Rerouting: Generates alternative optimal routes based on current conditions and fleet objectives (e.g., minimize fuel, maximize delivery efficiency). (3) Obstacle Avoidance: Processes immediate sensor data to suggest micro-adjustments for safe navigation. (4) Fleet Coordination: Optimizes the allocation of tasks and routes across the entire fleet to prevent localized congestion or inefficiencies. The cyclical nature of the pipeline (FIG. 9) allows continuous refinement of routes as new data arrives, with feedback loops to update traffic models and vehicle assignments.

  graph TD
      A[Vehicle Telemetry] --> DR(Data Receipt)
      B[Traffic Data] --> DR
      C[Weather/Road Conditions] --> DR
      DR --> DF(Data Filter)
      DF --> TP_Traffic(T1: Traffic Pattern Analysis)
      TP_Traffic --> TP_Reroute(T2: Dynamic Rerouting)
      TP_Reroute --> TP_Avoid(T3: Obstacle Avoidance)
      TP_Avoid --> TP_Coord(T4: Fleet Coordination)
      TP_Coord --> TP_Reroute
      TP_Coord --> OM[Output Module (Vehicle Commands)]
  

4. Integration with Emerging Tech

• Derivative B4.1: Blockchain-Secured Transformation Provenance and Audit Trail

  Enabling Description: This derivative integrates blockchain technology to provide an immutable and verifiable audit trail for every data transformation within the Transformation Pipeline (561). Each transformation node, upon completing its function, generates a cryptographically signed hash of its input data, its transformation logic (including version and parameters), and its output data. This hash, along with a timestamp and the node's identifier, is committed as a transaction to a permissioned blockchain ledger. This creates an unbroken chain of custody and processing history for every data element, ensuring data integrity, non-repudiation, and transparency. This is critical for regulated industries (e.g., finance, healthcare) where proof of data lineage and algorithmic transparency are paramount. The Messaging Software Module (562) includes a blockchain client for interacting with the distributed ledger, and the System Sanity and Retrain Module (563) uses blockchain data to verify the integrity of the pipeline's execution and detect any unauthorized modifications to transformation logic.

  sequenceDiagram
      participant TP_Node_N as Transformation Node N
      participant Blockchain as Blockchain Ledger
      participant TP_Node_N_plus_1 as Transformation Node N+1
      participant SystemSanity as System Sanity & Retrain
      TP_Node_N->>TP_Node_N: Process Data (Input, Logic) -> Output
      TP_Node_N->>Blockchain: Commit Transaction (Hash(Input|Logic|Output), Timestamp, NodeID)
      Blockchain-->>TP_Node_N: Transaction Confirmation
      TP_Node_N->>TP_Node_N_plus_1: Pass Output Data
      SystemSanity->>Blockchain: Query Ledger for Provenance
      Blockchain-->>SystemSanity: Verified Transaction History
  

5. The "Inverse" or Failure Mode

• Derivative B5.1: Low-Power, Low-Fidelity Pipeline for Continuous Baseline Monitoring

  Enabling Description: In a low-power or resource-constrained scenario, the Transformation Pipeline (561) operates in a "low-fidelity" mode. This involves dynamically simplifying or bypassing non-essential transformations, reducing computational complexity, and potentially decreasing data sampling rates or precision (e.g., processing aggregated summaries instead of raw individual events). For instance, complex machine learning inference nodes might be replaced by simpler rule-based filters, or data enrichment steps might be temporarily suspended. The System Sanity and Retrain Module (563), receiving signals about resource scarcity (e.g., low battery, limited network bandwidth, CPU throttling), activates this mode. The objective is to maintain continuous, albeit coarser, baseline monitoring and high-level anomaly detection, rather than detailed predictive analysis. Upon restoration of full resources, the pipeline seamlessly transitions back to full-fidelity operation, potentially using the batch analysis module to backfill any missed high-fidelity data points.

  stateDiagram
      state FullFidelityPipeline {
          T1_Full: Transformation 1 (High Res)
          T2_Full: Transformation 2 (Complex ML)
          T3_Full: Transformation 3 (Enrichment)
          T1_Full --> T2_Full
          T2_Full --> T3_Full
      }
      state LowFidelityPipeline {
          T1_Low: Transformation 1 (Low Res)
          T2_Low: Transformation 2 (Rule-based)
          T1_Low --> T2_Low
      }
      [*] --> FullFidelityPipeline : Normal Operation
      FullFidelityPipeline --> LowFidelityPipeline : Resource_Constraint
      LowFidelityPipeline --> FullFidelityPipeline : Resource_Restored
      LowFidelityPipeline --> T2_Low : Continue Baseline Monitoring
  

---

C. Input Event Data Store / Batch Event Analysis Server (Historical Analysis Core)

1. Material & Component Substitution

• Derivative C1.1: Optane-Backed In-Memory Graph Database for Ultra-Low Latency Historical Lookups

  Enabling Description: This derivative replaces or augments the Input Event Data Store (540) with a persistent, in-memory graph database leveraging Intel Optane™ Persistent Memory. This allows the entire historical data graph (nodes, edges, properties) to reside directly in memory while retaining data durability across power cycles. The Batch Event Analysis Server (550) then performs historical queries and aggregations directly on this in-memory graph using graph traversal languages (e.g., Gremlin from Apache TinkerPop). This architecture provides ultra-low latency access (nanosecond scale) for complex graph analytics, such as identifying intricate historical fraud patterns, analyzing social network dynamics over time, or reconstructing complex event sequences, without the performance bottlenecks associated with disk I/O or traditional relational database joins. The ability to load and query massive historical graphs at speed significantly enhances the predictive power of the system by enabling real-time context from vast historical data.

  flowchart TD
      A[Formalized Data Stream] --> OIMGD{Optane In-Memory Graph Database (IEDS)}
      OIMGD --> BES[Batch Event Analysis Server]
      BES -- Graph Traversal Queries (Gremlin) --> OIMGD
      OIMGD -- Ultra-low Latency Results --> BES
      BES --> MSG[Messaging Software Module]
  

2. Operational Parameter Expansion

• Derivative C2.1: Planetary-Scale Data Lake Analysis with Geographically Distributed Batch Processing

  Enabling Description: This derivative expands the Input Event Data Store (540) and Batch Event Analysis Server (550) to operate at a planetary scale, with data lakes distributed across multiple global regions or continents. Data formalization (530) includes robust metadata tagging for geographical origin and data residency requirements. The Input Event Data Store comprises a federated data lake architecture, where data is stored in object storage (e.g., S3-compatible storage) across various cloud providers or on-premises data centers. The Batch Event Analysis Server component is deployed as a serverless or containerized compute fabric (e.g., Apache Spark on Kubernetes) that can dynamically spin up analytical workloads geographically proximate to the relevant data partitions. This minimizes data movement costs and latency for large-scale historical analysis, allowing for localized trend detection (e.g., regional market shifts, climate patterns) while enabling global aggregations when necessary. Data synchronization between regions utilizes asynchronous, eventually consistent replication mechanisms.

  graph LR
      Sensor_EU(Data Sources EU) --> DR_EU(Data Receipt EU)
      Sensor_US(Data Sources US) --> DR_US(Data Receipt US)
      DR_EU --> DFZ_EU(Data Formalization EU)
      DR_US --> DFZ_US(Data Formalization US)
      DFZ_EU --> IEDS_EU[Data Lake EU]
      DFZ_US --> IEDS_US[Data Lake US]
      IEDS_EU <--> Replication(Data Replication) <--> IEDS_US
      subgraph Global Batch Analysis
          BES_EU(Batch Server EU) <--> IEDS_EU
          BES_US(Batch Server US) <--> IEDS_US
          BES_EU --- Query_Coord(Global Query Coordinator) --- BES_US
      end
      Query_Coord --> MSG[Messaging Module]
  

3. Cross-Domain Application

• Derivative C3.1: Epidemiological Outbreak Prediction and Resource Allocation

  Enabling Description: This derivative adapts the historical analysis core for epidemiological applications. The Input Event Data Store (540) collects and stores vast amounts of public health data: anonymized patient records, vaccine distribution logs, pathogen sequencing data, environmental factors, travel patterns, and social media sentiment. The Batch Event Analysis Server (550) applies advanced statistical modeling and machine learning (e.g., SIR models, Bayesian inference, deep learning for pattern recognition) to this historical data. It identifies emerging disease trends, predicts outbreak trajectories, assesses the efficacy of past interventions, and models resource demands (e.g., hospital beds, medical supplies, personnel) based on historical scenarios. The messaging software module (562) then communicates these predictions and resource allocation recommendations to health authorities (output module 590) to inform public health policy and operational responses.

  flowchart TD
      A[Patient Records] --> IEDS(Input Event Data Store - Health Data Lake)
      B[Vaccine Logs] --> IEDS
      C[Pathogen Sequencing] --> IEDS
      D[Environmental Data] --> IEDS
      E[Travel Patterns] --> IEDS
      IEDS --> BES{Batch Event Analysis Server - Epidemic Modeling}
      BES -- Trend & Prediction Models --> MSG[Messaging Software Module]
      MSG --> Output[Output Module (Health Authority Alerts, Resource Allocation)]
  

4. Integration with Emerging Tech

• Derivative C4.1: Federated Learning for Cross-Organizational Batch Analysis

  Enabling Description: This derivative integrates federated learning with the Batch Event Analysis Server (550) to enable collaborative historical analysis across multiple organizations without sharing raw sensitive data. Each participating organization maintains its own Input Event Data Store and a local Batch Event Analysis Server instance. Instead of centralizing all historical data, the local servers train predictive models (ee.g., for fraud detection, disease prediction) on their private datasets. Only model parameters (e.g., weights, gradients), not the raw data, are securely aggregated and averaged by a central federated learning orchestrator (managed by the Messaging Module 562). This aggregated global model is then sent back to each local server for improvement. This cyclical process, managed by the System Sanity and Retrain Module (563), allows for robust predictive models to be built from larger, diverse datasets while preserving data privacy and adhering to regulatory compliance (e.g., GDPR, HIPAA).

  graph TD
      OrgA_IEDS[Org A IEDS] --> OrgA_BES(Org A Local Batch Server)
      OrgB_IEDS[Org B IEDS] --> OrgB_BES(Org B Local Batch Server)
      OrgC_IEDS[Org C IEDS] --> OrgC_BES(Org C Local Batch Server)
      OrgA_BES -- Local Model Params --> FL_Orch(Federated Learning Orchestrator)
      OrgB_BES -- Local Model Params --> FL_Orch
      OrgC_BES -- Local Model Params --> FL_Orch
      FL_Orch -- Aggregated Global Model --> OrgA_BES
      FL_Orch -- Aggregated Global Model --> OrgB_BES
      FL_Orch -- Aggregated Global Model --> OrgC_BES
      FL_Orch --> SARM[System Sanity & Retrain Module]
  

5. The "Inverse" or Failure Mode

• Derivative C5.1: Archive-Only Mode with Summarized Batch Analysis for Long-Term Data Retention

  Enabling Description: In this mode, the Input Event Data Store (540) transitions to an "archive-only" state, primarily focused on long-term, cost-effective data retention rather than active, high-speed retrieval for batch analysis. This might be triggered during periods of low analytical demand, severe resource constraints, or to meet specific regulatory archiving requirements. Data is migrated from high-performance storage to cold storage tiers (e.g., tape libraries, deep cloud archives like Amazon Glacier). The Batch Event Analysis Server (550) then operates on highly aggregated, pre-computed summaries or indices of the archived data, rather than performing full scans of raw data. This "summarized batch analysis" provides general trends and high-level insights, sacrificing granular detail for cost efficiency and reduced computational load. Full, detailed batch analysis can still be initiated but would involve a delayed data retrieval and rehydration process from the archive.

  stateDiagram
      state ActiveMode {
          DataIngest: Data Ingestion
          HighPerfStorage: High Performance Storage
          FullBatchAnalysis: Full Granular Batch Analysis
          DataIngest --> HighPerfStorage
          HighPerfStorage --> FullBatchAnalysis
      }
      state ArchiveMode {
          DataIngest_Archive: Data Ingestion (Archive Focus)
          ColdStorage: Cold Storage Tier (e.g., Tape, Glacier)
          SummarizedAnalysis: Summarized Batch Analysis
          DataIngest_Archive --> ColdStorage
          ColdStorage --> SummarizedAnalysis
      }
      [*] --> ActiveMode : Normal Operation
      ActiveMode --> ArchiveMode : Resource_Constraint / Archiving_Policy_Active
      ArchiveMode --> ActiveMode : Resource_Restored / Full_Analysis_Requested
  

---

D. Adaptive Control Layer (Messaging Software, System Sanity and Retrain Modules)

1. Material & Component Substitution

• Derivative D1.1: Dedicated Neuromorphic Computing Unit for Reinforcement Learning in Retraining

  Enabling Description: The System Sanity and Retrain Software Module (563) incorporates a dedicated neuromorphic computing unit (e.g., Intel Loihi, IBM NorthPole) for executing the reinforcement learning algorithms used in retraining other modules (e.g., Data Filter, Transformation Pipeline functions). Neuromorphic chips, designed to mimic biological neural networks, offer extreme energy efficiency and high parallel processing capabilities for sparse, event-driven computations. The RL agent's policy network and value functions are directly mapped to the neuromorphic hardware, allowing for rapid, low-power policy updates based on feedback signals from the Messaging Software Module (562) regarding system performance metrics (e.g., latency, throughput, error rates) and analysis outcome quality. This hardware substitution enables near-real-time retraining cycles, allowing the system to adapt more quickly to dynamic data characteristics or changing analytical objectives.

  flowchart TD
      A[Messaging Module (Metrics/Feedback)] --> NPU[Neuromorphic Processing Unit]
      NPU -- RL Algorithm Execution --> Retrain_Logic(System Sanity & Retrain Logic)
      Retrain_Logic -- Policy Updates --> DF[Data Filter Module]
      Retrain_Logic -- Policy Updates --> TP[Transformation Pipeline Module]
      NPU --> Retrain_Logic : Continuous Learning
  

2. Operational Parameter Expansion

• Derivative D2.1: Real-time Adaptive Governance with Millisecond Response to Policy Violations

  Enabling Description: This derivative expands the operational parameters of the System Sanity and Retrain Module (563) to include real-time adaptive governance with millisecond-level response capabilities. Beyond merely ensuring system stability, this module actively enforces and adapts to complex governance policies (e.g., data privacy, compliance, access controls, ethical AI guidelines). It continuously monitors data flows and transformation logic for policy violations. For example, if sensitive data is detected in an unauthorized pipeline segment, the system can trigger immediate remediation actions such as data masking, termination of the offending process, or re-routing the data, all within milliseconds. This requires low-latency policy engines, formal verification methods for transformation logic, and tightly integrated distributed access control mechanisms. The Messaging Software Module (562) is augmented to prioritize and relay governance-related alerts and policy enforcement directives with guaranteed delivery.

  sequenceDiagram
      participant DataFlow as Data Stream
      participant TP_Node as Transformation Node
      participant PolicyEngine as Real-time Policy Engine
      participant SARM as System Sanity & Retrain
      participant Enforcer as Policy Enforcer
      DataFlow->>TP_Node: Process Data
      TP_Node->>PolicyEngine: Data Output (for scanning)
      PolicyEngine->>SARM: Detect Policy Violation
      SARM->>Enforcer: Issue Remediation Directive (ms response)
      Enforcer->>TP_Node: Block/Mask Data / Terminate Process
      SARM->>Messaging: Log Incident & Alert Admin
  

3. Cross-Domain Application

• Derivative D3.1: Smart City Infrastructure Management and Anomaly Detection

  Enabling Description: The Adaptive Control Layer (Messaging 562, System Sanity and Retrain 563) is applied to manage smart city infrastructure, ranging from traffic lights and public transit to waste management and utility grids. The Messaging Software Module collects real-time operational data (e.g., traffic sensor readings, energy consumption, waste bin levels, public safety alerts). The System Sanity and Retrain Module continuously analyzes this aggregated data for anomalies (e.g., unexpected traffic jams, power grid imbalances, overflowing bins). When anomalies are detected or predictive models (from the Transformation Pipeline) forecast issues, the module automatically generates and dispatches adaptive control commands (e.g., adjust traffic light timings, re-route public transport, optimize waste collection routes, shed electrical load). The retraining mechanism ensures that the anomaly detection models and response strategies evolve based on observed outcomes and changing urban dynamics.

  graph TD
      A[Traffic Sensors] --> MSG(Messaging Module)
      B[Energy Grid Data] --> MSG
      C[Waste Bin Levels] --> MSG
      D[Public Safety Alerts] --> MSG
      MSG --> SARM{System Sanity & Retrain Module (Smart City Control)}
      SARM -- Anomaly Detection/Prediction --> SARM
      SARM -- Control Commands --> Traffic[Traffic Management System]
      SARM -- Control Commands --> Energy[Energy Grid Controls]
      SARM -- Control Commands --> Waste[Waste Management System]
  

4. Integration with Emerging Tech

• Derivative D4.1: Explainable AI (XAI) for Transparency in Retraining Decisions

  Enabling Description: This derivative integrates Explainable AI (XAI) techniques within the System Sanity and Retrain Module (563) to provide transparency and interpretability for its autonomous retraining decisions. Whenever the module decides to modify the operational behavior of other software modules (e.g., updating filter parameters, adjusting transformation functions), an XAI component generates human-readable explanations. These explanations detail why a particular change was made, what impact it is expected to have, and which data points or metrics primarily influenced the decision. Techniques employed could include LIME (Local Interpretable Model-agnostic Explanations) for individual decisions or SHAP (SHapley Additive exPlanations) for overall model understanding. These explanations are then logged via the Messaging Software Module (562) and presented to administrators through the Output Module (590), fostering trust in the autonomous system and enabling auditors to understand the system's adaptive behavior, especially in critical applications.

  flowchart TD
      A[Messaging Module (System Status, Results)] --> SARM_AI(System Sanity & Retrain Module (AI-Enhanced))
      SARM_AI -- Retraining Decisions --> DF[Data Filter Module]
      SARM_AI -- Retraining Decisions --> TP[Transformation Pipeline Module]
      SARM_AI --> XAI_Comp[Explainable AI Component]
      XAI_Comp -- Generate Explanation --> Log[Log of Retrain Decisions]
      XAI_Comp -- Human-readable Explanations --> Output[Output Module (Admin Dashboard)]
  

5. The "Inverse" or Failure Mode

• Derivative D5.1: Manual Override and Human-in-the-Loop Arbitration for Critical Failures

  Enabling Description: In this "inverse" configuration, the System Sanity and Retrain Module (563) is equipped with a robust manual override and human-in-the-loop (HITL) arbitration mechanism for critical system failures or situations where autonomous retraining might lead to undesirable outcomes. When the system detects a severe, unresolvable anomaly (e.g., cascading failures, uncontained data corruption, persistent out-of-bounds metrics) or a human operator intervenes, the autonomous retraining logic is temporarily suspended. The Messaging Software Module (562) relays detailed diagnostics and recommended actions to a human operator via the Output Module (590). The human operator, through a dedicated administrative interface, can then manually adjust system parameters, inject new operational guidelines, or initiate a specific recovery protocol. The system's learning algorithms are designed to learn from these human interventions, improving its autonomous decision-making in similar future scenarios.

  stateDiagram
      state AutonomousOperation {
          SARM_Auto: SARM (Autonomous Retrain)
          SARM_Auto --> SARM_Auto : Continuous Adaptation
          SARM_Auto --> OtherModules(Control System Modules)
      }
      state ManualIntervention {
          Human_Op: Human Operator
          Messaging_Alert: Messaging Module (Critical Alert)
          Admin_UI: Administrative Interface
          Human_Op --> Admin_UI : Manual Input
          Admin_UI --> SARM_Manual(SARM (Manual Control))
          SARM_Manual --> OtherModules
          Messaging_Alert --> Human_Op
      }
      AutonomousOperation --> ManualIntervention : Critical_Failure_Detected / Human_Override
      ManualIntervention --> AutonomousOperation : Human_Resolution_Complete / Re-Enable_Autonomous_Control
  

---

Combination Prior Art Scenarios

These scenarios describe how US patent 12143425, particularly its core concepts of distributed computational graphs and adaptive transformation pipelines, could be combined with existing open-source standards to create a system that would be obvious to a person having ordinary skill in the art.

1. Scenario 1: US12143425 with Apache Flink for Stream Processing

   Enabling Description: A person having ordinary skill in the art (PHOSITA) in 2015-2024, aware of US12143425's concepts of distributed computational graphs and adaptive transformation pipelines for rapid predictive analysis, would find it obvious to implement the "Transformation Pipeline Software Module" (561) using Apache Flink. Apache Flink is an open-source, distributed stream processing framework that supports both bounded and unbounded data streams, offers advanced state management with exactly-once consistency, and can define complex acyclic dataflow graphs composed of streams and transformations. The architectural pattern of Flink applications, involving ingestion from sources, transformation, and output to destinations, directly maps to the transformation pipeline described in US12143425.

   • Combination: The Data Receipt Module (510) and Data Filter Module (520) would feed into a Flink source connector (e.g., Kafka connector). Each "transformation" (620, 630, etc.) in the distributed computational graph of US12143425 would be implemented as a Flink operator (e.g., map, filter, process, keyBy, window, join) within a DataStream API application. Flink's capability for stateful computations and customizable window logic would directly support complex event processing and iterative analysis within the pipeline, including cyclical transformations as described in FIG. 9 and FIG. 15. The "System Sanity and Retrain Software Module" (563) could leverage Flink's checkpointing and savepoint mechanisms to manage state and reconfigure pipelines, or dynamically update Flink job graphs based on performance metrics or new analytical requirements. Flink's REST API or command-line interface could be used by the Messaging Software Module (562) to deploy, monitor, and scale these Flink jobs.

   flowchart TD
       A[Data Sources] --> B(Data Receipt Module)
       B --> C(Data Filter Module)
       C -- Filtered Stream --> FlinkSource[Apache Flink Source Connector]
       FlinkSource --> FlinkJob(Apache Flink DataStream Application - Transformation Pipeline)
       FlinkJob -- Processed Streams --> FlinkSink[Apache Flink Sink Connector]
       FlinkSink --> Output(Output Module)
       FlinkJob <--> MessageBus(Messaging Software Module)
       MessageBus <--> SanityRetrain[System Sanity & Retrain Module]
       SanityRetrain -- Dynamically Update Flink Job Graph --> FlinkJob
   

2. Scenario 2: US12143425 with Apache Kafka for Event-Driven Architecture

   Enabling Description: A PHOSITA in 2015-2024, given US12143425's focus on rapid predictive analysis of streaming data and distributed computational graphs, would naturally consider using Apache Kafka as the underlying event streaming platform for the "Messaging Software Module" (562) and as a backbone for inter-module communication. Kafka is an open-source, distributed event streaming platform known for its scalability, reliability, fault tolerance, and low latency for ingesting and processing streaming data. Its ability to publish and subscribe to streams of events, store them durably, and process them in real-time aligns perfectly with the patent's requirements for handling "very large data sets."

   • Combination: The Data Receipt Module (510) would publish raw or initial filtered data streams to specific Kafka topics. The Data Filter Module (520) would consume from one topic and publish its filtered output to another. The "two identical parts" split by the Data Filter (as per independent claim description) would be implemented by having two separate Kafka consumer groups reading from the same filtered data topic. The Transformation Pipeline Software Module (561) and Batch Event Analysis Server (550) would each act as Kafka Streams applications or consumers, reading input data from their respective Kafka topics, performing their analysis, and publishing results or intermediate states back to other Kafka topics. The Messaging Software Module (562) would essentially be a Kafka broker cluster, routing administrative directives and status messages between components as Kafka events, and the System Sanity and Retrain Module (563) would consume relevant Kafka topics to monitor system health and publish retraining directives. Kafka's durability and fault tolerance would provide resilience to the entire system.

   flowchart LR
       A[Data Sources] --> DR(Data Receipt Module)
       DR --> KafkaInput[Kafka Topic: RawData]
       KafkaInput --> DF(Data Filter Module)
       DF --> KafkaFiltered[Kafka Topic: FilteredData]
       KafkaFiltered --> TP(Transformation Pipeline Module)
       KafkaFiltered --> DFZ(Data Formalization Module)
       DFZ --> IEDS(Input Event Data Store)
       IEDS --> BES(Batch Event Analysis Server)
       TP --> KafkaTPResults[Kafka Topic: TP_Results]
       BES --> KafkaBESummaries[Kafka Topic: BA_Summaries]
       KafkaTPResults & KafkaBESummaries --> MSG(Messaging Software Module)
       MSG --> KafkaControl[Kafka Topic: Control_Directives]
       KafkaControl --> SARM[System Sanity & Retrain Module]
       SARM --> KafkaControl
       KafkaTPResults & KafkaBESummaries & KafkaControl --> Output(Output Module)
   

3. Scenario 3: US12143425 with Apache TinkerPop and Kubernetes for Graph-Based Operations

   Enabling Description: A PHOSITA in 2015-2024, understanding US12143425's emphasis on a "distributed computational graph" and its transformation pipelines, would find it obvious to implement the graph-centric aspects of the system using Apache TinkerPop for graph traversal and Kubernetes for orchestrating the distributed components. Apache TinkerPop is an open-source graph computing framework that provides a common interface and a graph traversal language called Gremlin for processing and traversing graph data. Gremlin traversals can operate on both online transactional processes (OLTP) and online analytics processes (OLAP), making it suitable for both real-time streaming transformations and batch analysis over stored graphs. Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications across clusters, ideal for distributed systems.

   • Combination: The "transformation pipeline" described in US12143425 would be implemented as a series of containerized microservices, each representing a "transformation node." These microservices would be orchestrated by Kubernetes, allowing for dynamic scaling and fault tolerance (e.g., using Deployments, StatefulSets). The "distributed computational graph" itself could be explicitly modeled using a TinkerPop-enabled graph database (e.g., JanusGraph running in a Kubernetes StatefulSet) as the Input Event Data Store (540). The "transformation" operations (620, 710, 810, 910) would involve executing Gremlin traversals or functions on data represented as graph elements. The ability of Gremlin to express complex traversals, including branching and cyclical logic (analogous to FIGS. 7-9 and 15), maps directly to the advanced pipeline configurations described in the patent. The System Sanity and Retrain Module (563) would monitor Kubernetes metrics (e.g., pod health, resource utilization) and use TinkerPop's capabilities for analyzing the "transformation graphs" (e.g., identifying bottlenecks or suboptimal traversal paths) to issue retraining directives for the containerized transformation nodes.

   flowchart TD
       A[Data Filter Output] --> K8s_Ingress[Kubernetes Ingress (Load Balancer)]
       K8s_Ingress --> K8s_TP1[K8s Pod: Transformation Node 1 (Gremlin)]
       K8s_TP1 --> K8s_TP2[K8s Pod: Transformation Node 2 (Gremlin)]
       K8s_TP2 -- Branching/Cyclical Logic --> K8s_TP_N[K8s Pod: Transformation Node N (Gremlin)]
       K8s_TP_N --> K8s_Output[Kubernetes Egress (Output)]
       K8s_TP_N <--> GraphDB[TinkerPop-Enabled Graph Database (K8s StatefulSet)]
       subgraph Kubernetes Cluster
           direction LR
           K8s_Master(K8s Control Plane) --> K8s_Nodes[K8s Worker Nodes]
           K8s_Nodes --> K8s_TP1
           K8s_Nodes --> K8s_TP2
           K8s_Nodes --> K8s_TP_N
           K8s_Nodes --> GraphDB
       end
       SARM[System Sanity & Retrain Module] -- K8s API & Gremlin Queries --> K8s_Master
       SARM --> GraphDB