Derivative works

Defensive Disclosure for U.S. Patent No. 10,299,071

Publication Date: May 10, 2026
Subject: Methods and systems for location sharing, management, and monitoring.

This document discloses enhancements, alternative embodiments, and new applications of the technologies described in U.S. Patent No. 10,299,071. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing prior art for any future patent applications that might claim these inventions.

---

Part 1: Derivatives of "Instant Buddy" Temporary Location Sharing (Claims 1 & 11)

The core concept involves a server-mediated system for two users to temporarily and mutually share their real-time location after a request-and-acceptance process. The following variations expand upon this concept.

1.1. Material & Component Substitution: Decentralized Trust & Communication

• Derivative Title: Peer-to-Peer "Instant Buddy" Handshake via Distributed Hash Table (DHT).
• Enabling Description: This embodiment eliminates the central server for location data exchange. User A (initiator) generates a unique, time-limited cryptographic key pair. The request to User B contains User A's public key and a one-time-use contact address on a DHT network (e.g., Kademlia). User B, upon acceptance, publishes their own encrypted location data and public key to that DHT address. Both clients then use the DHT to discover each other's updated IP addresses and stream encrypted GPS coordinates directly via a peer-to-peer protocol like WebRTC. The initial request can still be routed through a lightweight signaling server or a mobile push notification service (APNS/FCM), but the server does not handle any location data, only the initial handshake. The "timeout" is enforced by the devices themselves, which discard the session key after the agreed-upon duration.
• Diagram:

  sequenceDiagram
      participant User_A as Mobile A
      participant SignalingServer as Push Notification Service
      participant DHT_Network as Kademlia DHT
      participant User_B as Mobile B
  
      User_A->>SignalingServer: Request Instant Buddy (B's phone #, A's PubKey, DHT_address)
      SignalingServer->>User_B: Push Notification: "A wants to connect"
      User_B-->>User_A: User accepts via App UI
      User_B->>DHT_Network: Publish {Enc_Location_B, PubKey_B} to DHT_address
      User_A->>DHT_Network: Lookup DHT_address
      DHT_Network-->>User_A: Return {Enc_Location_B, PubKey_B}
      User_A->>User_B: Initiate P2P (WebRTC) Connection
      User_B-->>User_A: Accept P2P Connection
      loop Location Exchange
          User_A->>User_B: Stream Encrypted GPS Data
          User_B->>User_A: Stream Encrypted GPS Data
      end
  

1.2. Operational Parameter Expansion: High-Density/High-Velocity Tracking

• Derivative Title: Sub-Centimeter, High-Frequency Proximity Tracking for Industrial Environments.
• Enabling Description: The system is adapted for a factory floor or warehouse, operating at extreme parameters. Mobile devices are replaced with Ultra-Wideband (UWB) tags on forklifts and personnel. The "server" is an on-premises edge computing node. The "Instant Buddy" request is triggered automatically when two assets (e.g., a forklift and a worker) are predicted to have intersecting paths. The request is sent to both the forklift's control unit and the worker's wearable device. The system exchanges location data at a rate exceeding 100 Hz with sub-centimeter accuracy. The "map" is a 3D CAD model of the facility. The system's purpose is not social, but collision avoidance. The "timeout" is not time-based but context-based, ending automatically when the assets are a safe distance apart.
• Diagram:

  graph TD
      subgraph Factory Floor
          A[Forklift with UWB Tag]
          B(Worker with UWB Tag)
      end
  
      subgraph Edge Server
          C{Path Prediction Engine}
          D[UWB Anchor Network]
          E{Collision Risk DB}
          F[Instant Session Manager]
      end
  
      A -- Position @ 100Hz --> D
      B -- Position @ 100Hz --> D
      D -- Raw Data --> C
      C -- Predicts Intersection --> E
      E -- Triggers Alert --> F
      F -- 'Instant Buddy' Request --> A
      F -- 'Instant Buddy' Request --> B
      A -- Accept/Stream Data --> F
      B -- Accept/Stream Data --> F
      F -- Real-time Proximity Alerts --> A & B
  

1.3. Cross-Domain Application: Aerospace Maintenance

• Derivative Title: Augmented Reality "Instant Expert" for Aircraft Maintenance.
• Enabling Description: An aircraft technician on the tarmac encounters an unknown component. Using an AR headset (e.g., HoloLens), they initiate an "Instant Expert" request by looking at a QR code on the component. The request, containing the component ID and the technician's precise location on the aircraft (via indoor GPS or UWB), is sent to a central server. The server routes the request to an available remote expert. The expert accepts, establishing a two-way audio, video, and data link. The server shares the technician's GPS coordinates so the expert can load the correct 3D model of that specific section of the aircraft. The technician's view is streamed to the expert, who can overlay AR instructions onto the technician's display. The "Instant Buddy" relationship is a temporary, secure link for sharing visual and positional data for the duration of the specific maintenance task.
• Diagram:

  sequenceDiagram
      participant Tech as Technician (AR Headset)
      participant MRO_Server as Maintenance Server
      participant Expert as Remote Expert (Workstation)
  
      Tech->>MRO_Server: POST /expert_request {componentID, location}
      MRO_Server->>Expert: NOTIFY: Assistance Request from Tech at [Location]
      Expert-->>MRO_Server: ACCEPT
      MRO_Server-->>Tech: 200 OK {expert_session_id}
      MRO_Server->>Tech: Stream 3D Model of Component
      MRO_Server->>Expert: Stream Live Video & Telemetry from Tech
      loop AR Guided Maintenance
          Tech->>MRO_Server: Send Headset Orientation/Position
          Expert->>MRO_Server: Send AR Annotations
          MRO_Server->>Tech: Stream Synced AR Overlays
      end
  

1.4. Integration with Emerging Tech: AI-Powered Proactive Pairing

• Derivative Title: AI-Driven Proactive "Instant Buddy" Suggestion System.
• Enabling Description: A server-side AI model continuously analyzes user location data, calendar entries, communication patterns (e.g., recent calls/texts), and stated interests. When the model predicts a high probability of a user needing to meet or coordinate with another user (e.g., two users heading to the same concert venue from different directions), it proactively sends a notification to both parties: "It looks like you and [User B's Name] are both heading to [Venue]. Would you like to temporarily share locations to meet up?" The system pre-populates the "Instant Buddy" request, requiring only a single tap to accept. The AI also sets the timeout intelligently based on the event's duration from the calendar. This moves the system from a user-initiated request to a machine-initiated suggestion.
• Diagram:

  graph TD
      subgraph User A Data
          A1[Location History]
          A2[Calendar Events]
          A3[Social Graph]
      end
      subgraph User B Data
          B1[Location History]
          B2[Calendar Events]
          B3[Social Graph]
      end
      subgraph AI Platform
          C[Data Ingestion]
          D{Pattern Recognition & Intent Model}
          E[Suggestion Engine]
      end
      subgraph Server Backend
          F[Instant Buddy Module]
      end
  
      A1 & A2 & A3 --> C
      B1 & B2 & B3 --> C
      C --> D
      D -- High-Confidence Match --> E
      E -- Trigger Suggestion --> F
      F -->|"Suggest Meetup?"| UserA_Device
      F -->|"Suggest Meetup?"| UserB_Device
  

1.5. Inverse/Failure Mode: "Last Known" Beacon Mode

• Derivative Title: Emergency Beaconing with Failsafe Location Sharing.
• Enabling Description: A user enables a "Hiker's Beacon" mode before entering an area with poor connectivity. The device stops actively transmitting but continues to cache GPS waypoints locally. If the device fails to perform a "check-in" with the server (e.g., by pressing a button) within a user-defined interval (e.g., 6 hours), the server automatically initiates an "Instant Buddy" request to a pre-designated emergency contact. This request does not require acceptance from the user in distress. Upon initiation, the server sends a command to the user's device (if it regains connectivity) to upload its entire cached GPS track. If the device remains offline, the server shares the last known location and the time of the missed check-in with the emergency contact. This inverts the model from "permission to share" to "assumed permission upon failure."
• Diagram:

  stateDiagram-v2
      [*] --> Inactive
      Inactive --> Active: User enables Beacon
      Active --> Inactive: User disables Beacon
      Active: Phone logs GPS locally
      Active: Checks-in with server every 1hr
      Active --> Distress_Mode: Missed Check-in (6hr timeout)
  
      state Distress_Mode {
          [*] --> Notify_Contact
          Notify_Contact: Server sends IB request to Emergency Contact
          Notify_Contact --> Awaiting_Device
          Awaiting_Device: Server pings lost device
          Awaiting_Device --> Send_Last_Known: If no response
          Awaiting_Device --> Upload_Track: If device comes online
          Send_Last_Known --> [*]
          Upload_Track --> [*]
      }
  

---

Part 2: Derivatives of Supervisory Group Management (Claim 20)

The core concept is a server-managed group where a "supervisor" can monitor members, and members cannot remove the supervisor, secured by a passcode.

2.1. Material & Component Substitution: Biometric and Hardware-Based Access Control

• Derivative Title: Supervisory Group Management with Hardware Security Module (HSM) and Biometric Authorization.
• Enabling Description: This variation replaces the software "passcode" with stronger, hardware-rooted authentication. To add or remove a supervisor from a group, or to change monitoring parameters (e.g., active hours), the action must be authenticated using a FIDO2/WebAuthn compliant security key (like a YubiKey) or through a platform-provided biometric authenticator (e.g., Face ID, Windows Hello). This binds the supervisory authority not to something the user knows (a password) but to something they have (a hardware key) or are (a biometric). The server validates the cryptographic signature from the hardware key or the biometric system before applying any changes to the group's hierarchy. This prevents unauthorized changes even if the supervisor's account password is compromised.
• Diagram:

  sequenceDiagram
      participant Supervisor as Supervisor's Device
      participant Server as Buddy Watch Server
      participant HSM as Hardware Security Module
  
      Supervisor->>Server: Request to modify group (e.g., remove self)
      Server-->>Supervisor: Challenge (Nonce)
      Supervisor->>HSM: Sign(Nonce) with Private Key
      HSM-->>Supervisor: Signed Challenge
      Supervisor->>Server: Send Signed Challenge
      Server->>Server: Verify Signature with Supervisor's Stored Public Key
      alt Signature Valid
          Server->>Server: Apply Group Change
          Server-->>Supervisor: Success
      else Signature Invalid
          Server-->>Supervisor: Error: Unauthorized
      end
  

2.2. Operational Parameter Expansion: Fleet Logistics & Geofence-Based Policy Enforcement

• Derivative Title: Dynamic Geofence-Based Supervisory Control for Fleet Management.
• Enabling Description: This system is applied to a large-scale commercial fleet. The "supervisor" (dispatcher) defines multiple, nested geofences (e.g., "Warehouse Perimeter," "City Limits," "State Borders") on a management dashboard. The monitoring rules are tied to these geofences. For example, location updates are sent every 5 seconds inside the "Warehouse" fence, every 60 seconds within "City Limits," and every 15 minutes outside the state. The supervisor cannot be removed by the driver. Furthermore, entering or exiting a geofence can automatically trigger alerts or change device permissions (e.g., disabling the camera on the phone when entering a secure facility). The server continuously ingests GPS data from vehicle telematics units and applies the geofence rules in real-time.
• Diagram:

  graph TD
      subgraph Dispatcher Console
          A[Map Interface] --> B{Geofence Editor}
          B --> C{Rule Engine: If Zone=X, then Freq=Y, Alert=Z}
      end
  
      subgraph Vehicle
          D[GPS/Telematics Unit]
      end
  
      subgraph Server
          E[Location Processor]
          F[Geofence Matcher]
          G[Policy Enforcer]
          H[Database: Geofences, Rules, Vehicle Locations]
      end
  
      D -- GPS Stream --> E
      E -- Lat/Lon --> F
      B -- Geofence Polygons --> H
      F -- Queries --> H
      F -- Location + Zone --> G
      G -- Queries --> H
      G -- Applies Rules (e.g., Update Frequency, Alerts) --> E
      G -- Sends Alert to --> A
  

2.3. Cross-Domain Application: Parolee Monitoring & Compliance

• Derivative Title: Court-Mandated Location Monitoring with Exclusion Zone Alerts.
• Enabling Description: This system is used for parolee supervision. The "supervisor" is the parole officer, and the "group member" is the parolee, equipped with a tamper-resistant tracking device. The supervisor sets up mandatory "inclusion zones" (e.g., home, workplace) and strict "exclusion zones" (e.g., schools, victim's residence). The server-side logic, controlled by the supervisor, continuously monitors the parolee's location. If the parolee enters an exclusion zone or leaves an inclusion zone outside of approved hours, an instant, high-priority alert (SMS, email, automated call) is sent to the supervisor and a central monitoring station. The parolee cannot disable the tracking or remove the supervisor. The server maintains an immutable, time-stamped log of all location data and zone violations for legal and evidentiary purposes.
• Diagram:

  graph TD
      A[Parolee Device] -- GPS Data --> B[Server]
      C[Parole Officer Portal] -- Defines Zones & Rules --> B
      B -- Processes Data --> D{Rule Engine}
      D -- Is parolee in Exclusion Zone? --> E{Alert Trigger}
      D -- Is parolee outside Inclusion Zone? --> E
      E -- Sends Alert --> C
      E -- Sends Alert --> F[Central Monitoring Station]
      B -- Logs All Data --> G[(Immutable Ledger)]
  

2.4. Integration with Emerging Tech: Blockchain-Verified Compliance Records

• Derivative Title: Supervisory Location Auditing via Blockchain.
• Enabling Description: To ensure data integrity for compliance or legal purposes (e.g., proving a delivery was made, or a security guard was on patrol), the server hashes each received GPS data point (location, timestamp, device ID) and records the hash on a private or permissioned blockchain (e.g., Hyperledger Fabric). The "supervisor" and other authorized third parties (e.g., a client, an auditor) can be granted read-access to this blockchain. This creates an immutable, unforgeable audit trail of a user's location history. Attempting to tamper with the location database on the central server would create a mismatch with the blockchain record, which would be easily detectable. The supervisor's administrative actions (e.g., changing a geofence) are also logged as transactions on the chain.
• Diagram:

  classDiagram
      class Server {
          +receiveLocationUpdate(device_id, lat, lon, timestamp)
          +processRules()
          -hashData(data)
          -writeToBlockchain(hash)
      }
      class BlockchainLedger {
          +addBlock(transactionData)
          +verifyChainIntegrity()
      }
      class SupervisorApp {
          +viewLocationHistory(device_id)
          +verifyAuditTrail(device_id)
      }
      Server "1" -- "1" BlockchainLedger : Records Hashes
      SupervisorApp "1" -- "1" Server : Requests Data
      SupervisorApp "1" -- "1" BlockchainLedger : Verifies Hashes
  

2.5. Inverse/Failure Mode: Privacy-Preserving Supervisory "Dead Man's Switch"

• Derivative Title: Escrowed Location Monitoring with Emergency Unlock.
• Enabling Description: This model is for users who require a supervisor for safety (e.g., lone workers in remote areas) but desire maximum privacy during normal operations. The user's device encrypts its location data using the supervisor's public key and sends the encrypted data to the server. The server cannot decrypt or view the location; it only stores the encrypted blobs. The user's device must also send a periodic "heartbeat" signal to the server. If this heartbeat is missed for a configurable period (the "dead man's switch"), the server automatically releases the most recent encrypted location data to the supervisor. The supervisor can then use their private key to decrypt the location and initiate a response. This ensures location is only revealed in a potential emergency, as defined by the lack of a "safe" signal from the user.
• Diagram:

  sequenceDiagram
      participant WorkerDevice as Lone Worker's Device
      participant Server
      participant Supervisor
  
      loop Normal Operation
          WorkerDevice->>WorkerDevice: Encrypt GPS with Supervisor's PubKey
          WorkerDevice->>Server: Store EncryptedLocationBlob
          WorkerDevice->>Server: Send Heartbeat Signal
      end
  
      Note over WorkerDevice, Supervisor: Worker Fails to Send Heartbeat (Timeout)
  
      Server->>Supervisor: NOTIFY: Heartbeat Missed!
      Server->>Supervisor: RELEASE: Last EncryptedLocationBlob
      Supervisor->>Supervisor: Decrypt Blob with Private Key
      Supervisor->>Supervisor: View Last Known Location
  

---

Part 3: Combination with Open-Source Standards

1. Integration with WebRTC for Serverless Data Exchange: The "Instant Buddy" initiation protocol of claims 1 and 11 can be combined with the WebRTC (Web Real-Time Communication) open standard. A central server would still handle the initial user discovery and signaling (using Session Description Protocol - SDP), authenticating the users and passing connection details. However, once the connection is established, all subsequent GPS location data would be streamed directly between the two peer devices in an encrypted, peer-to-peer manner via WebRTC's RTCDataChannel. This reduces server load and latency and enhances user privacy as the central server no longer processes the continuous stream of location updates.

2. Integration with MQTT for IoT Fleet Management: The supervisory model of claim 20 can be enhanced for massive IoT deployments by using the MQTT (Message Queuing Telemetry Transport) protocol. Each tracked device (e.g., a sensor on a shipping container) would act as an MQTT client. It would publish its location data to a specific, secured topic on an MQTT broker (the server). Supervisors (subscribers) would subscribe to topics corresponding to their groups (e.g., /fleet/trucks/group_A). This lightweight, publish-subscribe model is far more scalable for thousands of low-power devices than traditional HTTP request-response cycles, reducing battery consumption and network bandwidth.

3. Integration with GeoJSON for Interoperable Geofencing: The concept of defining a geographic area for tracking or alerts, as implied in the supervisory use cases of claim 20, can be standardized using the GeoJSON (RFC 7946) format. When a supervisor creates a "safe zone" or an "exclusion zone," the coordinates defining that polygon, multipolygon, or circle (as a polygon approximation) are stored and transmitted as a GeoJSON object. This allows the location-sharing system to interoperate with any other mapping or geographic information system (GIS) that supports this open standard, enabling the import/export of zones from third-party planning software or government-provided alert boundaries.