Derivative works

Defensive Disclosure and Prior Art Generation for POC Talkgroup Access Management

Publication Date: May 8, 2026
Reference Patent: US 11,997,568 B2
Field: Telecommunications, Secure Group Communication, Network Provisioning

This document discloses a series of methods, systems, and architectural variations related to the temporary and dynamic provisioning of non-subscriber devices into secure communication groups. These disclosures are intended to enter the public domain to serve as prior art against future patent applications claiming incremental or obvious variations of the concepts described in US patent 11,997,568.

---

Derivative Set 1: Architectural and Component Substitutions

1.1. Serverless Control Plane Architecture

• Enabling Description: The "control device" is not a monolithic server but a collection of ephemeral, serverless functions (e.g., AWS Lambda, Azure Functions) triggered by API Gateway events. A request from a subscriber device to add a non-subscriber is an HTTPS POST request that triggers a "Provisioning" function. This function generates a signed JSON Web Token (JWT) with an expiration claim (exp), stores the grant in a NoSQL database (e.g., DynamoDB), and triggers a "Notification" function. The Notification function dispatches the communication (SMS, email) containing a URL. This URL points to a static web page that includes the JWT and a link to a Progressive Web App (PWA) client, which uses the JWT to authenticate with the POC backend. Revocation is handled by a time-to-live (TTL) attribute on the database record, which triggers a "Revocation" function upon expiry to invalidate the JWT or remove the user from the talkgroup's Access Control List (ACL).

• Mermaid Diagram:

  sequenceDiagram
      participant Sub_Device as Subscriber Device
      participant APIGW as API Gateway
      participant Prov_Func as Provisioning Lambda
      participant Notif_Func as Notification Lambda
      participant DB as DynamoDB
      participant NonSub_Device as Non-Subscriber Device
  
      Sub_Device->>APIGW: POST /invite {contact_info}
      APIGW->>Prov_Func: Trigger event
      Prov_Func->>DB: Write grant with TTL
      Prov_Func->>Notif_Func: Invoke with contact_info & signed_url
      Notif_Func->>NonSub_Device: Send SMS with link
      NonSub_Device->>APIGW: GET /join_session
      APIGW-->>NonSub_Device: Return PWA with embedded JWT
      Note right of DB: TTL expires on grant record
      DB->>APIGW: Trigger /revoke endpoint
      APIGW-->>Prov_Func: Invalidate JWT / remove from ACL
  

1.2. WebRTC-Based Thin Client

• Enabling Description: This variation eliminates the need for a downloadable native application. The control device, upon granting access, transmits a URL to the non-subscriber. This URL opens a web application in a standard mobile or desktop browser. The application utilizes WebRTC (Web Real-Time Communication) APIs for all media (audio/video) and data channel communication. The control device acts as a signaling server (e.g., using WebSockets) to manage session establishment and a STUN/TURN server to facilitate NAT traversal. The "talkgroup" is a WebRTC mesh or MCU-based conference room. Access is controlled by a time-limited authentication token passed in the URL, which the signaling server validates. Revocation occurs when the token expires or is invalidated by the server.

• Mermaid Diagram:

  flowchart TD
      A[Subscriber Device] -- 1. Request Invite --> B{Control Device / Signaling Server};
      B -- 2. Send Unique URL --> C[Non-Subscriber Device];
      C -- 3. Opens URL in Browser --> D[Web App Client];
      D -- 4. WebSocket Handshake w/ Token --> B;
      B -- 5. STUN/TURN Config --> D;
      D -- 6. Establish Peer Connection --> E[Other Talkgroup Members];
      B -- 7. Token Expires --> F[Session Terminated];
  

---

Derivative Set 2: Operational Parameter Expansion

2.1. Massive-Scale Flash Event Provisioning

• Enabling Description: For events with 100,000+ temporary users (e.g., city marathons, protests), the system is designed for massive ingress. Instead of individual invitations, the subscriber (event organizer) pre-registers a block of phone numbers or email domains. The control device, built on a distributed hash table (DHT) and content delivery network (CDN), pre-generates cryptographically secure access tokens. The "invitation" is a generic URL or QR code distributed publicly. Upon access, a user's device hashes its device ID (e.g., IMEI) and sends it to a load-balanced endpoint. The endpoint uses the DHT to locate the relevant shard of the access database and validates the device against the pre-registered list, issuing a short-lived token. The POC application is hosted on a CDN to handle the download burst. The talkgroup itself is a broadcast-only channel with an optional, heavily moderated listen-and-reply queue to prevent chaos.

• Mermaid Diagram:

  graph TD
      subgraph Pre-Event Setup
          A[Organizer Device] --> B{Control Plane};
          B --> C[Register Phone # Blocks];
          B --> D[Pre-generate Tokens];
          B --> E[Distribute Public URL/QR Code];
      end
      subgraph Event Ingress
          F[Non-Subscriber Scans QR] --> G{Landing Page on CDN};
          G --> H[Device ID Hashing];
          H --> I[Load Balancer];
          I --> J[DHT Shard 1];
          I --> K[DHT Shard 2];
          I --> L[DHT Shard N];
          J --> M{Validate & Issue Token};
          M --> N[Connect to Broadcast Talkgroup];
      end
  

2.2. Disconnected, Intermittent, and Low-Bandwidth (DIL) Operations

• Enabling Description: This variation is designed for disaster recovery or battlefield scenarios with no reliable backhaul. The subscriber's device generates a signed "invitation packet" that contains the talkgroup configuration, an ACL, a public key, and an expiration timestamp. This packet can be transferred to a non-subscriber's device via local, out-of-band means like Bluetooth, Wi-Fi Direct, or a physical data transfer device (e.g., USB drive). The "POC application" is also transferred this way. The application, upon installation, validates the signature of the invitation packet. Communication within the talkgroup operates on a local mesh network, using a delay-tolerant networking (DTN) protocol. Messages are stored and forwarded as devices move in and out of range. Access automatically expires when the timestamp in the packet is reached.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Unprovisioned
      Unprovisioned --> Provisioned: Receive Signed Packet (OOB)
      Provisioned: Client validates signature & timestamp
      Provisioned --> Active: Join local mesh network
      Active --> Active: Store & Forward PTT data
      Active --> Expired: Timestamp reached
      Provisioned --> Expired: Timestamp reached
      Expired --> [*]
  

---

Derivative Set 3: Cross-Domain Applications

3.1. Aerospace: Temporary Avionics Data-Link Access

• Enabling Description: A flight operations manager (subscriber) grants a third-party ground maintenance crew (non-subscriber) temporary access to an aircraft's secure ACARS or FMS data stream for a specific tail number. The manager uses a flight ops terminal to enter the maintenance team leader's corporate email. The control device sends an email with a link to a sandboxed, web-based diagnostic client. This client establishes a secure, temporary VPN tunnel to a specific data bus on the aircraft via the airport's ground network. Access is limited to read-only telemetry and expires after a 2-hour window or when the aircraft's "Weight on Wheels" sensor indicates takeoff.

• Mermaid Diagram:

  flowchart LR
      subgraph On-Ground Ops
          A[Flight Ops Manager] -- 1. Invite via Email --> B{Control Device};
          B -- 2. Send Link --> C[Maint. Crew Laptop];
          C -- 3. Click Link --> D{Web-based Diagnostic Client};
          D -- 4. Auth & Tunnel Request --> B;
          B -- 5. Provision VPN --> E[Aircraft Data Gateway];
          D -- 6. Secure Telemetry Stream --> E;
      end
      F[Aircraft WoW Sensor] -- 7. Takeoff Signal --> E;
      E -- 8. Terminate VPN --> B;
  

3.2. AgTech: Ad-Hoc IoT Farm Sensor Network

• Enabling Description: A farm owner (subscriber) needs to grant a crop consultant (non-subscriber) temporary access to a section of their field's IoT network (soil moisture sensors, drone camera feeds). The owner uses a farm management app to draw a geofence on a map and selects the consultant from their contacts. The control device sends an SMS with a link to the consultant. The link opens a specialized app that displays data only from sensors within that geofence. The "talkgroup" is a data channel for controlling irrigation valves or tasking a drone for that specific zone. Access is automatically revoked after 24 hours or if the consultant's device GPS reports they are outside the geofence for more than 15 minutes.

• Mermaid Diagram:

  sequenceDiagram
      actor Owner
      participant App as Farm Mgmt App
      participant Server as Control Device
      actor Consultant
  
      Owner->>App: Define Geofence, Select Consultant
      App->>Server: Transmit Invite Request
      Server->>Consultant: Send SMS with Link
      Consultant->>Server: Access Link, Provide Location
      alt GPS inside Geofence
          Server->>Consultant: Stream Sensor/Drone Data
      else GPS outside Geofence
          Server->>Consultant: Deny Access
      end
      Note over Server, Consultant: Access revoked after 24hr or on leaving geofence.
  

3.3. Smart Home: Guest Access Control

• Enabling Description: A homeowner grants a house sitter temporary access to a subset of smart home devices (e.g., front door lock, specific cameras, thermostat). The homeowner uses their primary smart home app to select the "Guest Access" function, enters the sitter's phone number, and checks which devices to share. The system sends a link that prompts the sitter to download a lightweight "Guest" version of the app. Upon first open, the app uses the phone's secure element to generate a temporary cryptographic key pair and registers the public key with the home hub. All commands are signed by this temporary key. The homeowner can revoke access instantly, or it can be programmed to expire at a set date and time.

• Mermaid Diagram:

  classDiagram
      class HomeHub {
          -masterKey
          +deviceList
          +grantAccess(contact, deviceACL, duration)
          +revokeAccess(guestID)
      }
      class HomeownerApp {
          +requestGuestAccess()
      }
      class GuestApp {
          -guestPrivateKey
          +authenticateWithHub()
          +controlDevice(deviceID)
      }
      HomeownerApp --|> HomeHub : controls
      GuestApp --|> HomeHub : temporary control
  

---

Derivative Set 4: Integration with Emerging Technologies

4.1. AI-Driven Predictive Provisioning

• Enabling Description: In a public safety context, the control device integrates with a CAD (Computer-Aided Dispatch) system and an AI/ML model. When a multi-agency incident is dispatched (e.g., a 5-alarm fire), the AI model analyzes the incident type, location, and units dispatched. It predictively identifies likely non-subscriber participants (e.g., hospital ER supervisors, public utility foremen, nearby school principals) based on historical incident data and GIS information. The system automatically sends provisional access links to these individuals, who can then choose to join the incident talkgroup. The AI also monitors talkgroup sentiment and keyword mentions to suggest inviting additional experts if the situation evolves.

• Mermaid Diagram:

  graph TD
      A[CAD System] -- 1. Dispatch Event --> B(AI/ML Model);
      B -- 2. Analyze Incident --> C{Predict Participants};
      C -- 3. Generate Invite List --> D[Control Device];
      D -- 4. Send Provisional Links --> E[Hospital ER];
      D --> F[Utility Foreman];
      D --> G[School Principal];
      H[Incident Talkgroup] -- 5. Audio Stream --> B;
      B -- 6. Real-time Analysis --> I{Suggest New Experts};
      I --> D;
  

4.2. Blockchain/NFT-Based Access Tokens

• Enabling Description: The access grant is tokenized as a non-fungible token (NFT) on a private, permissioned blockchain. When a subscriber invites a non-subscriber, the control device (acting as a minting service) creates a new NFT. The NFT's metadata contains the talkgroup ID, the grantee's identifier (e.g., a hashed phone number), and an "expiration" property. The invitation link allows the non-subscriber to claim the NFT into a temporary, in-app crypto wallet. The POC application authenticates to the talkgroup by presenting this NFT and signing a challenge with the wallet's private key. The smart contract governing the NFT automatically renders it invalid after the expiration time, providing a decentralized and auditable method of revoking access.

• Mermaid Diagram:

  sequenceDiagram
      participant Sub as Subscriber
      participant Ctrl as Control Device
      participant Chain as Blockchain
      participant NonSub as Non-Subscriber
  
      Sub->>Ctrl: Request Invite
      Ctrl->>Chain: Deploy AccessToken Smart Contract (NFT)
      Chain-->>Ctrl: Contract Address
      Ctrl->>NonSub: Send Link to Claim NFT
      NonSub->>Chain: Claim NFT to In-App Wallet
      NonSub->>Ctrl: Request PTT Session w/ NFT Proof
      Ctrl->>Chain: Verify NFT Ownership & Validity
      Chain-->>Ctrl: Verification Result
      Ctrl->>NonSub: Grant PTT Access
  

---

Derivative Set 5: Inverse and Safe Failure Modes

5.1. Graceful Degradation to Low-Fidelity Mode

• Enabling Description: The downloaded POC application continuously monitors the non-subscriber device's state (battery level, network signal strength, CPU load). If any parameter crosses a critical low threshold, the application automatically switches to a "low-fidelity" mode. In this mode, video transmission is disabled, audio is transcoded to a low-bitrate codec (e.g., Opus at 8kbps), non-essential UI elements are hidden, and background data synchronization is paused. The device sends a status flag to the control server, which then signals other participants that the user is in a degraded state. This ensures core PTT voice functionality is maintained in adverse conditions.

• Mermaid Diagram:

  stateDiagram-v2
      state "High Fidelity" as HiFi
      state "Low Fidelity" as LoFi
  
      [*] --> HiFi
      HiFi --> LoFi: Battery < 15% OR Signal < -110dBm
      LoFi --> HiFi: Battery > 20% AND Signal > -100dBm
      HiFi: Full UI, HD Audio, Video Enabled
      LoFi: Minimal UI, Low-bitrate Codec, Video Disabled
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with Matrix/Element: A "control device" is implemented as a Matrix Synapse homeserver with a custom provisioning module. A public safety agency runs this server. An administrator, using a modified Element client, invites a non-subscriber by their phone number. The provisioning module uses a service like Twilio to send an SMS with a matrix.to invitation link. The link directs the user to a lightweight web-based Element client, which generates an ephemeral guest account on the homeserver and automatically joins the specified encrypted room (the "talkgroup"). The guest account is automatically deactivated by a cron job on the server after the pre-determined time has elapsed.

2. Combination with FIDO2/WebAuthn: The system forgoes passwords or traditional tokens for non-subscribers. The invitation link leads to a registration page. The page invokes the browser's WebAuthn API, prompting the user to authenticate with their device's built-in biometrics (e.g., fingerprint, Face ID). This creates a public-key credential which is stored by the control device. To join the POC talkgroup, the application (native or web-based) issues a cryptographic challenge which must be signed by the user's private key, again via a biometric prompt. This provides secure, passwordless, and temporary access tied to the user's specific device. Access is revoked by simply deleting the stored public key from the control device's database.

3. Combination with Open Policy Agent (OPA): Access control logic for the POC talkgroups is decoupled from the control device and managed by the Open Policy Agent (OPA) open-source engine. When a non-subscriber attempts to join, the control device queries the OPA service with a JSON object containing user attributes (e.g., user_id, contact_info, requested_talkgroup, current_time). OPA evaluates these attributes against a set of policies written in the Rego language. The policy can enforce complex rules, such as "Allow access only if the request is within the time window specified in the invitation AND the user is not on a global blocklist." This allows for highly flexible and auditable access control that can be updated without redeploying the main control device application.