Derivative works — US Patent 6314420

Defensive Disclosure: Derivative Embodiments of Collaborative and Adaptive Search

Publication Date: May 11, 2026
Reference Patent: US 6,314,420 B1 ("Collaborative/adaptive search engine")
Objective: This document discloses a plurality of derivative implementations, applications, and enhancements of the core concepts described in US Patent 6,314,420. The purpose of this disclosure is to establish prior art against future patent claims on incremental variations of dual-mode (demand/continuous) search systems and those integrating collaborative and content-based filtering.

Derivatives Based on Independent Claim 1: A System for Filtering and Responding to Queries

1. Material & Component Substitution

Derivative 1.1: In-Memory Graph Database for Collaborative Filtering
- Enabling Description: The filtering system is implemented using an in-memory graph database (e.g., Neo4j, RedisGraph) instead of a traditional relational database. User profiles, "informons" (information entities), and feedback events (ratings, views, shares) are modeled as nodes and edges. The "wire" query leverages graph traversal algorithms (e.g., PageRank, k-nearest neighbors) to determine relationships between users and content in real-time. This component substitution allows for significantly faster collaborative filtering by treating user similarity and content relevance as direct relationships within the graph, rather than requiring complex table joins. The "demand" search component queries a separate, document-oriented search index (e.g., Elasticsearch), but its results can be re-ranked using a fast, single-depth traversal from the user's node in the graph database.
- ```
graph TD
    A[User Query] --> B{Query Processor};
    B -- Demand Query --> C[Elasticsearch Index];
    B -- Wire Query --> D[In-Memory Graph DB];
    D -- Traversal & Ranking --> E[Ranked Wire Results];
    C --> F[Initial Demand Results];
    F -- User Node ID --> D;
    D -- Collaborative Re-ranking --> G[Re-ranked Demand Results];
    E --> H[User];
    G --> H;
```
Derivative 1.2: Serverless Function Architecture
- Enabling Description: The entire system is decomposed into a set of serverless functions (e.g., AWS Lambda, Google Cloud Functions). The "query processor" is a function triggered by an API Gateway endpoint. It determines the query type and invokes either a "demand-search" function or a "wire-update" function. The "wire" is not a continuously running process but a stateful entry in a key-value store (e.g., DynamoDB) that tracks user interest. A separate, time-triggered function periodically crawls for new informons, processes them, and asynchronously updates the result lists for all active "wires" by comparing informon content against stored wire profiles. This substitution of monolithic services with ephemeral functions reduces operational overhead and allows for massive, independent scaling of the demand and wire-processing components.
- ```
sequenceDiagram
    participant User
    participant APIGateway as API Gateway
    participant QueryProcessor [λ Query Processor]
    participant DemandSearch [λ Demand Search]
    participant WireStore [DynamoDB Wire Table]
    participant Crawler [λ Crawler]

    User->>APIGateway: POST /query
    APIGateway->>QueryProcessor: Invoke
    QueryProcessor->>WireStore: Check for existing wire
    alt Wire Exists
        QueryProcessor->>WireStore: Read latest results
        WireStore-->>User: Return cached wire results
    else Demand Search
        QueryProcessor->>DemandSearch: Invoke
        DemandSearch-->>User: Return immediate results
    end
    Note right of Crawler: Triggered every 5 mins
    Crawler->>WireStore: Update all active wires with new informons
```

2. Operational Parameter Expansion

Derivative 1.3: Planetary-Scale Redundant File System Search
- Enabling Description: The system is applied to a globally distributed, redundant file system (e.g., IPFS). "Informons" are immutable, content-addressed data blocks. A "wire" query acts as a persistent subscription to a Merkle-DAG, receiving updates as new versions are published. The "demand" search uses a distributed hash table (DHT) for fast lookups of known content identifiers (CIDs). Collaborative feedback is collected from peer nodes that have replicated the data, and feedback is cryptographically signed by each user's keypair. The system operates at an extreme scale, managing petabytes of data across thousands of untrusted nodes, with latency-tolerant "wire" updates propagated through a gossip protocol.
- ```
flowchart TD
    subgraph UserNode1
        A[User Query] --> B{Query Processor}
        B --> C[Demand Search via DHT]
        B --> D[Subscribe to Wire via GossipSub]
    end
    subgraph UserNode2
        F[User Feedback] --> G{Sign Feedback}
        G --> H[Publish to DHT]
    end
    subgraph Network
        I((IPFS Network))
        C -- CID Lookup --> I
        D -- Pub/Sub Channel --> I
        H -- Put Record --> I
    end
    I -- New Informon Blocks --> D
```
Derivative 1.4: Real-Time RF Spectrum Analysis
- Enabling Description: The system operates on high-frequency radio signal data. "Informons" are discrete signal patterns (e.g., a specific modulation type, frequency hopping sequence) captured by a distributed network of software-defined radios (SDRs). A "demand" search queries a historical database of categorized signals. A "wire" constitutes a continuous monitoring task for a specific signal signature in a noisy RF band. Collaborative filtering is performed by combining confidence scores from multiple SDR nodes that detect a similar signal pattern. The system functions at extreme frequencies (GHz range) and requires real-time processing to distinguish between known, unknown, and adversarial signals.
- ```
stateDiagram-v2
    [*] --> Idle
    Idle --> DemandSearch: onQuery(type=demand)
    DemandSearch --> Idle: return results
    Idle --> WireMonitoring: onQuery(type=wire, signature)
    WireMonitoring --> SignalDetected: onSignatureMatch
    SignalDetected --> Correlating: aggregate feedback from peer nodes
    Correlating --> ResultPublished: onQuorum
    ResultPublished --> WireMonitoring
    WireMonitoring --> Idle: onCancel
```

3. Cross-Domain Application

Derivative 1.5: Genomic Data Analysis
- Enabling Description: In bioinformatics, a "demand" search allows a researcher to find known gene sequences or protein structures in a large genomic database (e.g., NCBI BLAST). A "wire" is a persistent query that continuously scans newly sequenced genomes for a specific, novel genetic marker or mutation. Collaborative feedback is sourced from annotations and experimental results submitted by other researchers. If multiple independent labs associate a specific "wire" result (a newly found gene sequence) with a similar biological function, the system increases the relevance ranking of that result for all subscribers to that "wire."
- ```
classDiagram
class GenomicSearchSystem {
    +processQuery(query: UserQuery)
}
class QueryProcessor {
    -db: GenomicDatabase
    -wireStore: ActiveWires
    +routeQuery(query)
}
class DemandSearch {
    +findSequence(sequence: string)
}
class WireFilter {
    +scanNewGenomes(genome: GenomeData)
}
class CollaborativeFeedback {
    +updateRanking(markerId, annotation)
}
GenomicSearchSystem *-- QueryProcessor
QueryProcessor --> DemandSearch
QueryProcessor --> WireFilter
WireFilter o-- CollaborativeFeedback
```
Derivative 1.6: Automated Legal E-Discovery
- Enabling Description: In the legal field, a "demand" search is used by an attorney to find specific documents containing keywords relevant to a case from a large corpus of evidence. A "wire" is set up to continuously monitor incoming documents (e.g., new emails, scanned records) for privilege, confidentiality, or relevance to a specific legal argument. The collaborative feedback mechanism is implemented through a team of paralegals reviewing documents. When multiple reviewers independently tag a document found by a "wire" as "highly relevant," the system automatically prioritizes similar, unreviewed documents for the entire legal team.
- ```
flowchart LR
    A[Document Ingestion] --> B[Content Indexing];
    C[Attorney Query] --> D{Query Processor};
    D -- Demand --> B;
    D -- Create Wire --> E[Wire Profile Store];
    B -- Matched by Wire --> F[Review Queue];
    G[Paralegal Review] --> H{Relevance Feedback};
    H -- High Relevance --> I[Collaborative Filter];
    I -- Boost Priority --> F;
```

4. Integration with Emerging Tech

Derivative 1.7: AI-Driven Predictive Wire Creation
- Enabling Description: The system integrates a machine learning model (e.g., a recurrent neural network or transformer) that analyzes the sequence of a user's "demand" queries. If the model predicts a high probability that the user's information need is long-term (e.g., queries about "Model XYZ phone specs" followed by "Model XYZ phone reviews"), it proactively suggests creating a "wire" for that topic. The collaborative feedback data is used as a training signal for the model; wires that are accepted and receive positive user engagement reinforce the prediction pathways that led to their creation.
- ```
sequenceDiagram
    participant User
    participant SearchSystem
    participant PredictionModel as AI Model

    User->>SearchSystem: Demand Query 1
    SearchSystem->>PredictionModel: Log Query 1
    User->>SearchSystem: Demand Query 2
    SearchSystem->>PredictionModel: Log Query 2
    PredictionModel->>SearchSystem: Predict Long-Term Interest: Topic "T"
    SearchSystem->>User: Suggest creating a 'wire' for Topic "T"?
    User->>SearchSystem: Accept
```
Derivative 1.8: Blockchain-Verified Collaborative Feedback
- Enabling Description: The feedback system is integrated with a public blockchain. When a user submits a rating or review for an "informon," a hash of the feedback is recorded on the blockchain in a transaction signed by the user's private key. This creates an immutable, tamper-proof audit trail of all collaborative data. The filtering system prioritizes feedback from users with a long-standing, consistent history on the chain, effectively creating a reputation system. This prevents Sybil attacks where an adversary creates numerous fake accounts to manipulate search rankings, as each identity would need to expend resources (i.e., "gas fees") to submit feedback.
- ```
graph TD
    A[User rates Informon] --> B{Create Feedback Payload};
    B --> C[Sign Payload with User's Private Key];
    C --> D[Submit as Blockchain Transaction];
    D --> E((Blockchain Ledger));
    F[Filter System] --> G{Read Feedback from Ledger};
    G --> H[Verify Transaction Signature];
    H --> I[Apply Weighted Feedback to Wire];
```

5. The "Inverse" or Failure Mode

Derivative 1.9: Graceful Degradation under Load
- Enabling Description: The system is designed to operate in a "graceful degradation" mode. A central load balancer monitors the query queue length and the processing latency of the collaborative/content-based filter for the "wire" services. If latency exceeds a predefined threshold (e.g., 500ms), the query processor is automatically reconfigured to treat all incoming queries as "demand" searches. It bypasses the "wire" system entirely and serves results directly from the static content index. During this mode, collaborative feedback is still collected but is queued for batch processing once the system load returns to normal. This ensures high availability for basic search functionality at the expense of the more resource-intensive continuous and personalized features.
- ```
stateDiagram-v2
    state "Normal Operation" as Normal {
        state "Process as Wire" as Wire
        state "Process as Demand" as Demand
    }
    state "Degraded Mode" as Degraded

    [*] --> Normal
    Normal --> Degraded: on HighLatency
    Degraded --> Normal: on LowLatency

    Normal: onQuery -> checkWire()
    checkWire() --> Wire: if wireExists
    checkWire() --> Demand: else

    Degraded: onQuery -> processAsDemand()
```

Combination Prior Art Scenarios

Scenario 1: Combination with Apache Lucene and Kafka
- Disclosure: A search system is constructed using the open-source Apache Lucene library as the core "demand" search engine. User queries are ingested through an Apache Kafka topic. A "Query Processor" service consumes from this topic. For demand searches, it queries the Lucene index directly. To create a "wire," it stores the query profile and user ID in a database. A separate fleet of "informon processing" services, also consuming from a Kafka topic of newly discovered documents, compares each document against the stored wire profiles. If a match occurs, the result is pushed to a user-specific Kafka topic, which the user's client is subscribed to. Collaborative feedback is collected on yet another Kafka topic and is used by a stream processor (e.g., Kafka Streams) to continuously update a relevance model used by the informon processors. This architecture is an obvious combination of the system in '420 with standard, widely used open-source data processing components.
Scenario 2: Combination with ActivityPub Federated Social Protocol
- Disclosure: The system is implemented within a federated social network operating on the W3C ActivityPub standard. An "informon" is any Note or Article object. A "demand" search queries a user's home server for content. A "wire" is implemented by sending a Follow activity to a synthetic Service actor representing the query. This actor, upon discovering new, relevant content from the federated network, pushes it to its followers' inboxes as an Announce activity. Collaborative feedback is derived directly from social signals native to the protocol, such as Like and Announce activities from other users in the federation. A user's filtering is thus improved by the explicit actions of others who follow similar hashtag or topic actors, a direct implementation of the '420 method using a pre-existing, open protocol.
Scenario 3: Combination with TensorFlow for Collaborative Ranking
- Disclosure: The collaborative filtering component of the system is implemented using the open-source TensorFlow machine learning framework. User and informon profiles are represented as high-dimensional vectors (embeddings). A deep neural network is trained on historical user feedback data (clicks, ratings) to predict the probability of a user positively engaging with a given informon. The output of this model is the primary signal for ranking results in a "wire" search. The content-based filtering aspect serves as a pre-filtering step to select candidate informons which are then passed to the TensorFlow model for collaborative re-ranking. This represents a straightforward application of a standard, open-source machine learning toolkit to implement the collaborative feedback and relevance determination steps described in claim 1 and claim 9 of the '420 patent.