Derivative works — US Patent 6044382

Defensive Disclosure: Derivative Embodiments of a Data Transaction Assembly Server

Publication Date: May 11, 2026
Reference Patent: U.S. Patent 6,044,382

This document discloses novel and non-obvious variations, extensions, and applications of the methods and systems described in U.S. Patent 6,044,382 ("the '382 patent"). The purpose of this disclosure is to place these concepts in the public domain, thereby establishing prior art against future patent applications claiming these or similar inventions. The following disclosures are based on the core claims of the '382 patent.

Derivatives Based on Claim 1: A Method for Forming Data Transactions

The core concept involves a host computer receiving form/menu data streams from a remote server to reconfigure itself for a specific transaction, which is then assembled and returned.

Axis 1: Material & Component Substitution

Derivative 1.1: WebAssembly (WASM) Module as Form/Menu Data Stream
- Enabling Description: The "data stream representative of forms and menus" is a compiled WebAssembly (WASM) module. The host computer is a standard web browser or any other environment with a WASM runtime. The remote database server transmits a specific WASM module corresponding to the desired application (e.g., banking.wasm, retail.wasm). The host's Transaction Assembly Server (TAS) is a lightweight WASM runtime environment that executes the received module. The WASM module, upon execution, renders the user interface, handles data input, performs client-side validation, and assembles the data transaction into a binary-packed structure (e.g., using Protocol Buffers) for efficient transmission back to the server. This substitutes the abstract "data stream" with a specific, high-performance, sandboxed binary format.
- ```
sequenceDiagram
    participant HostComputer as Host (WASM Runtime)
    participant DatabaseServer as Server
    HostComputer->>DatabaseServer: Request application 'Banking'
    DatabaseServer-->>HostComputer: Transmit banking.wasm module
    activate HostComputer
    HostComputer: Instantiate banking.wasm
    HostComputer: Execute WASM to render UI & collect data
    HostComputer->>HostComputer: Assemble data transaction (Protocol Buffer)
    HostComputer->>DatabaseServer: Transmit binary data transaction
    deactivate HostComputer
```
Derivative 1.2: Neuromorphic Processing Unit for Host Computer
- Enabling Description: The host computer's processor is a neuromorphic chip (e.g., Intel Loihi 2) designed for event-based, asynchronous processing. The "data streams" from the server are not traditional UI layouts but are sets of synaptic weights and neuron configurations. The TAS on the host loads these configurations into the neuromorphic processor, which reconfigures its spiking neural network to represent the logic and flow of a specific transaction form. User input (e.g., keystrokes, voice commands) is converted into spike trains that propagate through the network. The final state of specific output neurons represents the assembled data transaction, which is then transmitted. This method is exceptionally low-power and suited for edge devices.
- ```
flowchart TD
    A[Server] -- Synaptic Weights & Neuron Config --> B(Host: Neuromorphic Processor)
    C[User Input] -- Spike Train --> B
    B -- Reconfigures Spiking Neural Network --> D{Transaction Logic}
    D -- Processes Input --> E(Output Neuron States)
    E -- Encoded as Data Transaction --> F[Transmit to Server]
```

Axis 2: Operational Parameter Expansion

Derivative 2.1: Nanoscale Molecular Assembler Application
- Enabling Description: The system operates at a molecular scale. The "host computer" is a biological cell or nanoscale assembler. The "database server" is a DNA sequencer/synthesizer. The "data streams" are encoded DNA or RNA sequences. The TAS is a ribosome or similar molecular machine within the cell that 'reads' the transmitted RNA sequence (the form) and assembles a specific protein or polypeptide chain (the data transaction) based on available amino acids (the user input). The completed polypeptide is then "transmitted" by being released into the cellular environment, where its structure and composition can be read by other sensors, effectively completing the transaction.
- ```
graph LR
    subgraph Server (DNA Synthesizer)
        A[Transaction Request] --> B(Encode RNA Sequence)
    end
    subgraph Host (Biological Cell)
        C(Ribosome TAS)
        D[Amino Acids]
    end
    B -- Transmit RNA Stream --> C
    D -- User Input --> C
    C -- Assemble Polypeptide --> E(Completed Protein Transaction)
    E -- Release & Detect --> F(Transaction Processed)
```
Derivative 2.2: Hypersonic Vehicle Control Surface Reconfiguration
- Enabling Description: The "host computer" is the flight control system of a hypersonic vehicle. The "database server" is a ground control station or an autonomous mission command AI. During flight, as the vehicle enters different atmospheric pressures and temperatures, the server transmits new data streams. These are not user forms but control-law parameter sets and aerodynamic models. The TAS on the vehicle dynamically applies these models to reconfigure the response characteristics of its control surfaces (e.g., ailerons, flaps) in real-time. The "data transaction" returned to the server is a packet of telemetry data confirming the new configuration and reporting current flight dynamics. This allows the vehicle to adapt its physical behavior to extreme, rapidly changing conditions.
- ```
stateDiagram-v2
    [*] --> InAtmosphere
    InAtmosphere --> HypersonicFlight: Mach 5+
    HypersonicFlight --> HypersonicFlight: GroundControl sends new Control-Law Data Stream
    HypersonicFlight --> PlasmaSheath: High Temp/Pressure
    PlasmaSheath --> PlasmaSheath: MissionAI sends updated Aerodynamic Model
    PlasmaSheath --> GlidePhase: Deceleration
    GlidePhase --> Landing: Final Config Stream
```

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - On-Orbit Satellite Repurposing
- Enabling Description: A satellite in orbit (the host computer) with a general-purpose software-defined radio (SDR) and field-programmable gate array (FPGA) needs to be repurposed. A ground station (the database server) transmits a new data stream containing an FPGA bitstream and SDR configuration parameters. This stream represents the "form" for a new mission (e.g., weather monitoring, signal intelligence). The satellite's TAS loads this configuration, reconfiguring its hardware to function as a new type of sensor. The "data transaction" it assembles and sends back is the sensor data collected under its new mission profile.
- ```
flowchart LR
    A[Ground Station] -- FPGA Bitstream & SDR Config --> B(Satellite TAS)
    B -- Reconfigures Hardware --> C(New Sensor Personality)
    D[Orbital Environment] -- Scanned by --> C
    C -- Assembles Sensor Data --> E(Mission Data Transaction)
    E -- Transmits Downlink --> A
```
Derivative 3.2: AgTech - Autonomous Drone Crop Scouting
- Enabling Description: An agricultural drone (host) flies over a field. A central farm server (database server), using satellite imagery, identifies a potential area of crop stress. The server transmits a data stream representing a "scouting mission form" to the drone. This form contains GPS coordinates, sensor settings (e.g., multispectral camera exposure, Lidar scan density), and flight path adjustments. The drone's TAS executes this form, flies to the specified location, captures the high-resolution data, and assembles it into a data transaction packet, tagging it with the mission ID from the form. This packet is transmitted back to the farm server for analysis.
- ```
sequenceDiagram
    participant FarmServer
    participant Drone
    FarmServer->>Drone: Transmit Scouting Mission Form (GPS, Sensor Params)
    activate Drone
    Drone->>Drone: Execute flight path and sensor readings
    Drone->>Drone: Assemble multispectral/Lidar data transaction
    Drone-->>FarmServer: Return completed Mission Data
    deactivate Drone
```
Derivative 3.3: Consumer Electronics - Dynamic Smart Home Scene Controller
- Enabling Description: A central smart home hub (database server) manages dozens of devices. A user's smartphone (host computer) connects to the hub. Instead of a fixed app interface, the hub transmits a data stream representing a "scene configuration form" based on the time of day and devices currently online (e.g., a "Movie Night" form appears on Friday evening). The user interacts with this dynamically generated form to set light levels, thermostat, and audio system. The user's selections are assembled into a "scene command" data transaction and sent to the hub, which then orchestrates the various smart devices accordingly.
- ```
erDiagram
    SMART_HUB ||--o{ DEVICE : controls
    SMART_HUB {
        string HubID
        string CurrentContext
    }
    DEVICE {
        string DeviceID
        string State
    }
    SMART_HUB }|..|| USER_PHONE : transmits
    USER_PHONE {
        string PhoneID
    }
    USER_PHONE ||--|{ SCENE_FORM : displays
    SCENE_FORM {
        string FormID
        string UserSelections
    }
    SCENE_FORM }o..|| SMART_HUB : returns-transaction
```

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Adaptive Form Generation
- Enabling Description: The database server incorporates a machine learning model (e.g., a recurrent neural network) that analyzes a user's past transactions. When a user initiates a new session, instead of sending a static form, the server's AI generates a predictive form data stream in real-time. It pre-populates fields it predicts the user will need, removes fields the user historically ignores, and orders the workflow based on the user's typical behavior. The host computer receives and renders this bespoke form. The assembled transaction is fed back into the ML model to further refine future form generations.
- ```
graph TD
    subgraph Server
        A[User History DB] --> B(ML Model)
        C[User Initiates Session] --> B
        B -- Generates --> D(Dynamic Form Data Stream)
    end
    subgraph Host
        E[TAS]
    end
    D -- Transmitted to --> E
    E -- Renders Personalized Form --> F(User Interaction)
    F -- Assembled Transaction --> G
    G -- Sent back to --> B
```
Derivative 4.2: IoT Sensor Auto-Population
- Enabling Description: The host computer is an industrial tablet on a factory floor, equipped with Bluetooth and NFC readers. The server sends a "machine maintenance" form. The form's data stream includes identifiers for required IoT sensor data (e.g., temperature_sensor_A5, vibration_sensor_B2). As the technician (user) moves the tablet near the respective machines, the TAS on the tablet automatically detects the sensors via Bluetooth beacons or NFC, reads their current values, and populates the corresponding fields in the form. The user only needs to add observational notes. The final data transaction combines manual input with verified, real-time IoT data.
- ```
sequenceDiagram
    participant Server
    participant Tablet_TAS as Host
    participant Machine_IoT_Sensor as Sensor
    Server-->>Tablet_TAS: Send Maintenance Form (w/ Sensor IDs)
    activate Tablet_TAS
    Tablet_TAS->>Sensor: Proximity Scan (BT/NFC)
    Sensor-->>Tablet_TAS: Report Value (e.g., 95C)
    Tablet_TAS->>Tablet_TAS: Auto-populate temperature field
    Note over Tablet_TAS: User adds notes
    Tablet_TAS->>Server: Transmit completed transaction
    deactivate Tablet_TAS
```
Derivative 4.3: Blockchain-Verified Data Transactions
- Enabling Description: The system is used for supply chain management. When the host computer (e.g., a shipping clerk's device) assembles a data transaction (e.g., "goods received"), the TAS calculates a cryptographic hash of the transaction data. It then transmits this transaction to the central database server. The server, after its own validation, submits the transaction hash and a server signature to a distributed ledger (blockchain). This creates an immutable, auditable, and non-repudiable record of the transaction, timestamped and verified by the network, without storing the full, potentially sensitive, transaction data on the public chain.
- ```
flowchart TD
    A[Host Assembles Transaction] --> B{Calculate Hash (H1)}
    B --> C[Transmit Transaction + H1 to Server]
    C --> D{Server Validates}
    D --> E{Generate Server Signature (S1)}
    E --> F[Submit (H1, S1, Timestamp) to Blockchain]
    F --> G(Immutable Record Created)
```

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation with Cached Minimalist Forms
- Enabling Description: The TAS on the host computer is designed with a "persistent cache" mode. During a normal connection, the server not only sends the primary rich-UI form but also a parallel, lightweight, text-only "offline" version. If the host loses connectivity, the TAS automatically switches to this cached offline form. The user can continue to enter essential data. Assembled data transactions are stored locally in a secure queue. When connectivity is restored, the TAS automatically transmits the queued transactions to the server for processing. This ensures business continuity during network outages.
- ```
stateDiagram-v2
    state "Online" as ON
    state "Offline" as OFF
    state "Queued Transactions" as Q
    [*] --> ON
    ON --> OFF : Network Lost
    ON: Renders rich forms from Server
    OFF: Renders cached offline forms
    OFF --> Q : User saves transaction
    Q --> ON : Network Restored
    ON --> [*]
```

Derivatives Based on Claim 22: A Database Server System

The core concept involves a server that sends form/menu data streams to a host, receives a completed data transaction, and "explodes" it to update multiple database files.

Derivative 22.1: Microservices-Based Transaction Explosion
- Enabling Description: The database server is not a monolithic application but an architecture of containerized microservices managed by a platform like Kubernetes. When a data transaction is received, it is placed on a message queue (e.g., RabbitMQ, Kafka). A "Transaction Router" service consumes the message and, based on the transaction type, publishes it to multiple topic-specific channels. Dedicated microservices (e.g., Inventory Service, Customer Service, Billing Service) subscribe to these channels. Each service independently consumes the transaction data, extracts the parts relevant to its domain, and updates its own isolated database. This "explosion" is thus a decoupled, parallel process rather than a single procedural one.
- ```
graph TD
    A[Host Computer] -- Data Transaction --> B(API Gateway)
    B --> C(Message Queue)
    C --> D(Transaction Router)
    D -- Publishes to topics --> E(Topic: Inventory)
    D -- Publishes to topics --> F(Topic: Billing)
    D -- Publishes to topics --> G(Topic: Shipping)
    E --> H(Inventory Microservice) --> I[Inventory DB]
    F --> J(Billing Microservice) --> K[Billing DB]
    G --> L(Shipping Microservice) --> M[Logistics DB]
```

Combination Prior Art Scenarios

Combination 3.1: MQTT and JSON Schema for IoT Control
- Disclosure: The method of claim 1 is combined with the open-source MQTT (Message Queuing Telemetry Transport) protocol and JSON Schema standard. A central server (MQTT Broker) acts as the database server. A lightweight IoT device (host computer) subscribes to a control topic. To reconfigure the device, the server publishes a message containing a data stream structured according to a pre-defined JSON Schema. This schema defines the "form" — a set of configurable parameters for the device. The IoT device's TAS (an MQTT client with a JSON parser) receives this message, validates it against the schema, applies the new configuration, and assembles a "data transaction" (a JSON object with its current status) which it publishes back to a telemetry topic on the MQTT broker.
Combination 3.2: OPC UA and XML for Industrial Automation
- Disclosure: The system of claim 13 is implemented in an industrial control setting using the open-source OPC UA (Open Platform Communications Unified Architecture) standard. The "database server" is an OPC UA Server. The "host computer" is a Human-Machine Interface (HMI) panel on the factory floor. The OPC UA server provides a "Method" object that, when called by the HMI, returns an XML data stream. This XML defines a "form" for a complex machine operation (e.g., a recipe for a batch process). The HMI's TAS renders this form, the operator enters parameters, and the HMI assembles the inputs into another XML structure. It then calls a different "Method" on the OPC UA server, passing the completed transaction XML as an argument to initiate the manufacturing process.
Combination 3.3: HTTP/2 and GraphQL for Web Applications
- Disclosure: The server system of claim 22 is implemented using modern web standards. The "data stream representative of forms" is a GraphQL schema definition transmitted from the server to a client (host computer) over an HTTP/2 connection. The client application uses this schema to dynamically construct a user interface ("the form"). The user's input is assembled into a GraphQL mutation query (the "data transaction"). When this mutation is sent to the GraphQL server, the server's resolver function acts as the "transaction controller." This resolver "explodes" the transaction by making multiple, parallel calls to different backend services and databases (e.g., updating a user profile, posting an order, and clearing inventory) as defined in the resolver's logic, all in response to the single incoming GraphQL mutation.