Derivative works

Defensive Disclosure and Prior Art Derivations for U.S. Patent 9,978,205

Publication Date: May 7, 2026
Subject: Technical Disclosures Expanding Upon the Art of Location-Based Restrictions on Networked Gaming

This document serves as a defensive publication to disclose variations, extensions, and alternative embodiments of the system described in U.S. Patent 9,978,205. The intent is to place these concepts into the public domain, thereby establishing them as prior art for any future patent applications.

---

Axis 1: Material & Component Substitution

Derivative 1.1: Hyper-Local Proximity-Based Gaming Enablement using UWB and BLE

• Enabling Description: This variation replaces generalized GPS-based location determination with a high-precision, indoor positioning system. Gaming clients are equipped with Ultra-Wideband (UWB) transceivers. The gaming venue (e.g., a casino, bar, or stadium) is outfitted with a grid of UWB anchors. The administration server uses Time Difference of Arrival (TDoA) or Two-Way Ranging (TWR) algorithms to calculate the client's position with sub-meter accuracy. This allows for the creation of micro-geofenced zones. For example, a "high-stakes" zone could be enabled near a physical poker room, while a "casual, low-wager" zone is active in a food court. Bluetooth Low Energy (BLE) beacons are used as a secondary, lower-power method to confirm presence within a broader area (e.g., the building itself) before activating the power-intensive UWB radio.

graph TD
    subgraph Gaming Venue
        UWB_Anchor1[UWB Anchor 1];
        UWB_Anchor2[UWB Anchor 2];
        UWB_Anchor3[UWB Anchor 3];
        BLE_Beacon[BLE Beacon];
    end

    subgraph GamingClient[Player Gaming Client]
        UWB_Transceiver[UWB Transceiver];
        BLE_Receiver[BLE Receiver];
        App[Gaming Application];
    end

    AdminServer[Administration Server];
    PositioningEngine[Positioning Engine];
    RuleEngine[Jurisdictional Rule Engine];

    GamingClient -- BLE Signal --> BLE_Beacon;
    GamingClient -- UWB Signals --> UWB_Anchor1;
    GamingClient -- UWB Signals --> UWB_Anchor2;
    GamingClient -- UWB Signals --> UWB_Anchor3;

    UWB_Anchor1 & UWB_Anchor2 & UWB_Anchor3 -- Raw Signal Data --> PositioningEngine;
    PositioningEngine -- Precise Coordinates (x,y,z) --> AdminServer;
    AdminServer -- Coordinates --> RuleEngine;
    RuleEngine -- Permitted Game List --> AdminServer;
    AdminServer -- Game List --> GamingClient;

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: Global-Scale, High-Latency Asynchronous Tournament System

• Enabling Description: This embodiment describes the system operating for a massive, global-scale tournament where players are in different jurisdictions and network latency is highly variable. The game type is asynchronous (e.g., a turn-based strategy game or a single-player puzzle challenge for high score). When a player initiates their session, the gaming client sends its location data to the nearest regional administration server. This server validates the location against local laws and authorizes a "session token." The client then downloads the game state (e.g., the puzzle seed, the chess board layout) which is cryptographically signed to ensure all players receive the identical challenge. The player can complete their game turn or session even if they lose connectivity. Upon completion, the game result, along with the session token, is queued and sent to the administration server when connectivity is restored. A central tournament server aggregates results from all regional servers after the tournament period ends to determine winners.

sequenceDiagram
    participant PClient as Player Client
    participant RegionalAdmin as Regional Admin Server
    participant CentralTournament as Central Tournament Server
    participant GameServer as Game Content Server

    PClient->>+RegionalAdmin: Request Entry (Location Data)
    RegionalAdmin->>RegionalAdmin: Validate Location vs. Local Laws
    RegionalAdmin-->>-PClient: Authorize Session (Session Token)
    PClient->>+GameServer: Request Game State (w/ Token)
    GameServer-->>-PClient: Signed Game Seed/State
    Note over PClient: Player completes game offline/asynchronously
    PClient->>+RegionalAdmin: Submit Result (Signed Result, Token)
    RegionalAdmin->>RegionalAdmin: Verify Result Signature
    RegionalAdmin->>+CentralTournament: Forward Validated Result
    Note over CentralTournament: Tournament period active...
    CentralTournament->>CentralTournament: Aggregate all results
    CentralTournament-->>RegionalAdmin: Distribute Final Standings/Payouts
    RegionalAdmin-->>PClient: Notify Player of Winnings

---

Axis 3: Cross-Domain Application

Derivative 3.1: Application to Regulated Drone Operations (Aerospace)

• Enabling Description: The core patent logic is applied to a command-and-control (C2) system for a fleet of commercial drones. Each drone is a "client." An "administration server" stores a dynamic, multi-layered map of operational rules based on geospatial boundaries. These rules include no-fly zones (airports, critical infrastructure), altitude restrictions, and payload-specific permissions (e.g., pesticide-spraying drones are disabled over organic farms). Before takeoff and in real-time during flight, the drone transmits its GPS coordinates to the administration server. The server responds with a list of currently "legal" commands or operational profiles. For instance, if a drone approaches a school, the server revokes the "spray" command and may only permit "return to base" or "loiter" commands. This ensures automated compliance with FAA regulations and local ordinances.

graph TD
    Drone[UAV Client] -- GPS & Telemetry --> AdminServer[C2 Administration Server];
    AdminServer -- Location --> RuleEngine[Geospatial Rule Engine];
    RuleEngine -- Query --> GIS_Database[GIS Database (No-Fly Zones, Property Lines)];
    GIS_Database -- Rule Data --> RuleEngine;
    RuleEngine -- Permitted Command Set --> AdminServer;
    AdminServer -- Signed Command Set --> Drone;

    subgraph Drone
        direction LR
        FlightController[Flight Controller];
        PayloadSystem[Payload System (e.g., Sprayer)];
    end

    AdminServer --> FlightController;
    AdminServer --> PayloadSystem;

Derivative 3.2: Application to Jurisdictional Telemedicine Platform

• Enabling Description: In this application, the "gaming client" is the interface used by a physician, and the "game options" are medical actions like prescribing medication or ordering specific lab tests. The "administration server" validates the physician's licensing credentials against the patient's current, verified location. When a physician attempts to write a prescription for a controlled substance, the system checks the patient's state laws, the physician's licensing status in that state, and the state's Prescription Drug Monitoring Program (PDMP) database. If all conditions are met, the "prescribe" option is enabled. If the physician is not licensed in the patient's state, only options like "recommend consultation" or "view records" would be available. This ensures strict compliance with the patchwork of state and federal medical laws.

sequenceDiagram
    participant PhysicianUI as Physician's EMR Client
    participant TelemedServer as Admin Server
    participant StateDB as State Licensing & PDMP DB
    participant PatientApp as Patient's Device

    PatientApp->>+TelemedServer: Report Verified Location
    PhysicianUI->>+TelemedServer: Request Patient Session (Physician ID, Patient ID)
    TelemedServer->>+StateDB: Verify Physician License for Patient's State
    StateDB-->>-TelemedServer: License Status (Valid/Invalid)
    TelemedServer->>TelemedServer: Generate Permitted Action List
    TelemedServer-->>-PhysicianUI: Enable/Disable UI Features (e.g., Prescribe Button)
    PhysicianUI->>PhysicianUI: User attempts to prescribe Drug X
    PhysicianUI->>+TelemedServer: Submit Prescription Action
    TelemedServer->>TelemedServer: Validate Action Against Permitted List
    alt Action is Permitted
        TelemedServer->>StateDB: Log prescription with PDMP
        TelemedServer-->>PhysicianUI: Prescription Confirmed
    else Action is Not Permitted
        TelemedServer-->>PhysicianUI: Error: Action not permitted in this jurisdiction
    end

---

Axis 4: Integration with Emerging Tech

Derivative 4.1: Integration with AI for Dynamic Risk Management

• Enabling Description: This derivative integrates a machine learning model into the administration server's Risk Management module. The AI model continuously analyzes real-time data streams, including player location, game choice, wager velocity, and historical player behavior. Its function is to predict and mitigate prohibited activities like collusion or money laundering. For example, if the model detects multiple players in close physical proximity (via UWB ranging) who are consistently joining the same poker tables and exhibiting unusual betting patterns (e.g., one player consistently folding to another), it can flag the activity. The system can then automatically intervene by disabling the ability for these players to join the same table, reducing their maximum wager limits, or presenting them with only single-player game options.

graph TD
    subgraph AdminServer
        GameAdmin[Game Administration]
        RiskML[AI Risk Model]
        RuleEngine[Rule Engine]
    end

    PlayerClient1 -- Game Actions & Location --> GameAdmin;
    PlayerClient2 -- Game Actions & Location --> GameAdmin;
    PlayerClient3 -- Game Actions & Location --> GameAdmin;

    GameAdmin -- Real-time Data Stream --> RiskML;
    RiskML -- Collusion Score, Risk Profile --> RuleEngine;
    RuleEngine -- Action --> GameAdmin;
    GameAdmin -- Modified Game Options --> PlayerClient1;
    GameAdmin -- Modified Game Options --> PlayerClient2;

Derivative 4.2: Integration with Blockchain for Provably Fair Wagering

• Enabling Description: This system uses a blockchain (e.g., a permissioned Ethereum-based chain) and smart contracts to manage wagers and payouts. When two players are matched, the administration server deploys a unique smart contract for their game. The players' wagers are sent to the smart contract address, which acts as an escrow. The game itself is run on a centralized gaming server for performance, but the critical game outcome (e.g., final score, winning hand) is cryptographically signed by the server and written to the blockchain. The smart contract is programmed to automatically release the funds (wager minus a house fee) to the winner's wallet address as soon as the valid, signed game outcome is posted on-chain. This creates a transparent, auditable, and tamper-proof record of every game and payout, removing the need for players to trust the central operator for financial settlement. Location verification still occurs off-chain on the administration server before the smart contract is deployed.

sequenceDiagram
    participant P1 as Player 1 Client
    participant P2 as Player 2 Client
    participant AdminServer as Admin Server
    participant GamingServer as Game Server
    participant Blockchain as Smart Contract

    AdminServer->>AdminServer: Match P1 and P2 (Location Verified)
    AdminServer->>+Blockchain: Deploy Game Contract
    Blockchain-->>-AdminServer: Contract Address
    AdminServer-->>P1: Contract Address
    AdminServer-->>P2: Contract Address
    P1->>+Blockchain: Send Wager to Contract
    P2->>+Blockchain: Send Wager to Contract
    AdminServer->>+GamingServer: Initiate Game for P1, P2
    Note over GamingServer: Game is played...
    GamingServer->>GamingServer: Generate and Sign Game Outcome
    GamingServer->>+AdminServer: Report Signed Outcome
    AdminServer->>+Blockchain: Submit Signed Outcome to Contract
    Blockchain->>Blockchain: Verify Signature & Execute Payout Logic
    Blockchain-->>P1: Transfer Winnings

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Failsafe Operation via "Regulatory Safe Mode"

• Enabling Description: This embodiment describes the system's behavior when a player's location cannot be determined with high confidence. This can occur due to GPS signal loss, suspected VPN/spoofing activity, or conflicting data from multiple location sources (e.g., IP geolocation says Nevada, but cell tower triangulation says California). In this state of ambiguity, the system enters a "Regulatory Safe Mode." It defaults to the most restrictive possible set of rules. This means presenting the player only with gaming options that are legal in all potential jurisdictions and involve no real-money wagering. The game transitions to a "points-only" or "play-for-fun" mode. The UI clearly indicates to the player that functionality is limited due to location uncertainty and provides steps to re-establish a high-confidence location fix.

stateDiagram-v2
    [*] --> HighConfidence: Location Fix Acquired
    HighConfidence --> HighConfidence: Location Stable
    HighConfidence: Real-money wagering enabled.
    HighConfidence: Full game library available.
    HighConfidence --> AmbiguousLocation: Location Signal Lost/Conflicting Data
    AmbiguousLocation --> AmbiguousLocation: Attempting to Re-verify
    AmbiguousLocation: Wagering Disabled.
    AmbiguousLocation: Only "Play-for-Fun" games active.
    AmbiguousLocation --> HighConfidence: High-Confidence Fix Re-acquired
    AmbiguousLocation --> [*]: Session Terminated

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with GeoJSON and PostGIS: The administration server ingests and stores regulatory boundaries (states, counties, tribal lands, specific venue perimeters) as GeoJSON objects in a PostgreSQL database with the PostGIS extension. When a player's coordinates are received, the server performs a highly efficient ST_Contains query in PostGIS to determine which polygon(s) the player's point-location falls within. This allows for dynamic and precise updating of legal zones without requiring software recompilation.

2. Combination with OAuth 2.0 and OpenID Connect: The gaming client does not manage player passwords. Instead, it uses the OAuth 2.0 Authorization Code Flow to delegate authentication to a trusted identity provider (e.g., Google, Apple, or a casino's own loyalty program SSO). After authentication, OpenID Connect is used to retrieve a signed ID Token containing the player's verified identity. This token is passed to the administration server, which uses it to authorize the gaming session, reducing the system's security liabilities.

3. Combination with WebRTC (Web Real-Time Communication): For certain peer-to-peer games (e.g., fast-paced action games), after the administration server has verified player locations and matched them, it acts as a signaling server to broker a direct peer-to-peer connection between the player clients using the WebRTC standard. Game state updates are sent directly between clients over a RTCDataChannel, providing extremely low latency. The administration server does not need to relay game traffic but still receives periodic heartbeats (with location data) to ensure ongoing compliance and collects the final, signed game result from the clients to determine the winner.