Derivative works — US Patent 8069073

Defensive Disclosure and Prior Art Enhancement for US 8,069,073

Publication Date: May 1, 2026
Subject: Derivative Implementations and Obvious Variations of Bilateral Preference Matching Systems
Technology Domain: Decision Support Systems, Recommender Systems, Computational Social Science

This document serves as a defensive publication to disclose technical variations, alternative implementations, and cross-domain applications of the core concepts described in US Patent 8,069,073. The purpose is to place these variations into the public domain, thereby establishing them as prior art against future patent applications claiming these incremental or obvious improvements.

1. Derivatives based on Algorithmic & Component Substitution

1.1. Substitution of Conjoint Analysis with Bayesian Preference Elicitation

Enabling Description: The core matching system is implemented using a Bayesian inference model instead of traditional conjoint analysis. For the "party" and "counterparty," each forced-choice question is treated as evidence that updates a posterior probability distribution of their latent preference vectors. The system uses a utility function based on Thompson sampling or Upper Confidence Bound (UCB) algorithms to select the next "question" (i.e., the next trade-off to present), optimizing for maximum information gain (reduction in entropy) about the user's preferences. The "closeness-of-fit" is calculated not as a simple distance metric, but as the Kullback-Leibler (KL) divergence between the posterior distributions of the party and the counterparty, representing the information lost when approximating one profile with the other. A lower KL divergence signifies a better match.

Diagram:

sequenceDiagram
    participant User as Party/Counterparty
    participant System as Bayesian Engine
    participant ProfileDB as Preference Profile DB

    User->>System: Initial Interaction
    loop Question Selection & Profile Update
        System->>System: Select question via UCB to maximize info gain
        System->>User: Present forced-choice question
        User->>System: Provide response
        System->>System: Update posterior distribution of preference vector
        System->>ProfileDB: Store updated distribution (mean, variance)
    end
    System->>System: Calculate KL Divergence between Party and Counterparty distributions
    System->>User: Deliver ranked list of matches

1.2. Substitution of Static Profiles with Dynamic State-Space Models

Enabling Description: User preferences are not modeled as static vectors but as dynamic states in a time-series. The system uses a Kalman filter or a particle filter to model the preference profiles of both the party and counterparty. Each new response to a forced-choice question, or any other behavioral data (e.g., click-stream, dwell time), serves as a new measurement to update the state estimate of the user's preference vector. This allows the system to track preference drift over time. The "closeness-of-fit" is a time-dependent function calculated based on the predicted future states of the party and counterparty profiles, enabling the matching of individuals based on converging or diverging preference trajectories.

Diagram:

graph TD
    A[Start: Initial Profile P(t-1)] --> B{New Data at Time 't' <br>(Response, Behavior)};
    B --> C[Prediction Step <br> Predict P'(t) using state transition model];
    C --> D[Update Step <br> Correct P'(t) with new data to get P(t)];
    D --> E[Store Updated Profile P(t) <br> (Kalman Gain, Covariance Matrix)];
    E --> F{Match Analysis};
    F --> G[Compare P_party(t) with P_counterparty(t)];
    F --> H[Predict Future States <br> P_party(t+n) vs P_counterparty(t+n)];
    H --> I[Generate Match List based on Trajectory Convergence];

2. Derivatives based on Operational Parameter Expansion

2.1. Nanosecond-Scale Matching for High-Frequency Trading

Enabling Description: The bilateral matching system is implemented for algorithmic trading to match buy/sell orders. The "party" is an algorithmic agent representing a buy order with a complex preference profile regarding trade execution (e.g., preference for low latency vs. price stability vs. order size fulfillment). The "counterparty" is a sell-side agent. The "forced-choice questions" are simulated micro-trades presented to each agent's algorithm in a sandboxed environment to elicit their utility functions for different execution scenarios. The entire process, from preference elicitation to matching, occurs in microseconds. The matching engine is implemented on FPGAs (Field-Programmable Gate Arrays) to minimize latency. The closeness-of-fit determines which buy and sell agents are paired in a dark pool to execute a trade based on multi-attribute preference alignment, not just price.

Diagram:

graph LR
    subgraph FPGA Core
        A[Buy Order Agent Profile] -- Elicitation via Simulated Micro-Trades --> C(Conjoint Utility Function Gen);
        B[Sell Order Agent Profile] -- Elicitation via Simulated Micro-Trades --> D(Conjoint Utility Function Gen);
        C -- Utility Vector --> E{Matching Engine};
        D -- Utility Vector --> E;
    end
    E -- Ranked Match (sub-millisecond) --> F[Trade Execution];

2.2. Planetary-Scale Matching for Interstellar Colonization

Enabling Description: The system is scaled to solve a multi-generational, multilateral matching problem for seeding an extrasolar planet. The "parties" are millions of human candidates, with preference profiles covering genetic traits, psychological stability, and technical skills. The "counterparties" are simulated environmental and societal models for the target exoplanet, each with a "success profile" defining the ideal population characteristics for long-term viability. A third set of co-evaluators (AI governance models) also provides preference profiles for desired societal outcomes (e.g., collectivism vs. individualism). The system uses a massively parallel genetic algorithm to find an optimal founding population (the "match list") that maximizes the aggregate closeness-of-fit between the human candidates, the planetary success profiles, and the AI governance goals.

Diagram:

erDiagram
    CANDIDATE ||--o{ PROFILE : has
    PROFILE {
        string GeneticVector
        string PsychoVector
        string SkillVector
    }
    PLANET_MODEL ||--o{ SUCCESS_PROFILE : requires
    SUCCESS_PROFILE {
        string OptimalGeneticMix
        string RequiredSkillDistribution
    }
    AI_GOVERNANCE ||--o{ GOAL_PROFILE : desires
    GOAL_PROFILE {
        string SocietalOutcomeVector
    }
    MATCHING_ENGINE {
        string PopulationID
    }
    MATCHING_ENGINE }o--|| CANDIDATE : selects
    MATCHING_ENGINE }o--|| PLANET_MODEL : for
    MATCHING_ENGINE }o--|| AI_GOVERNANCE : aligns_with

3. Derivatives based on Cross-Domain Application

3.1. Aerospace: Autonomous Satellite Constellation Tasking

Enabling Description: In a distributed satellite constellation (e.g., for Earth observation), individual satellites or clusters act as "parties" with preference profiles based on their current state (e.g., fuel levels, sensor temperature, orbital position, available bandwidth). Ground-based mission requests (e.g., "image sector X with SAR at resolution Y") are the "counterparties," with preference profiles based on mission-critical parameters (e.g., urgency, required angle, time-on-target). Satellites and mission requests both undergo a preference elicitation process (e.g., "Is it better to use 10% extra fuel to get the image in 1 hour, or 2% fuel and get it in 3 hours?"). A decentralized matching algorithm, running on each satellite, computes the closeness-of-fit to autonomously bid on and select tasks, optimizing the overall health and effectiveness of the constellation without direct ground control for every decision.

Diagram:

stateDiagram-v2
    [*] --> Idle
    Idle --> Task_Evaluation: New Mission Request Received
    Task_Evaluation --> Bidding: High Closeness-of-Fit
    Task_Evaluation --> Idle: Low Closeness-of-Fit
    Bidding --> Executing: Task Awarded
    Executing --> Idle: Task Complete
    state Task_Evaluation {
        direction LR
        [*] --> Elicit_Mission_Preference
        Elicit_Mission_Preference --> Elicit_Satellite_Preference
        Elicit_Satellite_Preference --> Calculate_Fit
        Calculate_Fit --> [*]
    }

3.2. Agriculture Technology (AgTech): Symbiotic Crop-Microbe Pairing

Enabling Description: The system is used to match plant cultivars with beneficial soil microbes (e.g., nitrogen-fixing bacteria, mycorrhizal fungi). The "party" is the plant, with a preference profile derived from its genetic markers related to nutrient uptake, root structure, and stress response. The "counterparty" is a microbial strain, with a "success profile" derived from its metabolic outputs, colonization efficiency, and resilience to soil conditions. The "forced-choice questions" are laboratory-based experiments where plant tissue cultures are exposed to various nutrient trade-offs, and microbial cultures are tested for performance under different environmental stressors. The matching engine computes the optimal pairing to maximize symbiotic benefit, generating recommendations for inoculating specific fields with tailored microbial cocktails to boost crop yield and reduce the need for chemical fertilizers.

Diagram:

flowchart TD
    A[Plant Cultivar DNA Analysis] --> B(Generate Plant Preference Profile <br> Utility for N, P, K, H2O);
    C[Microbe Strain Lab Analysis] --> D(Generate Microbe Success Profile <br> Utility for Soil pH, Temp, Moisture);
    B --> E{Matching Engine};
    D --> E;
    E -- Calculate Symbiotic Fit Score --> F[Ranked List of Optimal Pairings];
    F --> G[Recommendation: Inoculate Field X with Microbe Strain Y];

3.3. Consumer Electronics: Dynamic Smart Home Ambiance

Enabling Description: A smart home system uses bilateral matching to personalize the environment. The "party" is the user, whose preference profile is dynamically generated from biometric data via a wearable sensor (e.g., heart rate variability, skin temperature, electrodermal activity). This profile reflects their latent psycho-physiological state (e.g., stressed, focused, relaxed). The "counterparty" is the smart home environment, which has a profile of possible "ambiance states" (combinations of lighting color temperature, ambient sound, and air temperature). The system learns the correlation between the user's biometric state and their explicit choices (e.g., adjusting the lights). It then uses this learned model to perform a continuous, real-time match, adjusting the home environment to the state that has the highest closeness-of-fit with the user's inferred needs, without requiring constant manual input.

Diagram:

sequenceDiagram
    participant Wearable
    participant UserProfile as Dynamic User Profile
    participant HomeSystem as Smart Home System
    participant Lights
    participant Audio

    loop Real-time Update
        Wearable->>UserProfile: Send Biometric Data (HRV, EDA)
        UserProfile->>UserProfile: Update Latent State Vector (e.g., 'Stressed')
        UserProfile->>HomeSystem: Transmit Updated State
        HomeSystem->>HomeSystem: Calculate Fit between User State and Ambiance Profiles
        HomeSystem->>Lights: Set optimal color temperature
        HomeSystem->>Audio: Play calming ambient sound
    end

4. Derivatives based on Integration with Emerging Tech

4.1. AI-Driven Reinforcement Learning for Question Optimization

Enabling Description: The system integrates a reinforcement learning (RL) agent (e.g., a multi-armed bandit or a deep Q-network) to dynamically generate the forced-choice questions. The "state" in the RL model is the current estimated preference profile of the user. The "action" is the selection of the next attribute trade-off to present as a question. The "reward" is the amount of information gained (e.g., variance reduction in the preference estimate) from the user's answer. Over time, the RL agent learns a policy that generates the most efficient and informative line of questioning for different types of users, minimizing the number of questions needed to achieve a high-confidence preference profile. This is applied to both the party and counterparty, creating adaptive and personalized preference elicitation.

Diagram:

graph TD
    A[Start: User Session] --> B(Current Estimated Profile (State S));
    B --> C{RL Agent Policy π(S)};
    C -- Selects Action A --> D[Present Optimal Question];
    D --> E{User Response};
    E -- Leads to --> F(New Estimated Profile (State S'));
    F --> G[Calculate Reward R <br> (e.g., Information Gain)];
    G --> C;
    B --> H{Matching Engine};

4.2. Blockchain-Verified Profiles for Decentralized Matching

Enabling Description: The generated preference profiles for both parties and counterparties are cryptographically signed and stored as non-fungible tokens (NFTs) or verifiable credentials on a public blockchain (e.g., Ethereum). The hash of the responses to the forced-choice questions is included in the token's metadata, ensuring immutability and tamper-proofing the profile. A smart contract acts as the decentralized matching engine. Parties can grant the smart contract permission to read their profile token. The closeness-of-fit calculation is performed on-chain, and the smart contract emits an event containing the ranked list of matches (e.g., wallet addresses of the best-fit counterparties). This creates a trustless, auditable matching system where users retain full ownership and control over their preference data.

Diagram:

classDiagram
    class Blockchain {
        +executeSmartContract()
    }
    class UserWallet {
        -privateKey
        +signTransaction()
        +ownProfileNFT
    }
    class ProfileNFT {
        +tokenId
        +metadataURI
        +ownerAddress
    }
    class ProfileMetadata {
        +preferenceVector
        +responsesHash
    }
    class MatchingContract {
        +address[] parties
        +address[] counterparties
        +match()
    }
    UserWallet "1" -- "1" ProfileNFT : owns
    ProfileNFT "1" -- "1" ProfileMetadata : points to
    UserWallet "1" -- "1" MatchingContract : interacts with
    Blockchain "1" -- "*" MatchingContract : executes

5. Derivatives based on The "Inverse" or Failure Mode

5.1. Anti-Matching for Risk Aversion and Conflict Avoidance

Enabling Description: The system is configured to identify and flag the worst possible pairings. Instead of ranking matches from highest to lowest closeness-of-fit, it ranks them from lowest to highest (i.e., maximizing the distance metric between preference profiles). This "anti-match" or "conflict prediction" system is applied in high-stakes team formation, such as for astronaut crews, special operations teams, or corporate boards. The preference profiles include attributes related to communication style, risk tolerance, and conflict resolution methods. By identifying pairings with the largest divergence in these critical areas, the system helps organizations prevent catastrophic team failures by screening out incompatible individuals before they are placed in a mission-critical environment.

Diagram:

flowchart TD
    A[Input: Pool of Candidates];
    B[Generate Preference Profiles for all Candidates];
    A --> B;
    B --> C{Conflict Engine};
    C -- For each possible pair (i, j) --> D[Calculate Distance Metric D(P_i, P_j)];
    D --> E[Rank Pairs by Descending Distance Score];
    E --> F[Output: Ranked List of High-Conflict Pairs to Avoid];

5.2. Graceful Degradation using Profile Quantization

Enabling Description: A "low-power" or "limited-functionality" version of the invention is designed for edge computing devices with limited battery or processing power. The high-dimensional preference vectors generated by the full conjoint analysis are compressed using vector quantization. For example, a 128-dimension floating-point vector is mapped to an 8-bit integer codeword from a pre-computed codebook. The matching process on the edge device then involves a computationally inexpensive Hamming distance calculation between the codewords of the party and counterparty. This provides a fast, low-fidelity match. If a promising match is found, the device can expend more power to request a full-precision calculation from a cloud server. This allows the system to operate continuously in a low-power scanning mode and escalate to high-precision mode only when necessary.

Diagram:

graph TD
    subgraph Cloud
        A[Full Conjoint Analysis] --> B(Generate 128-dim FP32 Vector);
        B --> C[Train VQ Codebook];
    end
    subgraph Edge Device (Low Power)
        D[Abridged Questions] --> E(Generate 128-dim FP32 Vector);
        C --> F{Quantizer};
        E --> F;
        F --> G[Store 8-bit Codeword];
        G --> H{Low-Cost Matching <br> (Hamming Distance)};
        H -- Potential Match --> I{Escalate?};
        I -- Yes --> J[Request Full Match from Cloud];
        I -- No --> H;
    end

6. Combination Prior Art Scenarios with Open Source Standards

Combination with FHIR (Fast Healthcare Interoperability Resources): The bilateral matching system is implemented to match patients with clinical trials. A patient's electronic health record (EHR), structured as a set of FHIR resources (e.g., Patient, Condition, Observation), serves as the base data for the "party" profile. The clinical trial's protocol, also encoded using FHIR resources (ResearchStudy, ResearchSubject), defines the "counterparty" profile. The system administers forced-choice questions to both the patient (regarding their preferences for treatment burden, travel, side-effect risks) and the principal investigator (regarding their preferences for ideal subject compliance, comorbidity tolerance). The resulting match list provides patients and physicians with a ranked list of trials that are not only clinically appropriate but also behaviorally and preferentially aligned.
Combination with GraphQL: The entire client-server communication for the preference elicitation and matching service is defined by a public GraphQL schema. This allows any third-party application to integrate the matching service. The schema defines mutations like submitPartyResponses(questions: [ID!], answers: [Int!]) and queries like getRankedMatches(partyID: ID!, counterpartySet: [ID!]). This decouples the front-end user interface from the back-end matching engine and establishes a standardized, open-source method for interacting with any bilateral preference matching system built on the core principles of US 8,069,073.
Combination with Apache Mahout and Spark: The core computational engine for generating preference profiles and calculating closeness-of-fit is built using Apache Mahout running on an Apache Spark cluster. For a large dataset of parties and counterparties, the system uses Spark's distributed processing to run the conjoint analysis in parallel. The resulting utility vectors are stored in a distributed DataFrame. The "closeness-of-fit" calculation is implemented as a broadcast join between the party and counterparty DataFrames, allowing the system to scale to hundreds of millions of users and perform the complete matching analysis in minutes rather than days. This demonstrates the application of the patented method using widely available, open-source distributed computing tools.