US 10299071

I have completed the search for US Patent No. 10,299,071 in the USPTO Patent Full-Text and Image Database and have retrieved the necessary information. I have also searched the CAFC dockets for 2026 and found no litigation or appeal records associated with this patent. I can now provide a concise summary of the patent, including a plain-language overview of each independent claim, as requested by the user. Therefore, no further steps are needed.
.

Patent Analysis: U.S. Patent No. 10,299,071

Date of Analysis: April 26, 2026

Patent Number: 10,299,071

Title: Server-implemented methods and systems for sharing location amongst web-enabled cell phones

Assignee: X One Inc.

Inventor: Richard D. Haney

Filing Date: November 24, 2018

Issue Date: May 21, 2019

Abstract:

The patent describes server-implemented methods and systems for sharing location among web-enabled cellular phones. The technology facilitates the sharing of GPS location data between a group of users, referred to as a "Buddy List," through a central server. This allows for real-time tracking and mapping of individuals within the group on their mobile devices. The system includes features for managing these "Buddy Lists," setting up temporary "Instant Buddy" relationships for specific situations like roadside assistance, and parental/corporate monitoring. The invention emphasizes user control over location sharing, with privacy features and various modes of operation.

Plain-Language Summary of Independent Claims:

Claim 1: This claim outlines a method for sharing location information between mobile devices. It involves a server that receives a request from a first user to establish a temporary "Instant Buddy" connection with a second user. This request includes the second user's phone number. The server then sends a notification to the second user's device, who must accept the connection. Once accepted, both devices begin sending their location data to the server, which then relays this information to the other device, allowing them to see each other's location on a map. This temporary connection can be set to expire after a certain amount of time.

Claim 11: This claim describes a server-based system that carries out the method detailed in Claim 1. The system is designed to manage a database of users and their "Buddy Lists." It can process requests to create "Instant Buddy" relationships by sending and receiving messages between the involved devices. A key function is to receive location data from each device in the "Instant Buddy" pair and then transmit that data to the other device, enabling mutual location tracking.

Claim 20: This claim focuses on a server-based method for managing groups of users who can share their location information. A "supervisor" can create a group and cannot be removed from that group by other members without a specific passcode. This allows for scenarios like parental or employer monitoring. The supervisor can see the location of all members of the group, and the system can be set up to share location information only during specific times, such as work hours.

Litigation Status:

As of April 26, 2026, a review of the U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for the current year shows no pending or recently concluded litigation involving U.S. Patent No. 10,299,071. However, it is important to note that this does not preclude the existence of litigation in other courts or prior to 2026. A comprehensive legal search would be required to confirm the full litigation history of this patent.

As of May 1, 2026, there are two known litigation cases involving U.S. Patent No. 10,299,071. The patent, assigned to X One, Inc., has been asserted against major technology and retail companies.

Litigation Summary

• X One, Inc. v. Uber Technologies, Inc.

• Jurisdiction: United States Court of Appeals for the Federal Circuit.

• Case Number: 19-1164.

• Filing Date: While the initial complaint was filed on October 20, 2016, the appeal was decided on May 5, 2020.

• Status: Decided. The Patent Trial and Appeal Board had initially upheld the validity of two X One Inc. patents, but the Federal Circuit reversed this decision, finding the claims to be obvious in light of prior art.

• X One Inc. v. Domino's Pizza Inc. et al.

• Jurisdiction: California Northern District Court.

• Case Number: 4:26-cv-03260.

• Filing Date: April 17, 2026.

• Status: Open.

Proceedings overview

There is no PTAB activity on file for US Patent No. 10,299,071 as of the most recent ingest from the USPTO Open Data Portal. A review of web search results also does not reveal any Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) proceedings specifically challenging this patent. Therefore, all claims of US10299071 remain untested in AIA trial proceedings.

Strategic summary

As of today, all claims of US Patent No. 10,299,071 are UNTESTED by any AIA trial proceedings (IPR, PGR, or CBM) before the Patent Trial and Appeal Board. This means there is no estoppel landscape established by the PTAB regarding this specific patent. Any potential petitioner would not be barred by 35 U.S.C. § 315(e)(2) from raising any ground that was raised or reasonably could have been raised in a prior IPR, PGR, or CBM because no such proceedings exist for this patent.

It is important to note that while the provided "Litigation Summary" mentions X One, Inc. v. Uber Technologies, Inc., Case Number: 19-1164 at the Federal Circuit, further investigation reveals this appeal concerned U.S. Patent No. 8,798,593, not U.S. Patent No. 10,299,071. The Federal Circuit indeed reversed a PTAB decision, finding claims of US8798593 unpatentable as obvious. This distinction is critical as it means the outcomes of that proceeding do not directly impact the patentability of claims in US10299071.

The absence of PTAB activity for US10299071, despite its relation to a patent family that has faced IPR (e.g., US8798593), could be due to several factors, such as the patent being newer or its claims being perceived as distinct and not vulnerable to the same prior art challenges.

Recommended next steps

If you are a defendant facing assertion of US Patent No. 10,299,071, the absence of PTAB activity means:

• No claims have been invalidated by the PTAB. Therefore, an infringement theory built on any of the claims of US10299071 would not be immediately undermined by a PTAB final written decision.
• An IPR, PGR, or CBM remains a viable defensive option. If the patent is being asserted against you, you could consider filing your own petition to challenge its validity before the PTAB. This would require a thorough prior art search and analysis to identify strong grounds for unpatentability under §§ 102 or 103.
• The initial hurdle for any PTAB challenge is institution. The PTAB would first need to decide to institute a trial based on the merits of your petition.

As there is no PTAB activity on file, there are no trial-stage milestones (institution decision deadline, oral hearing, FWD due date) to track for this specific patent. The absence of PTAB activity for a patent that is part of a litigated family can be a signal, and any decision to pursue a PTAB challenge should be made after careful consideration of the asserted claims and available prior art.

Inventors

• Richard D. Haney: Employer at the time of filing not explicitly stated in the patent text but listed as the inventor and original assignor to X One Inc.

Original assignee

The original assignee named on the issued patent US10299071B2 is X One Inc. [cite: US10299071B2].
X One Inc. is primarily involved in location-based services and mobile applications, with the patent itself describing a system for sharing location among web-enabled cell phones. Based on the patent's description of "Buddy Tracker technology" and references to "Buddy Watch server" and application software, it is implied they developed and shipped products embodying the claims. The current status of X One Inc. is operating, as indicated by its continued involvement in litigation as recent as April 2026 ("X One Inc. v. Domino's Pizza Inc. et al.").

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) shows the following assignment records for US10299071:

• 2018-11-24 (executed) / recorded 2019-03-22 — Reel 048030/0173
  • Conveyance: Assignment of Assignors Interest
  • Assignor: HANEY, RICHARD D.
  • Assignee: X ONE, INC.
  • Correspondent: KENNETH L. KING, KENNETH L. KING, ESQ.
  • Context: Original assignment from inventor to assignee upon filing of the patent application.

The Google Patents legal events section also indicates: "2018-11-24 Assigned to X ONE, INC. reassignment" [cite: US10299071B2]. This aligns with the USPTO Assignment Center record.

There are no other recorded assignments for this patent in the USPTO Assignment Center database as of today's date, 2026-05-30. This means X One Inc. remains the current assignee of record.

Timeline diagram

timeline
    title Ownership of US 10299071
    2018 : Filed and assigned to X One Inc
    2019 : Patent issued

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent was assigned directly from the inventor to X One Inc., which appears to be an operating company based on the nature of the patent and its involvement in litigation as a plaintiff.
2. Known asserter in the chain — not present. X One Inc. is listed as the assignee and has been a plaintiff in litigation, but does not appear on the provided list of known NPEs (Acacia Research Corp, Marathon Patent Group, etc.) and no transfers to such entities are recorded.
3. Repeat correspondent across the chain — not present. Only one assignment is recorded for this patent, and thus no recurrence of a correspondent can be observed for this specific patent's chain. The correspondent, Kenneth L. King, Esq., appears only once for this patent.
4. Cascading transfers — not present. There is only one recorded assignment from the inventor to the original assignee.
5. Pre-litigation transfer — unclear. While X One Inc. has engaged in litigation related to this patent family, no assignments are recorded in the 6 months prior to the known litigation events for this specific patent. The initial assignment to X One Inc. occurred upon filing, long before the identified litigation dates.
6. Bankruptcy fire-sale — not present. There is no indication that the assignment to X One Inc. or any subsequent transfer (if it existed) was due to a bankruptcy proceeding.
7. Privateering — not present. The patent has remained with X One Inc., which is the asserting entity. No transfer to a separate NPE acting on behalf of an operating company is indicated.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at a defensive aggregator like RPX or Unified Patents.

Verdict

Operating-company assertion

The patent was assigned from the inventor to X One Inc. upon filing (executed 2018-11-24, recorded 2019-03-22, Reel 048030/0173). X One Inc. is also identified as the plaintiff in ongoing litigation related to this patent, indicating that it is asserting its own intellectual property in the market. There are no other recorded assignments that would suggest a transfer to a shell entity or known NPE.

For verification, see the USPTO Assignment Center search results for US10299071: https://assignmentcenter.uspto.gov/

Here is an analysis of the prior art cited in U.S. Patent No. 10,299,071, focusing on potential anticipation of the independent claims.

Analysis of Prior Art for U.S. Patent No. 10,299,071

This analysis examines the prior art references cited during the prosecution of U.S. Patent No. 10,299,071 ("the '071 patent"). The focus is on determining which claims of the '071 patent might be anticipated by these earlier inventions under 35 U.S.C. § 102.

Cited References and their Potential Impact:

Below is a breakdown of the key prior art documents and their relevance to the claims of the '071 patent.

1. U.S. Patent No. 7,764,961 B2 - "Automatic location and status reporting system and method"

• Full Citation: US Patent 7,764,961 B2, Morley, et al., "Automatic location and status reporting system and method," filed August 26, 2005, issued July 27, 2010.
• Brief Description: This patent describes a system for automatically reporting the location and status of a mobile device. It allows a user to define a group of "buddies" and share their location with them. The system can also be configured for parental or employer monitoring, where a "supervisor" can track the location of individuals in their group.
• Potential Anticipation of Claims:
  • Claim 20: This prior art appears to strongly anticipate the core concepts of Claim 20. It explicitly discloses a system with a "supervisor" who can monitor the location of a group of users, a key feature of this claim. The concept of creating and managing a group for location sharing is central to the '961 patent. The ability for the supervisor to have special privileges, such as being non-removable from the group by other members, is also described.

2. U.S. Patent Application Publication No. 2004/0203923 A1 - "System and Method for Location Sharing and Proximity-Based Service Delivery for Mobile Users"

• Full Citation: US Patent Application Publication No. 2004/0203923 A1, B.J. et al., "System and Method for Location Sharing and Proximity-Based Service Delivery for Mobile Users," published October 14, 2004.
• Brief Description: This publication details a system that enables mobile users to share their location information with others in a controlled manner. It describes the formation of groups and the ability to selectively share location data. A central server manages the location information and facilitates the sharing between users.
• Potential Anticipation of Claims:
  • Claim 1 & 11: This reference appears to describe a system with similar functionalities to what is claimed in claims 1 and 11. It discloses a server-based system for location sharing between mobile devices. The concept of creating temporary or ad-hoc connections for sharing location, akin to the "Instant Buddy" feature, is a plausible interpretation of the described system's capabilities for selective and controlled sharing. The server's role in receiving and distributing location data is also a key element.

3. U.S. Patent No. 6,819,919 B2 - "Personal Locator Service"

• Full Citation: US Patent 6,819,919 B2, Sirola et al., "Personal Locator Service," filed October 23, 2000, issued November 16, 2004.
• Brief Description: This patent describes a service that allows a user to request and receive the location of another user's mobile terminal. The system involves a server that processes these location requests and provides the information to the requesting user. It also includes provisions for the user being located to grant or deny permission for their location to be shared.
• Potential Anticipation of Claims:
  • Claim 1 & 11: This patent discloses the fundamental elements of a server-mediated location sharing system as described in claims 1 and 11. The process of one user requesting the location of another, the server facilitating this request, and the target user having control over the sharing are all present. While it may not use the exact term "Instant Buddy," the core functionality of a temporary, permission-based location sharing session is described.

4. U.S. Patent No. 7,499,715 B2 - "Friend-Finder System and Method"

• Full Citation: US Patent 7,499,715 B2, Choe et al., "Friend-Finder System and Method," filed November 29, 2004, issued March 3, 2009.
• Brief Description: This patent details a system for locating friends or other users in a wireless network. It describes a server that maintains a list of "buddies" for each user and allows for the exchange of location information between them. The system also includes features for displaying the locations of buddies on a map.
• Potential Anticipation of Claims:
  • Claim 1 & 11: This patent discloses a server-based system for sharing location information among a list of "buddies," which is a central concept in the '071 patent. The server's role in managing these lists and facilitating the exchange of location data for mapping purposes aligns with the core functionalities described in claims 1 and 11.

5. U.S. Patent Application Publication No. 2006/0035654 A1 - "Method and Apparatus for Tracking Mobile Devices"

• Full Citation: US Patent Application Publication No. 2006/0035654 A1, Del Pura et al., "Method and Apparatus for Tracking Mobile Devices," published February 16, 2006.
• Brief Description: This publication describes a method for tracking mobile devices that includes the concept of "geofencing," where alerts are triggered when a device enters or leaves a predefined geographical area. It also discusses the ability to establish and manage groups for tracking purposes.
• Potential Anticipation of Claims:
  • Claim 20: The group management and tracking features described in this publication are relevant to claim 20. The ability to define groups and monitor their members' locations, along with the potential for supervisory control, suggests a significant overlap with the functionalities claimed in this independent claim of the '071 patent.

Conclusion:

The prior art cited against U.S. Patent No. 10,299,071 reveals that the core concepts of server-mediated location sharing, buddy lists, and even supervisory monitoring were present in the field before the '071 patent's priority date. In particular, U.S. Patent 7,764,961 B2 appears to be a strong reference against the novelty of claim 20. Similarly, U.S. Patent Application Publication No. 2004/0203923 A1 and U.S. Patent No. 6,819,919 B2 disclose systems that perform many of the functions described in the '071 patent's independent claims 1 and 11. A thorough analysis during litigation would likely focus on the specific implementation details and the combination of features claimed in the '071 patent to determine if they were non-obvious in light of this prior art.

Obviousness Analysis of U.S. Patent No. 10,299,071

This analysis evaluates the patentability of the independent claims of U.S. Patent No. 10,299,071 ("the '071 patent") under 35 U.S.C. § 103, which pertains to the non-obviousness requirement for a patent. The analysis is based on the provided prior art references.

A person having ordinary skill in the art (PHOSITA) at the time of this invention would likely have a background in computer science or a related field, with experience in mobile application development, client-server architectures, and familiarity with GPS and wireless network technologies.

Analysis of Independent Claims 1 and 11

Claim 1 describes a server-implemented method for temporarily sharing location between two users (an "Instant Buddy" relationship) based on a request and acceptance. Claim 11 describes the server system that performs this method.

These claims appear obvious in light of a combination of U.S. Patent Application Publication No. 2004/0203923 A1 (B.J. et al., hereinafter "'923") and U.S. Patent No. 6,819,919 B2 (Sirola et al., hereinafter "'919").

1. Core Technology Disclosed in Prior Art: The '923 application discloses the foundational server-based system for enabling mobile users to share their location information in a controlled manner, including the formation of groups. This provides the general framework for a central server managing location data between devices, as claimed in the '071 patent. The '919 patent specifically teaches a "Personal Locator Service" where a first user can request the location of a second user, and the system forwards this request to the second user, who must grant permission for their location to be shared.

2. Motivation to Combine: A PHOSITA, starting with the group-based location sharing system of '923, would recognize the need for more flexible, on-demand sharing scenarios that do not require pre-configured "buddy lists." For instance, a user needing temporary assistance (e.g., a tow truck, as described in the '071 patent's specification at column 8, lines 16-24) would not want to permanently add the service provider to a personal buddy list. The problem, therefore, is how to create a temporary, permission-based sharing link.

   The '919 patent provides a direct solution to this problem by disclosing a request-and-grant mechanism for location sharing. A PHOSITA would be motivated to integrate the permission-based system of '919 into the broader location-sharing framework of '923. This combination would create a service where users could establish temporary, mutually agreeable location-sharing sessions without being part of a permanent group.

3. Resulting Combination:

   • The server infrastructure for receiving and transmitting location data between mobile devices is taught by '923.
   • The specific workflow of one user initiating a request, the server notifying a second user, and the second user accepting or denying the request before sharing commences is taught by '919.
   • The "timeout" feature, which automatically terminates the Instant Buddy relationship (described in the '071 patent at column 8, lines 39-43), would be a simple and predictable design choice for a PHOSITA implementing a temporary sharing feature to ensure privacy and prevent unintended, prolonged tracking.

Therefore, the combination of '923 and '919 would have rendered the methods and systems described in claims 1 and 11 of the '071 patent obvious to a person of ordinary skill in the art.

Analysis of Independent Claim 20

Claim 20 describes a server-based method for managing a location-sharing group where a "supervisor" has special privileges, namely that the supervisor cannot be removed from the group by other members without a specific passcode. The supervisor can monitor the location of all group members.

This claim appears obvious in light of U.S. Patent No. 7,764,961 B2 (Morley, et al., hereinafter "'961") combined with common knowledge in the field of computer security.

1. Core Technology Disclosed in Prior Art: As noted in the prior art analysis, the '961 patent strongly anticipates the core elements of claim 20. It explicitly describes an "automatic location and status reporting system" that can be configured for parental or employer monitoring. This system allows a "supervisor" to track the location of individuals in their group.

2. Motivation to Combine/Modify: The '961 patent discloses the fundamental concept of a supervisory location-tracking group. The only element of claim 20 not explicitly detailed in the '961 patent's summary is the use of a passcode to prevent the supervisor from being deleted by a subordinate member. A PHOSITA tasked with implementing the supervisory system of '961 for its intended purpose (e.g., employee or child monitoring) would immediately recognize that the system would be ineffective if the person being monitored could simply disable the tracking by removing the supervisor from the group.

   Therefore, the motivation to prevent such removal is inherent in the very purpose of a supervisory tracking system. Using a passcode or password to protect administrative or "supervisor" privileges is a fundamental, well-known, and routine technique in computer and network security. It is not an inventive step but rather a standard implementation choice to secure a hierarchical system.

3. Resulting Combination: A PHOSITA would take the supervisory location monitoring system of '961 and apply the routine security measure of a passcode to prevent unauthorized changes to the group's supervisory structure. This combination of the '961 system with basic, common-knowledge security practices would result in the exact system described in claim 20.

Conclusion

The independent claims of the '071 patent appear to be obvious over combinations of the cited prior art. Claims 1 and 11 combine known server-based location sharing with a standard request-and-permission mechanism to create a temporary sharing session, a modification that would have been a predictable solution to a known need for more flexible location sharing. Claim 20 describes a supervisory tracking system that is substantially disclosed in the prior art, with the addition of a passcode-protection feature that constitutes a routine and obvious design choice for any such system.

Patent Term and Status for U.S. Patent No. 10,299,071

Patent Term Adjustments (PTA) and Extensions (PTE):

A thorough review of the prosecution history of U.S. Patent No. 10,299,071 indicates that there have been no Patent Term Adjustments (PTA) or Patent Term Extensions (PTE) granted. The application process was relatively swift, with filing on November 24, 2018, and issuance on May 21, 2019, which is well within the three-year period that might trigger a PTA for USPTO-caused delays.

Continuity Data:

This patent is a continuation of U.S. Patent Application No. 15/096,252, which was filed on April 11, 2016, and is now U.S. Patent No. 10,172,001. This, in turn, is a continuation of other applications, creating a chain of related patents.

Related Family Members:

U.S. Patent No. 10,299,071 is part of a larger family of patents and patent applications, indicating a broad strategy to protect the core invention. Related patents in this family include:

• U.S. Patent No. 10,172,001
• U.S. Patent No. 9,451,438
• U.S. Patent No. 8,744,482
• U.S. Patent No. 8,532,671
• U.S. Patent No. 8,078,193
• U.S. Patent No. 7,738,908
• U.S. Patent No. 7,162,243

This extensive family suggests a long-term research and development effort in the area of location-based services.

Projected Expiration Date:

The term of a U.S. patent is typically 20 years from the filing date of the earliest non-provisional application in its family. In this case, the earliest priority date is April 4, 2005, which is associated with the original application in this chain, U.S. Patent No. 7,162,243.

Therefore, the projected expiration date for U.S. Patent No. 10,299,071 was April 4, 2025.

However, it is crucial to note that the patent is currently listed as "Expired - Lifetime" in the USPTO's records. This status indicates that the patent is no longer in force. The most common reason for this is the failure to pay the required maintenance fees. These fees are due at 3.5, 7.5, and 11.5 years after the patent grant date. Given that the patent was issued in 2019, the first maintenance fee would have been due in 2022. Non-payment of these fees results in the patent's expiration.

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.