Derivative works — US Patent 12353917

Defensive Disclosure and Prior Art Generation

Publication Date: May 1, 2026
Author: Senior Patent Strategist and Research Engineer
Subject: Derivative Implementations and Obvious Variations of U.S. Patent 12,353,917 ("Event-based resource allocation system")
Abstract: This document discloses a series of technical variations, extensions, and alternative embodiments of the system and method described in U.S. Patent 12,353,917. The purpose of this disclosure is to place into the public domain and establish as prior art these derivative concepts, thereby rendering obvious any future patent claims that incrementally build upon the core teachings of the '917 patent. The described variations are intended to be enabling for a Person Having Ordinary Skill in the Art (PHOSITA).

Core Claim Concept Analyzed

The fundamental process disclosed in US patent 12353917 involves a computing system that (1) generates prompts based on resource documents, (2) receives user responses, (3) generates structured resource data based on the responses and predefined rules, and (4) generates visualizations of the asset distribution. The following disclosures detail variations on this core process.

Category 1: Component and Architectural Substitutions

1.1. Real-Time Event Stream Ingestion Engine

Enabling Description: This variation replaces the static "resource document" ingestion mechanism with a real-time, event-driven architecture. The system subscribes to one or more message queues (e.g., using Apache Kafka, RabbitMQ, or AWS Kinesis) that stream data relevant to resource status. For financial applications, this could be a stream of stock ticks from a market data feed. For IT resource management, it could be a stream of syslog events or performance metrics from a monitoring agent. The system employs a complex event processing (CEP) engine, such as Esper, to identify patterns or anomalies in the event stream (e.g., a 15% drop in an asset's value within 5 minutes). Upon detection of a defined pattern, which functions as the "resource document," the system triggers the prompt generation module to query a human operator or an automated risk-management service for instructions. The response then initiates the allocation or re-allocation of assets.

Mermaid Diagram:

sequenceDiagram
    participant MarketDataFeed as Market Data Feed
    participant KafkaStream as Kafka Topic
    participant CEPEngine as CEP Engine
    participant PromptModule as Prompt Module
    participant User as User/Operator
    participant AllocationEngine as Allocation Engine

    MarketDataFeed->>+KafkaStream: Stream Asset Price Ticks
    CEPEngine->>+KafkaStream: Subscribe to Topic
    Note over CEPEngine: Detects 15% price drop
    CEPEngine->>PromptModule: Trigger Alert (Asset X dropped)
    PromptModule->>User: Prompt: "Asset X down 15%. Liquidate or hold?"
    User->>PromptModule: Response: "Liquidate 50%"
    PromptModule->>AllocationEngine: Generate Instruction: {action: "sell", asset: "X", quantity: "50%"}
    AllocationEngine-->>-CEPEngine: Execute Re-allocation

1.2. Graph-Based Resource Data Model

Enabling Description: This embodiment replaces a conventional relational database with a native graph database (e.g., Neo4j, Amazon Neptune) for storing the "resource data." Entities (users, beneficiaries), assets (physical, digital), rules (legal statutes, policies), and locations are all modeled as nodes in the graph. The relationships between them (e.g., OWNS, BENEFICIARY_OF, GOVERNED_BY, LOCATED_IN) are modeled as edges with properties. This structure allows for highly complex and performant queries that are inefficient in SQL, such as multi-level relationship analysis ("Find all beneficiaries who will inherit assets located in states with an inheritance tax, where the asset is held in a trust managed by a trustee who is also a beneficiary of another, separate trust."). The visualization component directly queries this graph structure to generate interactive network diagrams, allowing users to visually explore these complex relationships.

Mermaid Diagram:

erDiagram
    PERSON {
        string id
        string name
    }
    ASSET {
        string id
        string description
        float value
    }
    TRUST {
        string id
        string name
    }
    RULE {
        string id
        string jurisdiction
        string text
    }

    PERSON ||--o{ TRUST : "TRUSTEE_OF"
    PERSON ||--o{ ASSET : "BENEFICIARY_OF"
    TRUST ||--|{ ASSET : "HOLDS"
    ASSET ||--|{ RULE : "GOVERNED_BY"

Category 2: Operational Parameter and Scale Expansion

2.1. Global Supply Chain Logistics Management

Enabling Description: The system is scaled to manage the global logistics network for a multinational corporation. The "resources" are manufacturing capacity, raw materials, and shipping containers. "Resource documents" consist of trade agreements (e.g., USMCA), bills of lading, and real-time vessel location data from AIS (Automatic Identification System) feeds. When a geopolitical event occurs (e.g., a new tariff is announced, which is parsed from a government data feed), the system identifies all in-transit assets affected by the new rule. It then prompts a logistics manager with options, such as "New 10% tariff on component X from Port Y. Reroute to Port Z (2 day delay, $50k cost) or pay tariff ($120k cost)?" The visualization is a dynamic GIS map displaying all assets, shipping lanes, and highlighting nodes affected by the event.

Mermaid Diagram:

flowchart TD
    A[Start: Geopolitical Event Detected] --> B{Parse New Tariff Rule};
    B --> C[Query Database: Identify Affected Shipments];
    C --> D{Generate Re-routing Scenarios};
    D --> E[Prompt Logistics Manager: "Reroute or Pay Tariff?"];
    E --> F{Receive Manager's Response};
    F --> G[Generate New Instructions for Cargo Carrier];
    G --> H[Update GIS Visualization with New Route];
    H --> I[End: Re-allocation Executed];

2.2. Nanoscale Resource Allocation for Semiconductor Fabrication

Enabling Description: The invention is applied at the nanoscale to manage resource allocation within a semiconductor fabrication plant (fab). The "assets" are lots of silicon wafers, individual fabrication tools (e.g., lithography machines, etchers), and chemical precursors. The "resource document" is the master production schedule and the specific recipe for a chip design (GDSII file). The system monitors tool performance and chemical purity in real-time. If a sensor indicates an etcher is drifting out of spec (an "event"), the system pauses wafer lots scheduled for that tool. It prompts a fab engineer with options: "Etcher E-08 is out of tolerance. Recalibrate (4-hour downtime) or reroute high-priority Lot A-101 to Etcher E-09 (adds 2 hours to cycle time)?" The "rule data" includes complex process dependencies and tool qualifications. The visualization is a fab layout diagram showing wafer lot movements and tool status.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Idle
    Idle --> Processing_Lot: Wafer Lot Arrives
    Processing_Lot --> Tool_Malfunction: Sensor Detects Drift
    Tool_Malfunction --> Engineer_Prompt: "Recalibrate or Reroute?"
    Engineer_Prompt --> Rerouting: Reroute Decision
    Engineer_Prompt --> Recalibrating: Recalibrate Decision
    Rerouting --> Processing_Lot: Continues on new tool
    Recalibrating --> Idle: Tool Offline
    Idle --> Processing_Lot: Tool back online
    Processing_Lot --> [*]: Lot Complete

Category 3: Cross-Domain Applications

3.1. Aerospace: Autonomous Satellite Constellation Management

Enabling Description: The system is deployed to autonomously manage a LEO satellite constellation. "Assets" are satellite resources such as transponder bandwidth, onboard processing power, and imaging sensor time. The "resource documents" are client SLAs and pre-approved mission plans. An "event," such as a sudden request for high-priority disaster imaging over a specific geographic area, triggers the system. The system automatically identifies satellites with visibility of the target area and checks their current tasking and resource availability (power, data storage). It generates an allocation plan that may involve de-prioritizing lower-priority commercial tasks. This plan, with its justifications and predicted impacts on SLAs, is presented as a "prompt" to a human mission controller for final go/no-go approval. The visualization is a 3D celestial map showing satellite orbits, ground tracks, and real-time bandwidth allocation.

Mermaid Diagram:

flowchart LR
    subgraph On-Ground Control
        A[Priority Task Request] --> B(Identify Capable Satellites)
        B --> C{Model Resource Conflicts}
        C --> D[Generate Optimal Re-allocation Plan]
        D --> E(Prompt Mission Controller for Approval)
    end
    subgraph Satellite Constellation
        F[SAT-1: Imaging Task]
        G[SAT-2: Comms Task]
        H[SAT-3: Idle]
    end
    E -- Approval --> I(Uplink New Commands)
    I -- Command --> G(Deprioritize Comms Task)
    I -- Command --> F(Execute Priority Imaging)

3.2. AgTech: Automated Irrigation and Nutrient Allocation

Enabling Description: This variation applies the system to precision agriculture. The "assets" are water (measured in acre-feet), nitrogen fertilizer, and autonomous farming equipment (e.g., drones, tractors). "Resource documents" are soil-type maps, weather forecasts, and crop growth models. IoT sensors in the field provide real-time soil moisture and nutrient level data. When a sensor array detects that a specific zone is becoming water-stressed (an "event"), the system is triggered. It references the rules (e.g., water rights regulations, crop stage requirements) and prompts the farmer or an autonomous farm manager: "Zone 7 water stress at 25%. Apply 0.5 inches irrigation now? Forecast shows 80% chance of rain in 48 hours." The visualization is a color-coded heatmap of the farm, showing real-time resource levels and the proposed allocation.

Mermaid Diagram:

sequenceDiagram
    participant IoT_Sensor as Field Sensor
    participant AgSystem as Allocation System
    participant Farmer as Farmer/Manager
    participant IrrigationValve as Smart Irrigation Valve

    loop Real-time Monitoring
        IoT_Sensor->>AgSystem: Send Soil Moisture Data (Zone 7: 15%)
    end
    Note over AgSystem: Moisture level below threshold
    AgSystem->>Farmer: Prompt: "Zone 7 needs water. Approve irrigation?"
    Farmer->>AgSystem: Response: "Approved"
    AgSystem->>IrrigationValve: Command: Open Valve for Zone 7, 30 mins
    IrrigationValve-->>AgSystem: Acknowledge

Category 4: Integration with Emerging Technologies

4.1. Integration with AI-Driven Reinforcement Learning

Enabling Description: The core allocation engine is enhanced with a reinforcement learning (RL) agent (e.g., using a Deep Q-Network). The system state is defined by the current asset values and distribution. The action space consists of all possible re-allocations. The RL agent is trained to maximize a complex reward function, such as the 30-year projected after-tax value of an estate, while adhering to rules which act as hard constraints. The prompts generated for the user are no longer simple queries but are suggestions from the RL agent: "AI recommends rebalancing your portfolio by selling 10% of Asset A and buying Asset B to reduce tax exposure. Expected 5-year gain increase: 3.2%. Approve?" The user's response provides feedback to the RL model, further refining its strategy.

Mermaid Diagram:

flowchart TD
    subgraph TrainingLoop
        A[State: Current Portfolio] --> B(RL Agent: Propose Action)
        B --> C(Simulate Portfolio Change)
        C --> D{Calculate Reward: Projected Value - Risk}
        D --> B
    end
    subgraph UserInteraction
        E[State: User's Current Portfolio] --> F(RL Agent: Suggest Optimal Action)
        F --> G[Prompt User with AI Suggestion & Rationale]
        G --> H{User Approves/Rejects}
        H -- Approves --> I[Execute Re-allocation]
        H -- Rejects --> J[Record Feedback for Model]
        J --> F
    end

4.2. Blockchain and Smart Contract-Based Execution

Enabling Description: The system is integrated with a public or private blockchain (e.g., Ethereum, Hyperledger Fabric). Physical and digital assets are represented as Non-Fungible Tokens (NFTs) in a user's digital wallet. The "resource allocation instructions" generated by the system are compiled into a smart contract. The contract codifies the rules of distribution. The "events" (e.g., a person's death, a company's dissolution) are reported to the smart contract by a trusted, decentralized oracle service (e.g., Chainlink). Upon receiving a verified event trigger from the oracle, the smart contract automatically executes the transfer functions of the asset NFTs, sending them to the beneficiaries' wallet addresses. The blockchain provides an immutable, transparent, and auditable trail of the entire resource allocation process, eliminating the need for manual intermediaries.

Mermaid Diagram:

sequenceDiagram
    participant User as User
    participant AllocationSystem as Allocation System
    participant SmartContract as Deployed Smart Contract
    participant Oracle as Trusted Oracle
    participant Beneficiary as Beneficiary

    User->>AllocationSystem: Define allocation rules
    AllocationSystem->>SmartContract: Deploy contract with rules & asset addresses
    Oracle->>SmartContract: Trigger Event (e.g., Testator_Deceased)
    Note over SmartContract: Contract verifies oracle signature
    SmartContract->>SmartContract: Execute distribution logic
    SmartContract->>Beneficiary: Transfer Asset NFT to wallet

Category 5: Inverse and Safe-Failure Modes

5.1. Provably Safe Escrow Mode

Enabling Description: The system is designed with a "safe-fail" operational mode. If, during the process, the system detects an unresolvable ambiguity in a resource document, a direct conflict between two rules, or a user response that violates a critical constraint, it halts the standard workflow. Instead of proceeding, it automatically triggers a "safe escrow" protocol. All contested assets are programmatically transferred to a pre-defined, secure holding entity (e.g., a digital asset custody service, a legal trust account). The system then generates a detailed "conflict report" for all stakeholders, explaining the ambiguity and why the safe-fail mode was activated. This prevents an incorrect or legally invalid distribution of assets by defaulting to a secure, neutral state that requires high-level human intervention.

Mermaid Diagram:

flowchart TD
    A[Generate Resource Data] --> B{Ambiguity or Rule Conflict?};
    B -- No --> C[Proceed with Normal Allocation];
    B -- Yes --> D[HALT Allocation Workflow];
    D --> E[Activate Safe Escrow Protocol];
    E --> F[Transfer Contested Assets to Escrow];
    F --> G[Generate Conflict Report];
    G --> H[Notify All Stakeholders];
    H --> I[End: Awaiting Human Intervention];

Combination Prior Art with Open-Source Standards

Combination with BPMN (Business Process Model and Notation): The system's visualization output is a machine-readable, BPMN 2.0 compliant XML file. This model represents the resource allocation plan as a formal business process. "Resource recipients" are defined as actors in swimlanes, "assets" are data objects, and the "rules" are modeled as exclusive or parallel gateways. This allows the generated plan to be directly executed and monitored by open-source workflow engines like Camunda, transforming the visualization from a static report into an executable and auditable process.
Combination with FDC3 (Financial Desktop Connectivity and Collaboration Consortium): The system is implemented as an FDC3-compliant web application for use by financial advisors. The application "listens" for fdc3.instrument context on the advisor's message bus. When the advisor clicks on a stock in their separate portfolio management tool, that tool broadcasts the stock's context. The system receives this context, automatically identifies it as an "asset," retrieves the relevant client "resource documents" (e.g., investment policy statement), and initiates the prompt-and-response workflow, all within a seamless, open-standard desktop environment.
Combination with OpenID Connect (OIDC) for Verifiable Credentials: The system uses the OIDC for Verifiable Presentations protocol to authenticate entities and verify their attributes. Instead of prompting a user "Is Jane Doe married?", the system requests a Verifiable Credential (VC) for "marital status" from Jane Doe's digital identity wallet. This credential, cryptographically signed by a trusted issuer (e.g., a government vital records office), provides machine-verifiable proof. This replaces error-prone manual input for critical facts with a secure, decentralized, and open standard-based verification method, dramatically increasing the system's reliability and automation potential.