Derivative works — US Patent 12375890

This document presents a series of defensive disclosures derived from the core claims of US Patent 12,375,890. The intent is to preemptively place variations and improvements of the patented technology into the public domain, thereby establishing prior art against future, similar patent applications by third parties.

Each disclosure provides a technical "Enabling Description" sufficient for a person having ordinary skill in the art (PHOSITA) to practice the variation. These disclosures are organized according to a derivation framework.

Axis 1: Material & Component Substitution

Derivative 1.1: Browser-Based WebRTC Client

Enabling Description: This variation replaces a proprietary, downloadable Push-to-Talk-over-Cellular (POC) software application with a browser-based client utilizing the WebRTC open standard. The control device generates a cryptographically unique URL for each non-subscriber invitation. When the non-subscriber clicks this link, it opens their device's default web browser and loads a JavaScript application. This application uses the WebRTC API to access the device's microphone and establish a peer-to-peer or server-mediated (via a TURN/STUN server managed by the control device) real-time media stream with the POC talkgroup. Session management and authentication are handled via WebSockets connected to the control device. Access is revoked by invalidating the session token on the server and closing the WebSocket connection.

Mermaid Diagram:

sequenceDiagram
    participant Admin as Subscriber Device
    participant Server as Control Device
    participant NonSub as Non-Subscriber Device

    Admin->>Server: Invite NonSub (PhoneNumber) to Talkgroup
    Server->>Server: Generate Unique WebRTC URL & Auth Token
    Server->>NonSub: SMS: "Join Talkgroup: https://poc.service/join?token=XYZ"
    NonSub->>Server: User clicks link (HTTP GET /join?token=XYZ)
    Server-->>NonSub: Serve WebRTC Client (HTML/JS)
    NonSub->>Server: JS Client connects via WebSocket w/ Token
    Server-->>NonSub: WebSocket connection established
    NonSub->>Server: WebRTC: Initiate media session
    Server->>NonSub: WebRTC: Connect to talkgroup audio bridge
    Note right of NonSub: User can now PTT in browser

Derivative 1.2: Lightweight MQTT-Signaled Client

Enabling Description: To support low-power or constrained devices (e.g., wearables, IoT sensors with voice capabilities), this derivative substitutes the standard session initiation protocol (SIP) with the Message Queuing Telemetry Transport (MQTT) protocol for signaling. The control device also functions as an MQTT broker. The invitation link provides credentials for the non-subscriber's device to connect to the MQTT broker and subscribe to a specific talkgroup topic (e.g., /talkgroups/incident-123/presence). PTT requests are published as lightweight messages on a control topic, and the server manages the UDP-based RTP media streams separately. This architecture minimizes the persistent connection's overhead, conserving battery and bandwidth.

Mermaid Diagram:

flowchart TD
    subgraph Non-Subscriber Device
        A[POC App]
    end
    subgraph Control_Device
        B[MQTT Broker]
        C[RTP Audio Mixer]
    end
    subgraph Other_Participants
        D[...]
    end

    A -- "Connects with Temp Credentials" --> B
    A -- "Subscribes to /tg-123/presence" --> B
    A -- "Publishes PTT_START to /tg-123/control" --> B
    B -- "Notifies Mixer" --> C
    C -- "Opens UDP RTP Stream" --> A
    A -- "Sends Audio" --> C
    C -- "Mixes & Distributes Audio" --> D

Derivative 1.3: Decentralized Talkgroup Management via Mesh Network

Enabling Description: This disclosure describes a system where the control device is not a centralized server but a distributed function running on subscriber devices themselves. Using a mobile ad-hoc network (MANET) protocol (e.g., Wi-Fi Direct, Bluetooth Mesh), a subscriber device with administrative rights can directly grant access to a nearby non-subscriber device. The "invitation" is a direct, encrypted peer-to-peer transmission containing the talkgroup's cryptographic keys, a temporary device certificate, and a list of known peer nodes. The non-subscriber's device downloads a client app that allows it to join the mesh and route PTT audio directly to other participants without passing through a central server. Access is revoked when the temporary certificate expires.

Mermaid Diagram:

graph TD
    subgraph Talkgroup Mesh
        S1(Subscriber 1 - Admin)
        S2(Subscriber 2)
        S3(Subscriber 3)
        NS(Non-Subscriber)
    end

    S1 -- "Direct P2P Invitation (Wi-Fi Direct)" --> NS
    NS -- "Joins Mesh" --> S2
    NS -- "Joins Mesh" --> S3
    S1 <--> S2
    S2 <--> S3
    S1 <--> S3

    style S1 fill:#f9f,stroke:#333,stroke-width:2px
    style NS fill:#ccf,stroke:#333,stroke-width:2px

Axis 2: Operational Parameter Expansion

Derivative 2.1: Industrial IoT Control Channel Management

Enabling Description: At an industrial scale, the system manages temporary access to control channels for massive IoT deployments (e.g., a city's smart lighting grid). The "talkgroup" is a logical control channel (e.g., a multicast IP address) for thousands of luminaire controllers. A field technician (subscriber) needs to perform maintenance in a specific sector. They use their device to request temporary control access for that sector from the control device (grid management server). The server grants access by sending a time-limited digital certificate and the sector's specific control channel parameters to the technician's device (non-subscriber in the context of that specific channel). The "POC application" is a grid control app that uses these credentials to send authenticated CoAP (Constrained Application Protocol) commands to the lights.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Inactive
    Inactive --> Provisioned: Technician requests access
    Provisioned --> Active: Tech app downloads cert & params
    Active --> Active: Send CoAP control commands
    Active --> De-provisioned: Timer expires
    De-provisioned --> [*]: Access revoked

Derivative 2.2: Deep-Sea Acoustic Modem Provisioning

Enabling Description: This derivative applies the invention to extreme pressure and communication environments, specifically for deep-sea submersible drones. A surface vessel's control system (control device) manages communication. An operator (subscriber) needs to grant a third-party inspection drone (non-subscriber) temporary access to the primary drone swarm's acoustic communication network (talkgroup). The control system transmits a low-bandwidth acoustic message containing a link. This "link" is a command that instructs the drone to download a specific firmware module for its acoustic modem from an onboard repository. This module contains the necessary frequency hopping sequences and authentication keys to join the talkgroup for a predetermined time.

Mermaid Diagram:

sequenceDiagram
    participant Operator as Surface Console
    participant Vessel as Control Device
    participant Drone as Non-Subscriber Drone

    Operator->>Vessel: Grant Drone access to AcousticNet-Alpha
    Vessel->>Drone: Acoustic Msg: 'CMD:LOAD_FIRMWARE(ID=7, KEY=ABC)'
    Drone->>Drone: Access internal storage
    Drone->>Drone: Load Acoustic Modem Firmware v7
    Drone->>Vessel: Acoustic Msg: 'ACK:READY'
    Note right of Drone: Drone can now communicate on<br/>AcousticNet-Alpha

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - Temporary Satellite Constellation Access

Enabling Description: In the context of satellite fleet management, a primary operator (subscriber) uses a ground station management console to grant a third-party satellite (e.g., a research satellite needing to downlink data) temporary access to a specific communication channel within its constellation. The control device (ground station network scheduler) calculates an available time-division multiple access (TDMA) slot and generates a set of time-limited cryptographic keys. It transmits this "invitation" to the non-subscriber satellite during a scheduled contact window. The "link" is the command payload containing the slot assignment and keys, and the "POC application" is the satellite's existing communication subsystem, which is reconfigured by this command. Access automatically terminates when the TDMA slot window ends.

Mermaid Diagram:

gantt
    title Satellite Constellation TDMA Access
    dateFormat  HH:mm:ss
    axisFormat  %H:%M:%S
    section Ground Control
    Grant Access   :done, g1, 14:30:00, 10s
    Transmit Keys  :done, g2, 14:30:10, 30s
    section Non-Subscriber Satellite
    Receive & Reconfigure :crit, r1, 14:31:00, 45s
    Active Downlink Window :active, d1, 14:32:00, 5m
    Access Expires : r2, 14:37:00, 1s

Derivative 3.2: AgTech - Dynamic Drone Swarm Tasking

Enabling Description: A farm owner (subscriber) uses a farm management platform (control device) to hire a third-party drone spraying service (non-subscriber). To grant access, the owner selects a specific field and timeframe. The platform generates a task package and sends a link to the drone service operator. The link leads to a secure endpoint where the operator can download the package. This package is the "POC application" configuration; it includes field boundary coordinates (GeoJSON), flight path instructions, the specific radio frequency and protocol for communicating with on-site weather sensors, and a time-limited token to upload completion data back to the platform.

Mermaid Diagram:

erDiagram
    FARM_OWNER ||--o{ TASK : Creates
    TASK {
        string FieldID
        datetime StartTime
        datetime EndTime
    }
    TASK ||--|{ TASK_PACKAGE : Generates
    TASK_PACKAGE {
        string DownloadURL
        string AccessToken
        json GeoJSON_Boundaries
    }
    DRONE_OPERATOR ||--|{ TASK_PACKAGE : Downloads

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Predicted Access Provisioning

Enabling Description: The control device incorporates a predictive AI model trained on organizational data (calendars, personnel location, past incident reports). For a scheduled "multi-agency drill," the AI identifies all invitees from the calendar event. 30 minutes before the event, it automatically sends commands to grant talkgroup access to all participants who are not already subscribers. The AI also monitors the talkgroup for sentiment and keyword analysis; if it detects escalating urgency, it can pre-emptively extend the access duration or suggest inviting other relevant personnel (e.g., a nearby hazmat specialist) based on their location and certifications.

Mermaid Diagram:

flowchart LR
    A[Calendar Event: "Drill"] -- "Event Data" --> B(AI Model)
    C[Personnel Database] -- "Location/Skills" --> B
    B -- "Predicts Participants" --> D{Is User Subscriber?}
    D -- "No" --> E[Grant Temp Access]
    E --> F[Send Invite Link]
    D -- "Yes" --> G[Do Nothing]
    H[Live Talkgroup Audio] --> B
    B -- "Detects 'HAZMAT'" --> I[Suggest Inviting Specialist]

Derivative 4.2: Blockchain-Based Access Auditing

Enabling Description: Every action in the system is recorded on a permissioned blockchain (e.g., Hyperledger Fabric) for immutable auditing. When a subscriber invites a non-subscriber, the control device mints a non-fungible token (NFT) representing the temporary access grant. This NFT contains the user's identifier, the talkgroup ID, and the expiration time as metadata. The invitation link allows the non-subscriber to download the POC client and claim the NFT to their client's wallet. The POC client presents this NFT to the control device as a bearer token for authentication. When the timer expires, the smart contract governing the NFT automatically flags it as "expired," preventing further use.

Mermaid Diagram:

sequenceDiagram
    participant Admin
    participant ControlDevice
    participant Blockchain
    participant NonSubscriber

    Admin->>ControlDevice: Invite user
    ControlDevice->>Blockchain: Deploy AccessGrant Smart Contract (NFT)
    Blockchain-->>ControlDevice: NFT Token ID
    ControlDevice->>NonSubscriber: Send link to claim Token ID
    NonSubscriber->>ControlDevice: Claim Token
    ControlDevice->>Blockchain: Transfer NFT to NonSubscriber's wallet
    NonSubscriber->>ControlDevice: Authenticate with NFT
    Note over ControlDevice,Blockchain: Access granted & logged

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Fail-Safe Access Revocation with Client-Side Timer

Enabling Description: This derivative prioritizes secure de-provisioning. The configuration file downloaded by the non-subscriber's POC application contains an encrypted "time-to-live" (TTL) value and a public key for the control server. The client application must successfully perform a signed heartbeat check-in with the server at an interval less than the TTL (e.g., every 5 minutes for a 15-minute TTL). If the client cannot reach the server or if the server's response has an invalid signature, the client initiates a "fail-safe" mode: it immediately purges all talkgroup configurations, deletes the cryptographic keys from its keychain, and uninstalls any associated helper tools. This ensures a device does not remain "hot" if the central server goes offline.

Mermaid Diagram:

stateDiagram-v2
    state Active {
        [*] --> Heartbeat_OK
        Heartbeat_OK --> Heartbeat_OK: Timer < TTL
        Heartbeat_OK --> Purge_Config: Heartbeat fails
    }
    [*] --> Active: Initial Provisioning
    Purge_Config --> [*]: Access revoked locally

Derivative 5.2: Graceful Degradation via Dynamic Codec Switching

Enabling Description: In a network-constrained environment (detected by the control device via high packet loss or latency metrics), the system enters a "low-functionality" mode. The invitation link sent to new non-subscribers points to a lightweight version of the POC application. For existing clients, the control server sends a signaling message (e.g., a SIP re-INVITE) that commands them to switch to a low-bitrate, high-compression audio codec (e.g., Opus at 8 kbps or Speex). All non-essential features like presence indicators, file sharing, and high-definition voice are disabled server-side, ensuring the core PTT voice functionality remains intact.

Mermaid Diagram:

graph TD
    A(Control Device Monitors Network) --> B{Latency > 200ms?};
    B -- Yes --> C[Enter Degraded Mode];
    C --> D[Send Re-INVITE to all clients];
    D --> E[Clients switch to Low-Bitrate Codec];
    C --> F[New invite links point to Lightweight App];
    B -- No --> G[Maintain Normal Operation];

Combination Prior Art Scenarios with Open-Source Standards

Combination with Matrix Protocol: The control device is a Matrix Synapse homeserver. A subscriber with appropriate power levels in a Matrix room uses a custom command /invite-temp @user:server.com 1h to grant access. A bot on the homeserver receives this, generates a temporary guest registration token, and sends an SMS/email to the user with a link. The link opens a web-based Element client (an open-source Matrix client) which uses the token to register a temporary guest account and automatically join the specified room. The account is set to be automatically deactivated by the homeserver after the specified duration (1 hour). This leverages the Matrix specification's open federation and guest access features.
Combination with FreeSWITCH and WebRTC: The Push-to-Talk system is implemented as a conference bridge within the open-source FreeSWITCH telephony platform. An administrator uses a web interface to create a temporary access link for a specific conference. The FreeSWITCH server generates a unique URL that embeds a time-limited token. When a non-subscriber clicks the link, their browser is directed to a simple HTML5 page that uses JavaScript to establish a direct WebRTC connection to FreeSWITCH's mod_verto WebSocket endpoint. The token is used for authentication, and the user is placed into the correct audio bridge. No software installation is required, relying entirely on the open standards of WebRTC and WebSockets.
Combination with Open Source Trusted Platform Module (TSS): The downloaded POC application for the non-subscriber device leverages the device's Trusted Platform Module (TPM) via an open-source software stack like tpm2-tss. The initial link provides a one-time provisioning package. The client application generates a new cryptographic keypair within the TPM and uses the TPM's attestation feature to send a signed quote back to the control device, proving the key's integrity. The control device then issues a short-lived certificate tied to this TPM-bound key. All subsequent communication must be signed by this key, ensuring that the access credentials cannot be easily cloned or moved to another device. Access revocation involves the control device adding the client's certificate to a Certificate Revocation List (CRL).