Patent 11687971
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Active provider: Google · gemini-2.5-flash
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Defensive Disclosure for US Patent 11687971
This document describes a series of derivative works and technical disclosures related to US Patent 11687971, "Efficient and secure communication using wireless service identifiers." The purpose of this disclosure is to establish prior art, aiming to render future incremental improvements or alternative implementations of the patent's core concepts obvious or non-novel, thereby limiting the scope of potential future claims by competitors.
Combination Prior Art Scenarios
The following scenarios describe combinations of the fundamental concepts within US11687971 with existing open-source standards, demonstrating their synergistic application and further reducing the novelty of future similar inventions.
Distributed Ledger Technology (DLT) for Identifier Management (Claim 1, 16, 17):
The dynamically changing unique identifiers (as described in Claim 17) and the policies for disclosure (as in Claim 16) can be managed using a decentralized blockchain or other DLT (e.g., Hyperledger Fabric, Ethereum). Each device's unique identifier and its associated policy (e.g., access control list, privacy settings) could be stored as a smart contract on a permissioned blockchain. The central server (or a distributed network of validation nodes) would interact with the blockchain to verify identifiers and enforce policies. When a wireless device (Claim 1) detects a beacon, it sends the detected unique identifier to the server. The server, instead of querying an internal database (FIG. 10, step 1004), would query the blockchain for the identifier's validity and associated disclosure policies. New identifiers (Claim 17) could be minted as new blockchain tokens or updated within existing smart contracts. This leverages the immutability and verifiable nature of blockchain to enhance the security and privacy aspects already claimed.MQTT and CoAP for Efficient Server Communication (Claim 1, 10, 12):
For resource-constrained wireless devices (Claim 12) or in scenarios requiring highly efficient communication with the central server (Claim 1, 10), the second radio's communication can utilize IoT-specific protocols. Instead of a general IP-based network using HTTP/TCP, devices could employ MQTT (Message Queuing Telemetry Transport) or CoAP (Constrained Application Protocol) over UDP. MQTT is a lightweight publish-subscribe messaging protocol often used for IoT devices. When a wireless device detects a unique identifier, it would publish this identifier as a topic to an MQTT broker (which acts as the server or relays to it). The server, subscribed to relevant topics, receives the identifier and publishes the stored information back to a device-specific topic. CoAP offers a RESTful model for constrained devices. A wireless device would send a CoAP GET request to the server with the detected unique identifier, and the server would respond with the relevant information. This is particularly relevant for battery-powered broadcast devices or mobile devices operating in low-power modes.OpenStreetMap (OSM) for Predetermined Location Services (Claim 18):
For broadcast devices having a predetermined location (Claim 18), the stored information related to their location and associated content can be integrated with OpenStreetMap (OSM) data. The central server (FIG. 2, 100) would correlate the unique identifier of a broadcast device (204) with geocoordinates and associated metadata (e.g., museum exhibit details, store promotions) stored in or linked to an OSM database. When a mobile device (202) detects a broadcast identifier and sends it to the server, the server retrieves the OSM-referenced location and content. This provides a rich, open-source mapping and data context for location-based services, moving beyond proprietary mapping solutions. For instance, the "further action" (Claim 18) could involve overlaying a detected broadcast device's information onto an OSM map displayed on the mobile device, providing interactive elements derived from OSM's community-contributed data.
Derivative Variations and Technical Disclosures
This section details specific derivative variations for selected core independent claims of US11687971, designed to broaden the scope of prior art.
Derivatives of Independent Claim 1 (Method - general with MAC address)
Claim 1: A method comprising: transmitting, by at least one beacon transmitter using a short range wireless radio, a first beacon transmission in a first time period, the beacon comprising a first MAC address, a first unique identifier, and a beacon service identifier; receiving, by a wireless device using the short range wireless radio, a first plurality of beacon transmissions during the first time period; receiving, by the wireless device from one or more servers using a second radio, stored information relating to an entity or object associated with the first unique identifier; selecting, by the wireless device, one or more unique identifiers from the first plurality of beacon transmissions, by filtering the first plurality of beacon transmissions which include the beacon service identifier; and taking further action, if the first unique identifier is present among the selected one or more unique identifiers, using the stored information, which includes at least the identity of the entity or object associated with the first unique identifier.
1.1. Material & Component Substitution: Li-Fi Beacon with Satellite Backhaul
Enabling Description:
This derivative replaces the short-range wireless radio (e.g., Bluetooth, Wi-Fi) with a Light Fidelity (Li-Fi) optical wireless communication system and the second radio (e.g., cellular WWAN) with a satellite communication module. The beacon transmitter incorporates a Li-Fi LED array capable of modulating visible light to transmit data, including an optical MAC address (OMAC), a unique identifier encoded in the Li-Fi data stream, and a Li-Fi service identifier. The wireless device includes a photodetector for receiving Li-Fi transmissions and demodulating the optical signals. Upon detection, the device's integrated satellite transceiver (e.g., Iridium, Starlink user terminal) establishes a connection to a geostationary or low-Earth orbit (LEO) satellite network. The unique identifier is relayed via satellite to a central ground station server, which processes the request and sends back stored information. The filtering process occurs after optical demodulation, identifying beacons with the specific Li-Fi service identifier. The OMAC acts as the first MAC address, uniquely identifying the Li-Fi beacon emitter.
graph TD
A[Li-Fi Beacon Transmitter] -->|Optical Signal (OMAC, UID, ServiceID)| B(Wireless Device)
B -->|Satellite Uplink (UID)| C[Satellite Network]
C -->|IP via Ground Station| D[Central Server]
D -->|Stored Info| C
C -->|Satellite Downlink| B
B --> E{Filter by ServiceID}
E --> F{UID Present?}
F -- Yes --> G[Take Further Action (using Stored Info)]
1.2. Operational Parameter Expansion: Ultra-Low Power Nanoscale Beacons for Micro-Environmental Monitoring
Enabling Description:
This derivative applies the method at an extremely small scale, using nanoscale, batteryless beacon transmitters embedded in environmental sensing dust. Each "smart dust" particle (e.g., 100 µm silicon mote) incorporates a passive RFID or near-field communication (NFC) tag operating at ultra-low power, harvesting energy from ambient RF fields or light. The "first MAC address" is the unique serial number of the RFID/NFC chip. The "first unique identifier" is a cryptographically derived hash of environmental parameters (e.g., temperature, humidity) combined with the serial number, updated periodically. The "beacon service identifier" designates the environmental monitoring service. The "wireless device" is a miniature autonomous drone (e.g., micro-quadcopter) equipped with an active RFID/NFC reader for short-range detection. The drone's second radio is a sub-GHz LoRaWAN module, transmitting detected unique identifiers (and associated environmental data) over long distances (several kilometers) to a LoRaWAN gateway. The gateway relays data to a cloud-based server. The server provides stored information (e.g., sensor calibration data, deployment location context) for the drone to take further action, such as adjusting its flight path or triggering higher-resolution scans based on detected environmental anomalies.
graph TD
A[Nanoscale Beacon Transmitter (RFID/NFC)] -->|RF Field (MAC, Hashed-UID, ServiceID)| B(Mini-Drone with RFID/NFC Reader)
B -->|LoRaWAN (UID, Env. Data)| C[LoRaWAN Gateway]
C -->|Internet| D[Cloud Server]
D -->|Stored Info| C
C -->|LoRaWAN| B
B --> E{Filter by ServiceID}
E --> F{UID Present?}
F -- Yes --> G[Take Further Action (e.g., Adjust Flight/Scan)]
1.3. Cross-Domain Application: Industrial Asset Tracking in Smart Factories
Enabling Description:
In a smart factory setting, high-value industrial assets (e.g., robotic arms, specialized tools, Automated Guided Vehicles - AGVs) are equipped with active RFID beacons. Each beacon transmits its unique RFID tag ID (acting as the first MAC address), a serialized asset identifier (first unique identifier), and a "factory asset tracking" beacon service identifier via a short-range 2.4 GHz active RFID radio. Autonomous inspection robots, serving as the "wireless devices," continuously scan for these RFID beacons as they traverse the factory floor. The inspection robot's second radio, a Wi-Fi 6 (IEEE 802.11ax) module, communicates with a central factory control server over the factory's private local area network (LAN). Upon detecting an RFID beacon, the robot sends the asset identifier to the control server. The server returns stored information, such as the asset's maintenance schedule, last known operational status, or available software updates. The robot filters detected RFID tags based on the "factory asset tracking" service identifier. If a specific asset's identifier is found, the robot takes further action, such as performing a visual inspection, initiating a maintenance request, or updating its internal manifest.
flowchart TD
A[Industrial Asset Beacon (Active RFID)] -->|2.4GHz RFID (RFID-ID, AssetID, ServiceID)| B(Inspection Robot with RFID Reader)
B -->|Wi-Fi 6 (AssetID)| C[Factory Control Server (LAN)]
C -->|Stored Asset Info| B
B --> D{Filter by ServiceID}
D --> E{AssetID Present?}
E -- Yes --> F[Take Further Action (e.g., Visual Inspect/Maint. Req)]
1.4. Integration with Emerging Tech: AI-Optimized Beacon Parameters & Blockchain Identity
Enabling Description:
This derivative integrates AI for optimizing beacon parameters and blockchain for secure identity management. Beacon transmitters (e.g., smart lampposts, public transport hubs) utilize Bluetooth Low Energy (BLE) beacons. The "first MAC address" is a rotating, ephemeral address. The "first unique identifier" is a cryptographically signed identity derived from a private key stored on a secure element within the beacon, registered on a public blockchain (e.g., a non-fungible token, or NFT, representing the beacon's public identity). The "beacon service identifier" indicates a "smart city service." Mobile devices (the "wireless devices") receive BLE beacon transmissions. An AI agent running on the mobile device (or on a local edge server) applies machine learning to filter incoming beacons, not just by service ID, but also by learned patterns of user interest and historical interactions, dynamically adjusting filtering thresholds (e.g., signal strength, frequency of detection) to optimize relevance. The mobile device's second radio (5G NR) sends detected identifiers to a central "Smart City Orchestrator" server. This server, rather than relying on a traditional database, queries the blockchain network to verify the beacon's authenticity and retrieve its current public profile and policies. The AI agent on the mobile device then uses this verified information to take further action, such as presenting hyper-localized notifications or initiating a secure data exchange channel, ensuring identity is robustly verified via blockchain. The AI also dynamically adjusts the beacon's transmission power and interval based on real-time network conditions and user density, to optimize energy consumption and discovery rates.
sequenceDiagram
participant B as BLE Beacon (Rotating MAC, Blockchain UID, ServiceID)
participant WD as Wireless Device (Mobile w/ AI Agent, 5G NR)
participant SC as Smart City Server (Orchestrator)
participant BC as Blockchain Network
participant AI as AI Agent (on WD)
B->>WD: Transmit Beacon (Ephemeral MAC, Signed UID, ServiceID)
WD->>AI: Receive Beacon Data
AI->>AI: Filter by ServiceID & User Interest (ML)
alt UID Present & Relevant
AI->>WD: Selected UID
WD->>SC: Send Selected UID (via 5G NR)
SC->>BC: Verify UID & Retrieve Policy
BC-->>SC: Verified UID, Policy Data
SC-->>WD: Stored Info (Verified Identity, Content)
WD->>AI: Stored Info
AI->>WD: Take Further Action (Hyper-local notification, Secure channel setup)
end
1.5. The "Inverse" or Failure Mode: Emergency Broadcast with Degraded Functionality
Enabling Description:
In a critical infrastructure scenario (e.g., a power grid control center, disaster relief zone), fixed or mobile "emergency broadcast beacons" are deployed. These beacons typically transmit a standard Wi-Fi (802.11) beacon frame, containing a known MAC address, a unique identifier for the specific emergency zone/asset, and a "critical infrastructure alert" service identifier. In a normal operational mode, these beacons function as described in the patent. However, in a detected "failure mode" (e.g., internal power supply degradation, network link loss, or catastrophic event detection), the beacon transitions to a "degraded functionality" state. In this state, it ceases transmitting detailed information or engaging in server-brokered communication. Instead, it continuously transmits a simplified, low-power beacon with a specific "emergency-mode" service identifier and a unique identifier signifying its failure state (e.g., "power failure - unit 123"). This beacon is specifically designed to minimize power consumption, maximizing transmission duration. The "wireless device" (e.g., a first responder's ruggedized tablet) detects this emergency beacon. Its second radio (a robust satellite or mesh network radio) then tries to report the detected "emergency-mode" identifier to a central emergency management server. The stored information from the server would include emergency protocols specific to that failed unit/zone. The "further action" taken by the first responder's device might be to immediately display evacuation routes, safety instructions, or a direct communication channel to command control, prioritized over all other data. The server recognizes the "emergency-mode" identifier as a signal for critical system failure and alerts relevant personnel.
stateDiagram-v2
state Normal_Operation {
[*] --> Transmitting_Full_Beacon
Transmitting_Full_Beacon --> Server_Comm_Active : Detected by WD, Request info
Server_Comm_Active --> Transmitting_Full_Beacon : Info Received, Action Taken
Transmitting_Full_Beacon --> Failure_Detected : Internal Fault / Network Loss
}
state Degraded_Functionality {
Failure_Detected --> Transmitting_Emergency_Beacon : Enter Emergency Mode
Transmitting_Emergency_Beacon --> Transmitting_Emergency_Beacon : Continue Low-Power Broadcast
Transmitting_Emergency_Beacon --> Alert_Server : Detected by First Responder WD
Alert_Server --> Response_Received : Server Processes Alert
}
Failure_Detected --> Degraded_Functionality
Degraded_Functionality --> [*] : Event Resolved / Battery Depleted
Derivatives of Independent Claim 12 (Wireless Device)
Claim 12: A wireless device comprising: a short range wireless radio configured to receive a plurality of beacon transmissions, each beacon transmission comprising a unique identifier and a beacon service identifier; a second radio configured to receive stored information from one or more servers relating to an entity or object associated with the unique identifier; and one or more processors coupled to the short range wireless radio and the second radio, the one or more processors configured to: select one or more unique identifiers from the plurality of beacon transmissions, by filtering the plurality of beacon transmissions which include the beacon service identifier; and take further action, if a unique identifier is present among the selected one or more unique identifiers, using the stored information, which includes at least the identity of the entity or object associated with the unique identifier.
2.1. Material & Component Substitution: Software-Defined Radio (SDR) with Quantum Key Distribution (QKD) Interface
Enabling Description:
The "wireless device" is embodied as a specialized Software-Defined Radio (SDR) platform (e.g., utilizing an FPGA-based Universal Software Radio Peripheral - USRP). The "short-range wireless radio" is a reconfigurable SDR module capable of dynamically switching between various short-range protocols (e.g., sub-GHz ISM band, millimeter-wave (mmWave) for high-density environments), programmed to receive beacon transmissions. This SDR module is coupled to the processors. The "second radio" is a dedicated optical interface for Quantum Key Distribution (QKD) paired with a traditional high-bandwidth microwave radio for data transfer. The QKD link establishes a secure, unbreakable cryptographic key with a QKD node connected to the server network. This key is then used to encrypt all data exchanged with the server via the microwave radio. The processors, highly parallelized, perform real-time filtering of received beacon transmissions based on the beacon service identifier. The "stored information" from the server, securely transmitted via the QKD-protected channel, includes cryptographic certificates for authenticating detected unique identifiers. The "further action" involves applying these certificates to establish a secure, ephemeral session with the detected entity, enhancing overall communication security.
classDiagram
class SDR_Platform {
+FPGA_Processors
+Reconfigurable_ShortRange_Radio
+QKD_Optical_Interface
+Microwave_Data_Radio
+Filtering_Logic()
+QKD_Key_Exchange()
+Data_Decryption_Encryption()
+Take_Further_Action()
}
class Beacon_Transmitter {
+ShortRange_Radio
+Unique_Identifier
+Beacon_Service_Identifier
}
class Central_Server {
+QKD_Node_Interface
+Secure_Database
+UID_Authentication_Service()
+Policy_Engine()
}
Beacon_Transmitter "1" -- "N" SDR_Platform : Transmits Beacon
SDR_Platform "1" -- "1" Central_Server : Establishes QKD-Protected Communication
SDR_Platform ..> Beacon_Transmitter : Receives Beacon
SDR_Platform ..> Central_Server : Exchanges Stored Info
2.2. Operational Parameter Expansion: Sub-Millimeter Wave (THz) Beacon Receiver for High-Resolution, Ultra-Dense Environments
Enabling Description:
This wireless device is designed for extremely high-resolution, ultra-dense indoor environments, such as semiconductor cleanrooms or advanced manufacturing facilities. The "short-range wireless radio" is a sub-millimeter wave (Terahertz, THz) receiver array, capable of directional reception and spatial filtering. Beacons in this environment transmit highly localized, narrow-beam THz signals containing unique identifiers and specialized "precision tracking" beacon service identifiers. The THz signals allow for centimeter-level localization accuracy. The device's processors are configured to process the massive data rates from the THz receiver, performing beamforming and advanced spatial filtering to pinpoint beacon sources. The "second radio" is a fiber-optic Ethernet connection to a local edge server within the facility, providing ultra-low-latency communication. The processors filter THz beacon transmissions based on the "precision tracking" service identifier. The stored information from the edge server includes detailed 3D spatial models of the environment and real-time positional data of tracked objects. The "further action" involves updating a high-precision digital twin of the environment, tracking tool movement, or guiding robotic manipulation with unprecedented accuracy.
graph TD
A[THz Beacon Transmitter] -- THz Signal --> B(Wireless Device (THz Receiver Array))
B -- Fiber Optic Ethernet --> C[Local Edge Server]
C -- Stored 3D Spatial Models --> B
B --> D{Process THz Data (Beamforming, Spatial Filter)}
D --> E{Filter by ServiceID 'Precision Tracking'}
E --> F{UID Present?}
F -- Yes --> G[Take Further Action (Update Digital Twin, Guide Robot)]
2.3. Cross-Domain Application: Maritime Distress Beacon Receiver for Autonomous Vessels
Enabling Description:
This wireless device is integrated into an autonomous maritime vessel. The "short-range wireless radio" is a specialized acoustic modem operating in the underwater frequency spectrum. Maritime distress beacons, such as those on sunken vessels or in search-and-rescue (SAR) operations, transmit acoustic pulses containing an acoustic MAC address, a unique identifier for the distress event/object, and a "maritime distress" beacon service identifier. The autonomous vessel's acoustic modem receives these transmissions. The "second radio" is a SATCOM (Satellite Communication) module for communication with a shore-based SAR command center server. The vessel's onboard processors filter the received acoustic beacon signals, identifying those with the "maritime distress" service identifier. The stored information from the SAR server, received via SATCOM, includes distress call details, last known position of the distressed asset, and emergency contact information. The "further action" taken by the autonomous vessel is to adjust its course for interception, activate onboard survey equipment (e.g., side-scan sonar), and relay real-time environmental conditions to the SAR command center.
flowchart TD
A[Underwater Acoustic Distress Beacon] -- Acoustic Pulses (MAC, UID, ServiceID) --> B(Autonomous Vessel w/ Acoustic Modem)
B -- SATCOM (UID) --> C[SAR Command Center Server]
C -- Stored Distress Info --> B
B --> D{Filter by ServiceID 'Maritime Distress'}
D --> E{UID Present?}
E -- Yes --> F[Take Further Action (Adjust Course, Activate Sonar, Relay Data)]
2.4. Integration with Emerging Tech: Federated Learning for Contextual Filtering
Enabling Description:
The "wireless device" is a next-generation smartphone with a secure enclave processor for local AI inference. The "short-range wireless radio" is a combined Wi-Fi 7 (802.11be) and UWB (Ultra-Wideband) module. Beacons transmit a unique identifier and beacon service identifier. The "second radio" is a 6G-enabled transceiver. The device's main processors are configured to filter beacons by service identifier. Crucially, the local AI (within the secure enclave) performs contextual filtering using federated learning. This AI model is trained on diverse user interaction patterns and preferences across many devices, but the training data remains on the individual devices, ensuring privacy. When a beacon is detected, the AI analyzes user context (location, time, current activity, app usage, biometric data) and dynamically adjusts the relevance of detected beacons. The "stored information" from the server, received via 6G, includes privacy-preserving aggregated insights from other devices regarding relevant entities/objects, rather than raw personal data. The "further action" is a highly personalized notification or content display, where the AI ensures that information deemed "personally sensitive" by the federated model is either suppressed or presented with explicit user consent, based on refined privacy policies.
graph LR
subgraph Wireless Device
SRR[Short Range Radio (Wi-Fi 7, UWB)] -- Beacon Tx --> Proc[Processors]
Proc -- Contextual Data --> AI[AI Agent (Federated Learning)]
AI -- Filtered UID --> Proc
SRR -- Beacon Tx (UID, ServiceID) --> Proc
Proc -- Selected UID --> SR[Second Radio (6G)]
SR -- Stored Info --> Proc
end
subgraph Server Network
Server[Central Server] -- Aggregated Insights/Stored Info --> SR
end
SRR -.-> Beacon Tx
Proc --> Action[Take Further Action (Personalized Content/Notification)]
2.5. The "Inverse" or Failure Mode: Stealth Mode Device with Obfuscated Beacon Interaction
Enabling Description:
This wireless device is designed for covert operations or environments requiring extreme privacy/anonymity. The "short-range wireless radio" is a highly configurable, low-emission BLE/UWB transceiver. Normally, the device does not actively transmit a detectable identifier. In "stealth mode," it operates solely as a receiver, silently capturing beacon transmissions (unique identifier, beacon service identifier). The "second radio" is a burst-transmission, frequency-hopping satellite modem designed for minimal detectability. The device's processors are configured to perform filtering by beacon service identifier. If a specific "target" unique identifier (pre-loaded or derived from server instructions) is detected, the device enters a "report mode." In this mode, instead of directly sending the detected identifier, it generates an obfuscated report. This report includes a cryptographically unique, one-time alias for the detected beacon, its approximate location (derived from signal strength/direction-finding), and a timestamp. This obfuscated report is then transmitted via a single, rapid burst over the satellite modem to a highly secure command server. The "stored information" received from the server (also via burst transmission) would be encrypted instructions for further reconnaissance or updated target lists. The "further action" by the device involves either initiating silent data collection on the target or ceasing all activity to maintain stealth. This inverse mechanism ensures no direct interaction or identification that could compromise the device's presence.
stateDiagram-v2
state Stealth_Mode {
[*] --> Listening
Listening --> Beacon_Detected : Receive (UID, ServiceID)
Beacon_Detected --> Filtering : Processors Filter by ServiceID
Filtering --> Target_UID_Detected : If Target UID is present
Target_UID_Detected --> Obfuscate_Report : Generate One-Time Alias, Location, Timestamp
Obfuscate_Report --> Burst_Transmit_Report : Send via Satellite Modem
Burst_Transmit_Report --> Listening : Return to Stealth
Filtering --> Listening : If Target UID not present
}
state Report_Mode {
Obfuscate_Report --> Burst_Transmit_Report
Burst_Transmit_Report --> Receive_Instructions : Receive encrypted instructions from Server
Receive_Instructions --> Stealth_Mode : Execute instructions, return to Stealth
}
Derivatives of Independent Claim 16 (Method with Prevention of Sending Identifier)
Claim 16: A method comprising: transmitting, by at least one beacon transmitter using a short range wireless radio, a first beacon transmission in a first time period, the beacon comprising a first unique identifier and a beacon service identifier; receiving, by a wireless device using the short range wireless radio, a first plurality of beacon transmissions during the first time period; receiving, by the wireless device from one or more servers using a second radio, stored information relating to an entity or object associated with the first unique identifier; selecting, by the wireless device, one or more unique identifiers from the first plurality of beacon transmissions, by filtering the first plurality of beacon transmissions which include the beacon service identifier; and taking further action, if the first unique identifier is present among the selected one or more unique identifiers, using the stored information, which includes at least the identity of the entity or object associated with the first unique identifier, wherein the further action includes preventing the sending of the first unique identifier by the first wireless device to the one or more servers.
3.1. Material & Component Substitution: Directed Energy Beacon with Mesh Network Backhaul
Enabling Description:
The short-range wireless radio is replaced with a directed energy (e.g., focused infrared laser) beacon transmitter. This beacon emits an encoded laser pulse containing a unique identifier and a "privacy-enhanced data" beacon service identifier. The "wireless device" has an optical receiver capable of precisely receiving and decoding these laser pulses. Its "second radio" is a secure, multi-hop mesh network transceiver (e.g., using Wi-SUN or a custom ad-hoc protocol). Upon receiving a laser beacon, the wireless device processes the unique identifier locally. Because the "further action" explicitly includes preventing the sending of the unique identifier to the server, the server must have pre-provisioned a vast repository of stored information corresponding to all possible unique identifiers for this service type. The wireless device's processors perform a local lookup of the received unique identifier against the pre-downloaded, securely cached stored information. If a match is found, the relevant identity and other information are immediately accessible, without any network transmission of the unique identifier. Any required server interaction (e.g., to confirm the device's presence or request broader data) is performed using an anonymized, aggregated, or tokenized identifier, but not the raw unique identifier received from the beacon. The mesh network ensures robust, localized data access even without direct server connectivity.
graph TD
A[Directed Energy Beacon (IR Laser)] -->|Laser Pulse (UID, ServiceID)| B(Wireless Device w/ Optical Receiver)
B --> C{Filter by ServiceID 'Privacy-Enhanced Data'}
C --> D{UID Present?}
D -- Yes --> E[Local Lookup (Pre-cached Stored Info)]
E -- Match Found --> F[Take Further Action (Access Identity, Prevent UID Send)]
F --> G[Mesh Network Transceiver]
G -.-> H[Mesh Network Gateway]
H -.-> I[Central Server (Pre-provisioned Info)]
B -- No UID Send --> G
3.2. Operational Parameter Expansion: High-Frequency Acoustic Beacons in Subterranean Environments
Enabling Description:
This derivative implements the method in challenging subterranean environments (e.g., mines, underground facilities). "Beacon transmitters" are high-frequency (e.g., 20-100 kHz) ultrasonic emitters, strategically placed. Each emits a pulsed acoustic signal carrying a unique identifier (e.g., room ID, equipment ID) and a "subterranean safety" beacon service identifier. The "wireless device" is a helmet-mounted acoustic receiver worn by personnel or integrated into autonomous inspection robots. The device's "second radio" is an ultra-low-frequency (ULF) radio for through-rock communication, capable of very slow, low-bandwidth data bursts to a surface server. Due to the severe communication constraints of ULF, and the privacy requirement, the "stored information" (e.g., safety protocols, real-time gas readings for specific zones) is largely pre-cached on the wireless device. The device's processors filter received acoustic signals by the "subterranean safety" service identifier. If a unique identifier is found, the device performs a local lookup in its cache. The "further action" involves displaying relevant safety warnings or procedures, without transmitting the precise unique identifier of the detected hazard back to the surface server. Instead, the device might send an aggregated status update (e.g., "Alert in Zone B") via ULF to conserve bandwidth and maintain location privacy of the individual/robot.
sequenceDiagram
participant B as Ultrasonic Beacon (UID, ServiceID)
participant WD as Wireless Device (Acoustic Receiver, ULF Radio, Local Cache)
participant S as Surface Server (via ULF Gateway)
B->>WD: Transmit Acoustic Pulse (UID, ServiceID)
WD->>WD: Filter by ServiceID "Subterranean Safety"
alt UID Present
WD->>WD: Local Lookup of Stored Info (Cache)
WD->>WD: Take Further Action (Display Safety Info, Prevent UID Send)
WD->>S: Burst Transmit Aggregated Status (e.g., "Alert in Zone B")
end
3.3. Cross-Domain Application: Personalized Museum Guide with Data Sovereignty
Enabling Description:
In a museum, interactive exhibits are equipped with small, low-power directional millimeter-wave (mmWave) beacons. Each beacon transmits a unique identifier representing the exhibit and a "personal cultural experience" beacon service identifier. A visitor's smartphone, acting as the "wireless device," incorporates a mmWave receiver. The smartphone's "second radio" is its standard cellular (LTE/5G) connection to the museum's cloud server. Upon detecting a mmWave beacon, the smartphone's processors filter for the "personal cultural experience" service identifier. Critically, to protect visitor privacy (preventing the museum from tracking specific exhibit interactions), the phone retrieves stored information (e.g., multimedia content, historical context) from the cloud server without sending the exhibit's unique identifier. This is achieved by the server proactively pushing or allowing anonymous access to content associated with broad geographical zones or time-based codes, or by the phone querying the server with a cryptographically hashed version of the unique identifier that the server can only match against pre-computed hashes, not the original ID. The "further action" is to display interactive exhibit content, offer augmented reality overlays, or suggest related exhibits, all while guaranteeing the museum server never directly logs which specific exhibit a user is interacting with. This ensures data sovereignty for the user.
flowchart TD
A[mmWave Exhibit Beacon] -->|mmWave (UID, ServiceID)| B(Smartphone w/ mmWave Receiver)
B --> C{Filter by ServiceID 'Personal Cultural Experience'}
C --> D{UID Present?}
D -- Yes --> E[Request Stored Info (via Cellular, using Hashed UID/Zone ID)]
E --> F[Museum Cloud Server]
F -- Stored Info (Content) --> B
B --> G[Take Further Action (Display AR, Suggest Exhibits, Prevent Raw UID Send)]
3.4. Integration with Emerging Tech: Decentralized Identity (DID) & Zero-Knowledge Proofs for Authenticated Anonymity
Enabling Description:
Beacon transmitters (e.g., public transport payment terminals, secure entry points) emit BLE 5.0 beacons with rotating MAC addresses, a unique identifier based on a self-sovereign Decentralized Identifier (DID) hash, and a "verified access" beacon service identifier. The "wireless device" (e.g., a wearable biometric authenticator) receives these beacons. Its "second radio" is a secure NFC/Wi-Fi Direct link to a local payment/access gateway. When the device detects a beacon, it filters by the "verified access" service identifier. The "stored information" from the server (or a distributed DID resolver network) includes public keys and verifier policies associated with the DID-based unique identifier. The crucial "further action" involves the wireless device generating a Zero-Knowledge Proof (ZKP) that it possesses the necessary credentials (e.g., valid transit pass, authorized employee status) without disclosing the actual credentials or its own personal DID. This ZKP is then transmitted to the local gateway (server) via NFC/Wi-Fi Direct. The gateway verifies the ZKP, grants access, and provides a confirmation, all without ever receiving the beacon's unique identifier (beyond the initial anonymous hash for policy retrieval) or the user's personal identity. The prevention of sending the unique identifier is inherent in the ZKP process; only proof of attributes linked to the DID is exchanged.
sequenceDiagram
participant B as BLE Beacon (Rotating MAC, DID-Hash UID, ServiceID)
participant WD as Wireless Device (Wearable Biometric Auth, NFC/Wi-Fi Direct, DID Wallet, ZKP Generator)
participant LG as Local Gateway (Server)
participant DID as DID Resolver Network
B->>WD: Transmit Beacon (DID-Hash UID, ServiceID)
WD->>WD: Filter by ServiceID "Verified Access"
alt UID Present
WD->>DID: Resolve DID-Hash UID (Retrieve Public Keys, Verifier Policies)
DID-->>WD: Public Keys, Policies
WD->>WD: Generate Zero-Knowledge Proof (ZKP) of Credentials (NO UID SENT!)
WD->>LG: Transmit ZKP (via NFC/Wi-Fi Direct)
LG->>LG: Verify ZKP
LG-->>WD: Access Granted/Denied Confirmation
WD->>WD: Take Further Action (Unlock door, Authorize payment)
end
3.5. The "Inverse" or Failure Mode: Anonymous Threat Reporting with Identifier Purge
Enabling Description:
In public spaces, "threat detection beacons" (e.g., integrated into surveillance cameras, public safety kiosks) are equipped with UWB transceivers. These beacons normally transmit a unique identifier and a "public safety monitor" service identifier. The "wireless device" is any citizen's smartphone with UWB capability. If the user detects a threat (e.g., active shooter, suspicious package), they activate a "threat reporting" application on their phone. The application is designed such that when activated, it filters for "public safety monitor" beacons. If a beacon's unique identifier (UID) is present, indicating proximity to a surveillance point, the phone's "further action" is to generate an anonymous threat report. This report includes a timestamp, type of threat, and a highly obfuscated, single-use token derived from the beacon's UID, along with an approximate location (e.g., cell tower triangulation). Crucially, the actual beacon UID is never transmitted to the server, and the phone immediately purges the received UID from its memory after generating the token. This prevents the server from linking the threat report to a specific beacon or, more importantly, to the reporting individual. The report is sent via the second radio (cellular data) to an emergency response server. The server, having a pre-shared secret or algorithm for token verification, can infer the approximate origin of the report without compromising the privacy of the beacon or the reporter.
stateDiagram-v2
state Normal_Scan {
[*] --> Scanning
Scanning --> Threat_Detected_by_User : User Input
Threat_Detected_by_User --> Filter_Beacons : Filter by 'Public Safety Monitor' ServiceID
Filter_Beacons --> UID_Present : If UID detected
UID_Present --> Generate_Anonymous_Token : Create one-time token from UID, Location, Timestamp
Generate_Anonymous_Token --> Purge_UID : Delete raw UID from memory
Purge_UID --> Transmit_Anonymous_Report : Send token + threat details to Server
Transmit_Anonymous_Report --> Scanning : Return to Scanning
UID_Present --> Scanning : If UID not detected (no nearby beacon)
}
Derivatives of Independent Claim 17 (Method with Two Time Periods)
Claim 17: A method comprising: transmitting, by at least one beacon transmitter using a short range wireless radio, a first beacon transmission in a first time period, the beacon comprising a first unique identifier and a beacon service identifier; transmitting, by the at least one beacon transmitter using the short range wireless radio, a second beacon transmission in a second time period, the second beacon transmission comprising a second unique identifier and the beacon service identifier; receiving, by a wireless device using the short range wireless radio, a first plurality of beacon transmissions during the first time period; receiving, by the wireless device from one or more servers using a second radio, first stored information relating to an entity or object associated with the first unique identifier; receiving, by the wireless device using the short range wireless radio, a second plurality of beacon transmissions during the second time period; receiving, by the wireless device from one or more servers using the second radio, second stored information relating to an entity or object associated with the second unique identifier; selecting, by the wireless device, one or more unique identifiers from the first plurality of beacon transmissions, by filtering the first plurality of beacon transmissions which include the beacon service identifier; taking further action related to the first stored information, if the first unique identifier is present among the selected one or more unique identifiers; selecting, by the wireless device, a second set of one or more unique identifiers from the second plurality of beacon transmissions, by filtering the second plurality of beacon transmissions which include the beacon service identifier; and taking further action related to the second stored information, if the second unique identifier is present among the selected second set of one or more unique identifiers.
4.1. Material & Component Substitution: Inductive Coupling Beacons with RF Backscatter Network
Enabling Description:
The "short-range wireless radio" for beacon transmission is replaced with an inductive coupling coil, emitting a low-power, near-field magnetic signal. This signal is encoded with a unique identifier and a "proximity event" beacon service identifier. The "wireless device" is equipped with a matching inductive receiver coil. Its "second radio" is an RF backscatter communication module. In the first time period, an inductive beacon transmits its first UID. The wireless device receives this, performs filtering, and uses its backscatter module to reflect ambient RF energy (e.g., from a dedicated interrogator or general cellular signals), modulating it with the detected UID to transmit to a nearby RF backscatter reader (acting as a server gateway). In the second time period, the same inductive beacon transmits a different, second UID. The wireless device repeats the process, transmitting the second UID via backscatter. The "stored information" from the server, related to the first and second UIDs, is received via the wireless device's backscatter module (e.g., server modulates its response onto the ambient RF field, which the backscatter module passively receives). The "further action" might involve triggering a specific action based on the identified object, such as unlocking a smart cabinet (first UID) or initiating a machine calibration sequence (second UID), reflecting a change in the object's state across time periods.
sequenceDiagram
participant IBC as Inductive Beacon Coil
participant WD as Wireless Device (Inductive Receiver, RF Backscatter Tx/Rx)
participant RB as RF Backscatter Reader (Server Gateway)
participant S as Central Server
Note over IBC, WD: First Time Period
IBC->>WD: Inductive Pulse (UID1, ServiceID)
WD->>WD: Filter by ServiceID
WD->>RB: Backscatter UID1
RB->>S: Forward UID1
S->>S: Retrieve Stored Info1
S->>RB: Send Stored Info1
RB->>WD: Backscatter Stored Info1
WD->>WD: Take Further Action1
Note over IBC, WD: Second Time Period
IBC->>WD: Inductive Pulse (UID2, ServiceID)
WD->>WD: Filter by ServiceID
WD->>RB: Backscatter UID2
RB->>S: Forward UID2
S->>S: Retrieve Stored Info2
S->>RB: Send Stored Info2
RB->>WD: Backscatter Stored Info2
WD->>WD: Take Further Action2
4.2. Operational Parameter Expansion: Variable Altitude UAV-Based Beacons in Dynamic Airspace
Enabling Description:
This derivative applies the method to Unmanned Aerial Vehicles (UAVs) operating as mobile beacons in dynamic airspace. A fleet of UAVs (beacon transmitters) continuously transmits short-range Wi-Fi (802.11s mesh networking) beacons. These beacons include a unique identifier (UID) that changes based on the UAV's current mission phase or altitude, and an "air traffic management" beacon service identifier. In a first time period, a UAV transmits UID1 while patrolling at altitude X. In a second time period, the same UAV transmits UID2 while descending to altitude Y. Ground control stations or other manned/unmanned aircraft (wireless devices) are equipped with Wi-Fi 802.11s transceivers for short-range detection and satellite communication modules for the "second radio." The wireless device receives a plurality of Wi-Fi beacons and filters them by the "air traffic management" service identifier. The "stored information" from an Air Traffic Control (ATC) server (via satellite link) includes real-time flight plans, no-fly zones, and potential collision alerts associated with UID1 and UID2. The "further action" involves dynamic route adjustments, visual/auditory alerts to pilots, or automatic communication with other aircraft to maintain separation, adapting to the changing state of the beaconing UAV.
graph TD
A[UAV Beacon (UAV1, Alt X)] -->|Wi-Fi 802.11s (UID1, ServiceID)| B(Wireless Device (Aircraft/GCS))
B -->|SATCOM (UID1)| C[ATC Server]
C -->|Stored Info1| B
B --> F1{Filter by ServiceID}
F1 --> G1{UID1 Present?}
G1 -- Yes --> H1[Take Further Action (Route Adj. 1)]
subgraph Second Time Period
D[UAV Beacon (UAV1, Alt Y)] -->|Wi-Fi 802.11s (UID2, ServiceID)| B
B -->|SATCOM (UID2)| C
C -->|Stored Info2| B
B --> F2{Filter by ServiceID}
F2 --> G2{UID2 Present?}
G2 -- Yes --> H2[Take Further Action (Route Adj. 2)]
end
4.3. Cross-Domain Application: Dynamic Inventory Management in Retail Logistics
Enabling Description:
In a large retail warehouse, palletized goods are equipped with Bluetooth 5.2 (LE Audio) beacons. Each pallet beacon transmits a unique identifier that changes based on its inventory status (e.g., "in transit," "awaiting restock," "available for pick") and a "logistics management" beacon service identifier. Autonomous inventory robots (wireless devices) equipped with BLE 5.2 receivers patrol the warehouse. Their "second radio" is a private 5G mmWave network connection to a central Warehouse Management System (WMS) server. In a first time period, a robot detects a pallet transmitting UID1 ("in transit"). It reports this to the WMS, which provides "first stored information" (e.g., destination, expected arrival). The robot takes "further action" to confirm its transit. In a second time period, the same pallet is moved and updates its beacon to UID2 ("available for pick"). The robot detects UID2, reports it to the WMS, which provides "second stored information" (e.g., specific shelf location, picking instructions). The robot then takes "further action" to route other robots for picking. This system dynamically updates inventory status and associated instructions in real-time as product states change, improving warehouse efficiency.
sequenceDiagram
participant PB as Pallet Beacon (BLE 5.2)
participant AIR as Autonomous Inventory Robot (BLE 5.2 Rx, 5G mmWave)
participant WMS as Warehouse Management System (Server)
Note over PB, AIR: First Time Period (Pallet "In Transit")
PB->>AIR: Beacon (UID1, ServiceID 'Logistics Management')
AIR->>AIR: Filter by ServiceID
AIR->>WMS: Report UID1 (via 5G mmWave)
WMS->>WMS: Retrieve Stored Info1 (Destination, ETA)
WMS-->>AIR: Stored Info1
AIR->>AIR: Take Further Action (Confirm Transit)
Note over PB, AIR: Second Time Period (Pallet "Available for Pick")
PB->>AIR: Beacon (UID2, ServiceID 'Logistics Management')
AIR->>AIR: Filter by ServiceID
AIR->>WMS: Report UID2 (via 5G mmWave)
WMS->>WMS: Retrieve Stored Info2 (Shelf Location, Pick Instructions)
WMS-->>AIR: Stored Info2
AIR->>AIR: Take Further Action (Route Pick Robots)
4.4. Integration with Emerging Tech: Predictive Maintenance with Digital Twin Synchronization
Enabling Description:
Industrial machinery (beacon transmitters) in a manufacturing plant are fitted with NFC-enabled diagnostic tags. These tags generate a unique identifier that cyclically changes (e.g., every 30 minutes) based on a pseudo-random sequence, alongside a "predictive maintenance" beacon service identifier. The "wireless device" is a mobile inspection drone equipped with an NFC reader. Its "second radio" is an industrial Wi-Fi 6E link to a central Predictive Maintenance (PM) server hosting digital twins of the machinery. In a first time period, the drone detects UID1 from a machine. It sends UID1 to the PM server. The server, knowing the machine's pseudo-random sequence, associates UID1 with the correct machine's digital twin and provides "first stored information" (e.g., current sensor readings, scheduled maintenance tasks). The drone takes "further action" to perform a visual inspection. In a second time period, the machine updates its tag to UID2. The drone detects UID2, sends it to the server, and receives "second stored information" (e.g., an anomaly detection alert from the digital twin, suggesting imminent failure). The "further action" is to immediately flag the machine for critical inspection and schedule an intervention. This system ensures that even with dynamic identifiers, the digital twin remains synchronized with the physical asset's current state and enables proactive maintenance.
flowchart TD
A[Industrial Machine w/ NFC Diagnostic Tag] -- NFC (UID_t1, ServiceID 'PM') --> D[Inspection Drone (NFC Reader, Wi-Fi 6E)]
D -- Wi-Fi 6E (UID_t1) --> PMS[Predictive Maintenance Server (Digital Twin)]
PMS -- Stored Info_t1 --> D
D --> F1{Filter by ServiceID}
F1 --> G1{UID_t1 Present?}
G1 -- Yes --> H1[Take Further Action (Visual Inspection)]
subgraph Second Time Period
A -- NFC (UID_t2, ServiceID 'PM') --> D
D -- Wi-Fi 6E (UID_t2) --> PMS
PMS -- Stored Info_t2 (Anomaly Alert) --> D
D --> F2{Filter by ServiceID}
F2 --> G2{UID_t2 Present?}
G2 -- Yes --> H2[Take Further Action (Critical Alert, Schedule Intervention)]
end
4.5. The "Inverse" or Failure Mode: Time-Limited Access Control with Identifier Expiration
Enabling Description:
In a secure facility, access points (beacon transmitters) are equipped with NFC readers and continuously broadcast unique identifiers (UIDs) that are valid for a very short duration (e.g., 5 seconds) before expiring, along with an "access control" beacon service identifier. These UIDs are time-synchronized with a central access control server. An authorized employee's badge or smartphone (wireless device) acts as the receiver. Its "second radio" is a dedicated secure Wi-Fi channel to the access control server. In a first time period, the employee's device detects UID1 from an access point. The device sends UID1 to the server. The server verifies UID1's validity (i.e., it hasn't expired) and provides "first stored information" (e.g., authorization for temporary access). The device takes "further action" to display a "tap to unlock" prompt. If the employee doesn't interact within the validity window, the UID expires. In a second time period, the access point transmits a new UID2. The device detects UID2, but if the employee's prior "further action" (tap to unlock) failed or timed out, it might receive "second stored information" indicating denial of access for UID2. This "inverse" aspect means that the default mode of operation leads to denial if not acted upon rapidly, enforcing strict, time-limited security. The rapid expiration of UIDs prevents replay attacks.
sequenceDiagram
participant AP as Access Point (NFC Beacon)
participant ED as Employee Device (NFC Reader, Secure Wi-Fi)
participant ACS as Access Control Server
Note over AP, ED: First Time Period (UID1 valid 5s)
AP->>ED: Beacon (UID1, ServiceID 'Access Control')
ED->>ED: Filter by ServiceID
ED->>ACS: Send UID1 (via Secure Wi-Fi)
ACS->>ACS: Validate UID1 (check expiration, authorization)
ACS-->>ED: Stored Info1 (Temporary Auth)
ED->>ED: Take Further Action (Display "Tap to Unlock")
Note over AP, ED: Second Time Period (UID2 valid 5s)
AP->>ED: Beacon (UID2, ServiceID 'Access Control')
ED->>ED: Filter by ServiceID
alt Previous action timed out OR UID1 Expired
ED->>ACS: Send UID2
ACS->>ACS: Validate UID2 (check expiration, authorization)
ACS-->>ED: Stored Info2 (Denial)
ED->>ED: Take Further Action (Display "Access Denied")
else Previous action successful
ED->>ACS: Send UID2
ACS->>ACS: Validate UID2
ACS-->>ED: Stored Info2 (Auth Granted)
ED->>ED: Take Further Action (Unlock Door)
end
Derivatives of Independent Claim 18 (Method with Broadcast Device Determination)
Claim 18: A method comprising: transmitting, by at least one beacon transmitter using a short range wireless radio, a first beacon transmission in a first time period, the beacon comprising a first unique identifier and a beacon service identifier; receiving, by a wireless device using the short range wireless radio, a first plurality of beacon transmissions during the first time period; receiving, by the wireless device from one or more servers using a second radio, stored information relating to an entity or object associated with the first unique identifier; selecting, by the wireless device, one or more unique identifiers from the first plurality of beacon transmissions, by filtering the first plurality of beacon transmissions which include the beacon service identifier; and taking further action, if the first unique identifier is present among the selected one or more unique identifiers, using the stored information, which includes at least the identity of the entity or object associated with the first unique identifier, wherein the further action includes determining that at least one beacon transmitter is a broadcast device having a predetermined location.
5.1. Material & Component Substitution: Directed Acoustic Beacons with Millimeter-Wave Link
Enabling Description:
In this derivative, the "short-range wireless radio" is a directed acoustic transducer embedded in a ceiling tile, emitting a highly localized, inaudible ultrasonic beam. This beam carries a unique identifier for the specific location/zone (e.g., "Conference Room A corner") and a "spatial context" beacon service identifier. The "wireless device" is a smartphone with a microphone array capable of directional acoustic reception and processing. Its "second radio" is a high-bandwidth 60 GHz mmWave link to a local edge server. Upon receiving an acoustic beacon, the smartphone's processors filter the signals to extract the unique identifier and verify the "spatial context" service identifier. The "stored information" from the edge server (via mmWave) includes rich media content, such as a 3D model of the room, specific meeting agenda for that corner, or localized advertising. The "further action" specifically determines that the acoustic emitter is a broadcast device with a predetermined location (derived from the unique identifier itself or pre-mapped in the server's database) and then renders an augmented reality (AR) overlay on the smartphone's display, showing virtual objects anchored precisely to physical points within the room, demonstrating knowledge of the broadcast device's fixed position.
graph TD
A[Directed Acoustic Beacon (Ceiling Tile)] -->|Ultrasonic Beam (UID, ServiceID 'Spatial Context')| B(Smartphone w/ Mic Array)
B -->|60 GHz mmWave (UID)| C[Local Edge Server]
C -->|Stored Info (3D Model, Content)| B
B --> D{Filter by ServiceID}
D --> E{UID Present?}
E -- Yes --> F[Take Further Action (Determine Predetermined Location, Render AR Overlay)]
5.2. Operational Parameter Expansion: High-Power, Long-Range HF/VHF Beacons for Remote Wilderness Tracking
Enabling Description:
This derivative utilizes the method for tracking in remote, unpopulated areas. "Beacon transmitters" are ruggedized, high-power High-Frequency (HF) or Very High-Frequency (VHF) radio beacons, deployed in designated wilderness zones or on remote scientific equipment. These beacons transmit a unique identifier (e.g., "Research Station Alpha," "Wildlife Zone 7") and a "wilderness monitoring" beacon service identifier over distances of tens to hundreds of kilometers. The "wireless device" is an autonomous reconnaissance drone or a specialized ranger's handheld radio with an HF/VHF receiver. Its "second radio" is a long-range, low-bandwidth satellite data link (e.g., Inmarsat BGAN). The drone/radio receives the HF/VHF beacon signals and filters them by the "wilderness monitoring" service identifier. The "stored information" from a central command server (via satellite) includes up-to-date topographical maps, satellite imagery, and environmental data pertaining to the unique identifier's zone. The "further action" specifically determines that the HF/VHF beacon is a broadcast device having a predetermined, geographically vast location. This then enables the drone to initiate patrol routes around the identified zone, monitor local sensor data linked to the beacon, or guide search-and-rescue teams to the precise predetermined location.
flowchart TD
A[HF/VHF Wilderness Beacon] -->|HF/VHF Radio Wave (UID, ServiceID 'Wilderness Monitoring')| B(Reconnaissance Drone/Ranger Radio)
B -->|SATCOM (UID)| C[Central Command Server]
C -->|Stored Info (Maps, Env. Data)| B
B --> D{Filter by ServiceID}
D --> E{UID Present?}
E -- Yes --> F[Take Further Action (Determine Predetermined Location, Initiate Patrol/SAR Guidance)]
5.3. Cross-Domain Application: Smart Retail Shelf Advertising
Enabling Description:
In a retail store, individual smart shelves are equipped with extremely short-range UWB (Ultra-Wideband) beacons. Each shelf beacon broadcasts a unique identifier representing the product category on that shelf and a "dynamic retail offer" beacon service identifier. A customer's smartphone, acting as the "wireless device," has an integrated UWB receiver. Its "second radio" is the phone's standard cellular data connection to the store's retail server. When a customer walks by a shelf, their smartphone detects the UWB beacon and filters for the "dynamic retail offer" service identifier. The "stored information" from the retail server (via cellular) is a highly personalized advertisement, discount coupon, or product recommendation tailored to that customer's purchasing history and current proximity to the specific product category. The "further action" by the smartphone specifically determines that the UWB beacon is a broadcast device fixed to a predetermined location (the shelf). It then triggers a contextual display of the personalized offer on the phone, tied directly to the products physically present on that shelf. This allows for hyper-localized, real-time marketing.
sequenceDiagram
participant SB as Smart Shelf UWB Beacon
participant CS as Customer Smartphone (UWB Rx, Cellular)
participant RS as Retail Server
SB->>CS: Transmit Beacon (UID_Shelf, ServiceID 'Dynamic Retail Offer')
CS->>CS: Filter by ServiceID
alt UID_Shelf Present
CS->>RS: Send UID_Shelf (via Cellular)
RS->>RS: Retrieve Stored Info (Personalized Ad/Coupon)
RS-->>CS: Stored Info
CS->>CS: Take Further Action (Determine Predetermined Location (Shelf), Display Personalized Offer)
end
5.4. Integration with Emerging Tech: Environmental Sensor Network with Digital Twin Registration
Enabling Description:
This derivative concerns an extensive environmental sensor network (e.g., smart agriculture fields, smart forests). Each individual sensor node acts as a "beacon transmitter," equipped with a low-power LoRa (Long Range) radio. It transmits a unique identifier (representing the sensor's ID and type) and an "environmental monitoring" beacon service identifier. The location of each sensor node is precisely surveyed and stored as a predetermined location. An autonomous drone (wireless device) with a LoRa receiver patrols the area. Its "second radio" is a 5G cellular modem for connection to a cloud-based environmental monitoring server that hosts a digital twin of the entire sensor network. When the drone detects a LoRa beacon, it filters by the "environmental monitoring" service identifier. The "stored information" from the server includes the sensor's calibration data, historical readings, and its precise GPS coordinates in the digital twin. The "further action" by the drone determines that the LoRa beacon is a broadcast device with a predetermined location (the fixed sensor node). It then initiates a visual inspection of the sensor, collects its localized data (if available via a secondary, very short-range link, or wirelessly from the beacon payload itself), and updates the digital twin with the drone's confirmation of the sensor's presence and operational status. The drone's real-time location and camera feeds also augment the digital twin.
graph TD
A[Environmental Sensor Node (LoRa Beacon)] -->|LoRa (UID, ServiceID 'Env. Monitoring')| B(Autonomous Drone (LoRa Rx, 5G Modem))
B -->|5G Cellular (UID)| C[Environmental Monitoring Server (Digital Twin)]
C -->|Stored Info (Calibration, GPS)| B
B --> D{Filter by ServiceID}
D --> E{UID Present?}
E -- Yes --> F[Take Further Action (Determine Predetermined Location, Visual Inspect Sensor, Update Digital Twin)]
5.5. The "Inverse" or Failure Mode: Geofence Breach Alert with "Last Known Good" Location
Enabling Description:
Mobile assets (e.g., construction equipment, cargo containers) are equipped with short-range UWB beacons. These beacons normally transmit a unique identifier and a "geofence monitoring" beacon service identifier. These assets are confined to a predefined "predetermined location" (a geofence zone). Perimeter guard robots or stationary receivers (wireless devices) are equipped with UWB receivers and cellular modems (second radio) connected to a central security server. If an asset (beacon transmitter) moves outside its predetermined geofence, its UWB beacon is configured to transition to a "geofence breach" mode. In this mode, it still transmits its unique identifier but may also include a "breach status" flag or a simplified, intermittent beacon signal. When a guard robot detects this "breach mode" beacon, its "further action" immediately determines that the beacon was a broadcast device having a predetermined location, but is now indicating a deviation. The "stored information" from the security server, in response to this breach alert, includes the asset's "last known good" location (within the geofence) and emergency response protocols. The "further action" taken by the guard robot is to sound an alarm, send immediate alerts to human security personnel, and initiate tracking procedures based on the "last known good" location, rather than attempting to retrieve detailed information about the asset's current (breaching) location, thus prioritizing rapid response to the detected failure mode (breach of predetermined location).
stateDiagram-v2
state Normal_Operation {
[*] --> In_Geofence
In_Geofence --> Transmitting_Normal_Beacon : UWB (UID, ServiceID 'Geofence Monitoring')
Transmitting_Normal_Beacon --> In_Geofence : Detected by WD, Status OK
In_Geofence --> Out_of_Geofence : Asset Moves Out
}
state Geofence_Breach_Mode {
Out_of_Geofence --> Transmitting_Breach_Beacon : UWB (UID, ServiceID 'Geofence Breach', Breach Flag)
Transmitting_Breach_Beacon --> Alert_Server : Detected by Guard Robot WD
Alert_Server --> Response_Received : Server retrieves 'Last Known Good' Location, Protocols
Response_Received --> Trigger_Emergency_Action : Alarm, Alerts, Tracking Initiation
}
Out_of_Geofence --> Geofence_Breach_Mode
Generated 5/18/2026, 6:50:22 PM