Derivative works

Defensive Disclosure and Prior Art Derivations for U.S. Patent 6,073,142

Publication Date: May 11, 2026
Reference: U.S. Patent 6,073,142 ("the '142 patent")

This document discloses novel variations, extensions, and applications of the methods and systems described in the '142 patent. The intent of this disclosure is to place these concepts into the public domain, thereby establishing prior art against future patent applications claiming these or obvious variations thereof.

---

Axis 1: Architectural & Algorithmic Substitution

1.1. Serverless "Post Office" with Atomic Rule Functions

• Enabling Description: The monolithic "post office" architecture is replaced by a set of decoupled, event-driven serverless functions (e.g., AWS Lambda, Google Cloud Functions, Azure Functions) orchestrated via a message queue (e.g., SQS, RabbitMQ). The "receipt engine" is a function triggered by an object's arrival in a storage bucket or message queue. It places a message containing the object's metadata onto a "rules bus." Multiple, independent "rule functions" subscribe to this bus, each embodying a single business rule. Each rule function that is satisfied publishes a proposed "action" object (containing action type, priority, and parameters) to an "actions topic." A final "distribution engine" function is triggered by messages on the actions topic. It collects all actions for a given data object within a defined time window (e.g., 500ms), determines the highest-priority action according to a predefined hierarchy, and executes it. "Gating" involves publishing the original data object's location to a specific "gatekeeper review" queue, which a human-in-the-loop system monitors.

• Mermaid Diagram:

  flowchart TD
      subgraph Serverless Architecture
          A[Data Object Ingest] -->|Object metadata| B(Receipt Engine Function);
          B -->|Publishes to| C{Rules Bus};
          C --> D1[Rule Function 1];
          C --> D2[Rule Function 2];
          C --> Dn[Rule Function N];
          D1 -->|Action Object| E{Actions Topic};
          D2 -->|Action Object| E;
          Dn -->|Action Object| E;
          E --> F(Distribution Engine Function);
          F -->|Executes Highest Priority Action| G{Perform Action};
          G --> G1[Release];
          G --> G2[Delete];
          G --> G3[Gate to Gatekeeper Queue];
      end
  

1.2. Probabilistic Action Selection via Bayesian Inference

• Enabling Description: The deterministic "highest priority" action selection mechanism is replaced with a probabilistic model. The "rule engine" is a Bayesian inference engine. Instead of binary "fired/not fired" rules, each rule contributes evidence that updates a posterior probability distribution over the set of possible actions {release, delete, gate, etc.}. The rule P(Action | Attributes) ∝ P(Attributes | Action) * P(Action) is applied. For example, attributes like "sender is external," "contains financial keywords," and "has attachment > 10MB" increase the probability of the "Gate" action. The distribution engine does not select the highest-priority action but rather the action with the maximum a posteriori (MAP) probability. If the MAP probability is below a certain confidence threshold (e.g., 95%), it defaults to a safe action, such as "Gate." This allows the system to handle uncertainty and combinations of weak signals more gracefully than a rigid priority system.

• Mermaid Diagram:

  flowchart TD
      A[Data Object Received] --> B{Extract Attributes};
      B --> C[Bayesian Inference Engine];
      subgraph Rules as Priors
          R1[P(Gate | Attachment)]
          R2[P(Delete | Keyword)]
          R3[P(Release | Sender)]
      end
      C -- Applies Rules as Evidence --> D{Calculate Posterior Probabilities};
      D --> E[P(Release)=0.1, P(Delete)=0.2, P(Gate)=0.7];
      E --> F{Select Action with Max a Posteriori (MAP)};
      F --> G[Execute: Gate];
  

---

Axis 2: Operational Parameter Expansion

2.1. Gating in High-Latency, Disconnected Tactical Networks

• Enabling Description: This variation applies to edge computing in tactical or intermittently connected environments (e.g., military MANETs, remote industrial sites). The "post office" is a ruggedized edge server with limited connectivity to a central command. Business rules are pre-loaded, but include a "Staleness" attribute. If the connection to central command is lost for a period exceeding a rule's max_staleness parameter, the rule's action is automatically elevated in priority. The "gating" action is localized: the data object is rerouted to the designated local commander's (gatekeeper's) end-user device. A cryptographic hash of the gated object and the gating decision is stored. Upon reconnection, the edge "post office" syncs its log of gated decisions with the central server for audit and potential override. This ensures autonomous local policy enforcement while maintaining central oversight when possible.

• Mermaid Diagram:

  sequenceDiagram
      participant EdgeNode as Edge "Post Office"
      participant Central as Central Command
      participant Operator as Local Gatekeeper
  
      EdgeNode->>EdgeNode: Receive Data Object
      EdgeNode->>Central: Check Connectivity
      alt Connection OK
          EdgeNode->>Central: Sync Rules
          Central-->>EdgeNode: Latest Rules
          EdgeNode->>EdgeNode: Apply Rules normally
      else Connection Lost > max_staleness
          EdgeNode->>EdgeNode: Elevate Priority of Safety Rules
          EdgeNode->>EdgeNode: Trigger Gating Action Locally
          EdgeNode->>Operator: Route object for review
          Operator-->>EdgeNode: Manual Decision (Release/Delete)
      end
      EdgeNode->>Central: (On Reconnect) Sync Decision Log
  

2.2. Nanoscale Gating for On-Chip Data Flows

• Enabling Description: The concept is miniaturized to operate within a System-on-Chip (SoC) or FPGA. The "data objects" are data packets moving across an on-chip bus (e.g., AXI). The "post office" is a dedicated hardware logic block, the "Policy Enforcement Point" (PEP). The "business rules" are stored in on-chip block RAM and define acceptable data flows between IP cores (e.g., "CPU core cannot write directly to RF modulator memory"). The "rule engine" is implemented in HDL as a state machine that inspects packet headers and destinations in real-time. If a rule is violated, the "gating" action stalls the bus transaction and raises an interrupt to a security-supervisor processor core (the "gatekeeper"). This core can then inspect the stalled transaction, kill it, or grant an exception, allowing it to complete. This provides hardware-level security policy enforcement inside a single chip.

• Mermaid Diagram:

  graph TD
      subgraph SoC
          CPU -->|AXI Bus Transaction| PEP(Policy Enforcement Point);
          PEP -- Reads --> BRAM(Rule Store);
          subgraph Rule Example
              R["Rule: Disallow CPU -> RF_MEM Write"]
          end
          BRAM -- Rule --> PEP;
          PEP -->|Transaction Matches Rule| Gate{GATING LOGIC};
          Gate -->|Stall Bus & Interrupt| Supervisor(Security Supervisor Core);
          Supervisor -->|Inspect & Decide| Decision{Kill or Allow};
          Decision -- Allow --> PEP;
          PEP -->|Complete Transaction| RF(RF Modulator Core);
      end
  

---

Axis 3: Cross-Domain Application

3.1. Aerospace: Autonomous Drone Swarm Command Gating

• Enabling Description: In a drone swarm, a ground control station sends a high-level command object (e.g., { "action": "SURVEY", "area": [coords], "altitude": 50 }). The swarm's leader drone acts as the "post office." The "business rules" are the swarm's rules of engagement (ROE), flight safety parameters, and mission constraints (e.g., "Do not descend below 30m in urban zones," "Do not engage targets unless positively identified"). When the leader drone receives a command, its onboard "rule engine" validates it against the ROE. A command that violates a rule (e.g., survey altitude is too low for the zone) is not propagated to the swarm. Instead, it is "gated": the command is rerouted back to the human ground control operator (the "gatekeeper") with a "Request for Confirmation" flag and a description of the rule conflict. The operator must then explicitly override the rule for the command to be executed.

• Mermaid Diagram:

  sequenceDiagram
      participant GCS as Ground Control Station
      participant Leader as Leader Drone (Post Office)
      participant Swarm as Swarm Drones
  
      GCS->>Leader: Send Command Object
      Leader->>Leader: Apply Rules of Engagement (ROE)
      alt Command is ROE-Compliant
          Leader->>Swarm: Propagate Command
          Swarm->>Swarm: Execute Command
      else Command violates ROE
          Leader-->>GCS: Gate Command (Request Confirmation + Reason)
          GCS->>Leader: Send Explicit Override
          Leader->>Swarm: Propagate Overridden Command
      end
  

3.2. AgTech: Smart Irrigation Anomaly Gating

• Enabling Description: A centralized farm management system acts as a "post office" for processing sensor data and generating actuator commands. A "data object" is a scheduled irrigation command, e.g., { "zone": 7, "volume_liters": 5000, "start_time": "02:00" }. The "business rules" database contains crop water requirements, weather forecast data, soil moisture thresholds, and electricity pricing tiers. The "rule engine" processes the command before sending it to the irrigation controller. A rule might be: "IF weather_forecast.rain_chance > 80% THEN Action=DELETE" or "IF command.volume_liters > (2 * historical_avg) THEN Action=GATE". If the "GATE" action is triggered, the command is not sent to the pump controller. Instead, it is placed in a "review queue" on the farm manager's dashboard (the "gatekeeper"), who must manually approve the unusually high water usage before it is executed.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Scheduled
      Scheduled: Command Created {zone:7, vol:5000}
      Scheduled --> Rule_Engine: Process Command
  
      state Rule_Engine {
        [*] --> Check_Weather
        Check_Weather --> Check_Anomaly : [Rain <= 80%]
        Check_Weather --> Deleted : [Rain > 80%]
        Check_Anomaly --> Approved : [Volume < 2x Avg]
        Check_Anomaly --> Gated : [Volume >= 2x Avg]
      }
  
      Approved --> Executed: Command sent to pump
      Gated --> Awaiting_Review: On Manager Dashboard
      Awaiting_Review --> Executed: Manager Approves
      Awaiting_Review --> Deleted: Manager Rejects
      Executed --> [*]
      Deleted --> [*]
  

3.3. Consumer Electronics: Smart Home Command Arbitration

• Enabling Description: A smart home hub (e.g., Home Assistant, Amazon Echo) acts as the "post office" for commands from various sources (voice, mobile app, automations). A command to lock_front_door is a data object. The "business rules" represent household policies: "Never lock the front door if presence_sensor.people_inside == 0," or "If time > 23:00 and command is unlock_front_door, action is GATE." The "gatekeeper" is the primary homeowner's smartphone. If a late-night unlock command is issued by a guest's voice, the hub "gates" it by sending a high-priority push notification to the homeowner's phone: "Guest is attempting to unlock the front door. [Allow] [Deny]". The door remains locked until the gatekeeper manually allows the action.

• Mermaid Diagram:

  classDiagram
  class SmartHomeHub {
      +receiveCommand(Command)
      -applyRules(Command)
      -executeAction(Action)
  }
  class RuleEngine {
      +evaluate(Command, HouseState) ActionList
  }
  class HouseState {
      +people_inside: int
      +time_of_day: Time
  }
  class Command {
      +source: string
      +action: string
      +target: string
  }
  class GatekeeperDevice {
      +receiveGatedRequest(Command)
      +sendApproval()
      +sendDenial()
  }
  SmartHomeHub o-- RuleEngine
  SmartHomeHub o-- HouseState
  SmartHomeHub "1" -- "n" GatekeeperDevice : Notifies
  RuleEngine ..> Command
  

---

Axis 4: Integration with Emerging Tech

4.1. AI-Driven Predictive Gating with RLHF

• Enabling Description: The static, human-written "database of business rules" is replaced with a machine learning classification model (e.g., a gradient-boosted tree or a neural network). The model is trained on a massive corpus of historical data objects and the actions that were taken on them. The model ingests a new data object and outputs a risk score (0.0 to 1.0) and a recommended action. If the risk score exceeds a dynamic threshold, the system's action is to "gate" the object to a human gatekeeper. The key innovation is the feedback loop: the gatekeeper's final decision (e.g., releasing a message the AI flagged, or deleting one it missed) is used as a new labeled data point to continuously retrain and fine-tune the model, a process known as Reinforcement Learning from Human Feedback (RLHF). This allows the system to adapt to new threats and policies without manual rule rewriting.

• Mermaid Diagram:

  flowchart LR
      subgraph Inference
          A[Data Object] --> B(Feature Extraction);
          B --> C[ML Model];
          C --> D{Risk Score > Threshold?};
      end
      subgraph Gatekeeper Review
          E[Gatekeeper UI] -->|Approve/Deny| F{Final Action};
      end
      subgraph Training Loop (RLHF)
          G[Action Log] --> H(Model Retraining);
      end
      D -- Yes --> E;
      D -- No --> F;
      F --> G;
  

4.2. Blockchain-Based Immutable Gating with Smart Contracts

• Enabling Description: The system is implemented on a permissioned blockchain (e.g., Hyperledger Fabric). The "business rules" are encoded as functions within a smart contract. The "post office" is a network node that receives an off-chain data object. The node initiates a transaction on the blockchain by calling the smart contract's evaluate() function, passing in a hash of the data object and its metadata. The smart contract logic (the "rule engine") executes on all peer nodes. If the logic determines a "gate" action is required, the contract enters a PendingApproval state and emits an event. This state requires a multi-signature transaction to proceed, with the required signatures belonging to the cryptographic wallets of the designated "gatekeepers." A gatekeeper approves by signing a release() transaction call. The entire sequence—initial evaluation, gating, and final resolution—is recorded as an immutable, cryptographically verifiable series of transactions in the blockchain ledger, providing unparalleled auditability.

• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant AppNode as Application Node
      participant Blockchain
      participant Gatekeeper
  
      User->>AppNode: Submit Data Object
      AppNode->>Blockchain: Invoke evaluate(dataHash) on Smart Contract
      Blockchain->>Blockchain: Contract logic executes (Rule Engine)
      alt Gate Condition Met
          Blockchain->>Blockchain: Set state to PendingApproval
          Blockchain-->>Gatekeeper: Emit ApprovalRequest Event
          Gatekeeper->>Blockchain: Invoke release(dataHash) with signature
          Blockchain->>Blockchain: Validate signature; execute release logic
      else Gate Condition Not Met
          Blockchain->>Blockchain: Execute default logic (e.g., release)
      end
  

---

Axis 5: The "Inverse" or Failure Mode

5.1. Fail-Secure Gating Default

• Enabling Description: The system is designed with a "fail-secure" or "fail-closed" posture. The "distribution engine" is wrapped in a monitoring process or circuit breaker. If the rule engine service fails to return a decision within a specified timeout (e.g., 1 second), if it crashes, or if its connection to the rule database is lost, the monitoring process intercepts the data object. Instead of allowing it to pass or failing entirely, it enforces a default "gate-all" policy. The object is immediately shunted to a high-priority "quarantine" or "dead-letter" queue designated for system failure review. An alert is automatically sent to system administrators (the default gatekeepers for this scenario), notifying them of the failure and the location of the quarantined objects. This prevents data leakage or policy bypass during system outages.

• Mermaid Diagram:

  stateDiagram-v2
      state "Processing" as P
      [*] --> P
      P --> Released: Rule Engine -> Release
      P --> Deleted: Rule Engine -> Delete
      P --> Gated: Rule Engine -> Gate
      P --> Quarantined: Rule Engine -> Timeout/Error
  
      Quarantined: Object gated due to system failure
      Quarantined --> Manual_Review
      Manual_Review --> Released
      Manual_Review --> Deleted
  

5.2. Tiered Gating with Graceful Degradation

• Enabling Description: The system operates in multiple modes to gracefully handle resource constraints (e.g., high load, low power). In "Full Mode," the complete, computationally expensive rule set is applied. If system load exceeds a threshold (e.g., CPU > 90%), it enters "Degraded Mode." In this mode, only a pre-defined subset of high-priority, low-cost rules (e.g., simple keyword matching) is executed. All other data objects are "soft-gated"—they are released to their destination but are tagged with a review_required flag, and their metadata is logged to a queue for asynchronous, delayed review once system load returns to normal. This ensures critical policies are still enforced in real-time while preventing system collapse and creating a backlog for eventual consistency.

• Mermaid Diagram:

  flowchart TD
      A[Data Object] --> B{Check System Load};
      B -- Load < 90% --> C[Full Rule Set Engine];
      C --> D{Apply Actions};
      B -- Load >= 90% --> E[Degraded Mode Engine];
      subgraph Degraded Mode Engine
          E1[Apply Critical Rules Only] --> E2{Triggered?};
      end
      E2 -- Yes --> D;
      E2 -- No --> F[Release with 'Review Required' Tag];
      F --> G[Log for Async Review];
  

---

Combination Prior Art with Open-Source Standards

Scenario 1: Gating SMTP Messages based on DMARC & SPF

• Enabling Description: A mail transfer agent (MTA) acting as a "post office" (e.g., Postfix, Exim) integrates a policy daemon that functions as the "rule engine." When an email is received, the MTA first performs standard DMARC, SPF, and DKIM validation. The results of these checks (pass, fail, softfail, none) are passed to the policy daemon as attributes of the message. A business rule can now be defined as: "IF (dmarc.result == 'fail' OR spf.result == 'fail') AND header.from matches domain-list:financial_partners THEN Action=GATE, Gatekeeper=soc-team@example.com." This combines standard internet email authentication protocols with the '142 patent's gating logic to create a sophisticated anti-phishing and anti-spoofing system where marginal authentication failures from critical partners are routed for human analysis rather than being automatically rejected or delivered.

Scenario 2: Gating HTTP API Calls based on JWT Claims

• Enabling Description: A cloud-native API Gateway (e.g., Kong, Tyk) serves as the "post office" for all incoming microservice requests. Every request must include a JSON Web Token (JWT) in its Authorization header. The gateway acts as the "rule engine," validating the JWT's signature and then inspecting its payload (claims). Business rules are defined based on these claims: "IF request.path matches /admin/* AND jwt.claims.role != 'admin' THEN Action=GATE." The "gating" action is implemented by forwarding the original request object to a separate "security approval" service and returning an HTTP 202 Accepted status to the original client with a location header pointing to a status-check endpoint. A security officer (gatekeeper) reviews the request in a dashboard and, upon approval, the security service re-plays the original request with an elevated-privilege token.

Scenario 3: Gating MQTT Messages in an IoT Network based on OPC UA Models

• Enabling Description: An MQTT broker (e.g., Mosquitto, EMQ X) is configured with a rule engine plugin. The broker is the "post office" for messages from industrial sensors and actuators. The "business rules" are defined using the standardized information models from OPC UA, which describe the valid states and operating parameters of industrial equipment. A sensor publishes a JSON payload to an MQTT topic: topic: 'factory/press-1/pressure', payload: { 'value': 950, 'units': 'kPa' }. The rule engine loads the OPC UA model for press-1 and knows the max_pressure is 900 kPa. A rule states: "IF payload.value > opcua.model.max_pressure THEN Action=GATE, Gatekeeper=topic:factory/press-1/alerts." The "gating" action simultaneously publishes the anomalous message to an alert topic for human review and sends a command via MQTT to a safety PLC to halt the machine, preventing damage.