Derivative works — US Patent 11443344

Defensive Disclosure for US Patent 11443344

This document outlines derivative variations of the core claims of US Patent 11443344, "Efficient and secure communication using wireless service identifiers," to serve as defensive publications. The goal is to establish prior art that would render future incremental improvements by competitors obvious or non-novel, thereby limiting the patentability landscape.

The core claims of US11443344 revolve around a system and method for secure and efficient communication utilizing short-range wireless beacon transmissions (e.g., Bluetooth or Wi-Fi) for proximity detection and identification, coupled with a central server over a long-range wireless network (WWAN) for brokering communication, managing identity, applying policies, and delivering content.

Independent Claim 1 (Method Claim)

The method involves:

A beacon transmitter sends out a short-range wireless beacon (e.g., Bluetooth or Wi-Fi) containing a unique identifier, a MAC address, and a beacon service identifier.
A wireless device receives these beacon transmissions.
The wireless device filters these transmissions, only selecting those that contain a specific beacon service identifier.
The wireless device then performs an action based on whether a particular unique identifier from the filtered beacons is present. This action uses information about the entity associated with that unique identifier, which is obtained from one or more servers via a separate, long-range radio connection. The information from the server can be pre-downloaded or requested when the unique identifier is detected.

Derivative Variations for Claim 1

1. Material & Component Substitution: Deploying Ultra-Low Power Acoustic Beacons with Piezoelectric Transducers

Enabling Description:
Instead of traditional RF-based short-range wireless radios (Bluetooth/Wi-Fi), this derivative employs ultra-low power acoustic beacons utilizing piezoelectric transducers for transmitting the beacon signal. Each acoustic beacon comprises a miniature microcontroller (e.g., ARM Cortex-M0+) interfaced with a piezoelectric transducer capable of generating ultrasonic frequencies (e.g., 20 kHz to 100 kHz). The unique identifier, MAC address (or an acoustically encoded pseudo-MAC), and a specific acoustic "beacon service identifier" (a unique frequency signature or modulated pulse sequence) are encoded into the ultrasonic signal using frequency-shift keying (FSK) or pulse-position modulation (PPM). The receiving wireless device integrates a micro-electromechanical system (MEMS) microphone array coupled with a low-power digital signal processor (DSP) for acoustic signal reception and demodulation. The DSP applies a Fast Fourier Transform (FFT) or matched filtering algorithm to detect the specific acoustic beacon service identifier and extract the encoded unique identifier. The long-range communication to the central server remains via a standard WWAN cellular modem, transmitting the detected acoustic unique identifier. The server then processes the request as per the original patent. Power optimization for the acoustic beacons can involve duty cycling the transmission at intervals of several seconds to minimize energy consumption.

graph TD
    A[Acoustic Beacon Transmitter] --> B{Piezoelectric Transducer};
    B --> C{Ultrasonic Signal <br/>(Encoded ID, MAC, Service ID)};
    C --> D[Ambient Medium (Air/Water)];
    D --> E{MEMS Microphone Array};
    E --> F{Low-Power DSP <br/>(FFT/Matched Filter)};
    F --> G{Wireless Device <br/>(Detected Acoustic ID)};
    G --> H[WWAN Cellular Modem];
    H --> I[Central Server];
    I -- Policy/Content --> G;

2. Operational Parameter Expansion: Interplanetary Proximity Detection for Swarm Robotics with Gravitational Wave Modulators

Enabling Description:
This variation extends the concept to an interplanetary scale for swarm robotics, operating in the vacuum of space at extremely low frequencies or using modulated gravitational waves for detection (a theoretical future technology, but within the bounds of "extreme scales"). Each robotic probe in a swarm (beacon transmitter) is equipped with a highly sensitive gravitational wave modulator (or, more practically for current tech, an extremely low-frequency radio transmitter operating in the kHz range with a massive antenna array). The beacon transmits a unique probe identifier, a dynamically assigned pseudo-MAC for the swarm node, and a gravitational wave (or ELF radio) "swarm service identifier." The signals are detected by receiving probes using highly specialized gravitational wave interferometers (or ELF receivers with advanced noise cancellation and signal integration over long periods). The filtering for the "swarm service identifier" involves identifying a unique wave signature or modulation pattern. Due to the extreme distances and low signal-to-noise ratios, the "further action" on the receiving probe includes extensive error correction and signal reconstruction before transmitting the detected identifier and its own status via a deep-space communication link (e.g., X-band or Ka-band satellite communication) to a central, Earth-based mission control server. The server then applies mission-specific policies, such as re-tasking based on proximity, resource allocation, or fault detection.

graph TD
    A[Robotic Probe (Beacon)] --> B{Gravitational Wave Modulator / ELF Antenna};
    B --> C{Modulated Gravitational/ELF Signal <br/>(Probe ID, Pseudo-MAC, Swarm Service ID)};
    C --> D[Interplanetary Space];
    D --> E{Gravitational Wave Interferometer / ELF Receiver};
    E --> F{Signal Processing Unit <br/>(Error Correction, Filtering)};
    F --> G{Receiving Robotic Probe <br/>(Detected Probe ID)};
    G --> H[Deep-Space Comm Link];
    H --> I[Mission Control Server (Earth)];
    I -- Mission Policy/Content --> G;

3. Cross-Domain Application: Precision Agriculture for Crop Health Monitoring

Enabling Description:
In precision agriculture, this mechanism is applied to autonomous agricultural drones (beacon transmitters) and ground-based sensor nodes (wireless devices) for real-time crop health monitoring. Each drone periodically transmits a short-range beacon using a directional millimeter-wave (mmWave) radio (e.g., 60 GHz band) containing a unique drone identifier, a regional plot identifier (as the MAC address equivalent), and a "crop health service identifier." Ground-based sensor nodes, deployed throughout the fields, are equipped with mmWave receivers. These nodes detect drone beacons, filter for the "crop health service identifier," and identify passing drones. Upon detection of a relevant drone identifier, the ground sensor node transmits its own geo-tagged environmental data (e.g., soil moisture, temperature, nutrient levels) and the detected drone identifier via a LoRaWAN (long-range wide-area network) connection to a central farm management server. The server then cross-references drone flight patterns, sensor data, and satellite imagery to generate localized crop health reports, trigger automated irrigation, or dispatch specific treatments.

graph TD
    A[Agricultural Drone (Beacon)] --> B{Directional mmWave Radio};
    B --> C{mmWave Beacon <br/>(Drone ID, Plot ID, Crop Health Service ID)};
    C --> D[Crop Field];
    D --> E{Ground Sensor Node <br/>(mmWave Receiver)};
    E --> F{Filtering Module <br/>(Crop Health Service ID)};
    F --> G{LoRaWAN Transmitter};
    G --> H[Farm Management Server];
    H -- Crop Health Report/Actions --> G;

4. Integration with Emerging Tech: AI-Driven Adaptive Beacon Scheduling with IoT Sensor Fusion and Blockchain Identity

Enabling Description:
This derivative integrates AI-driven optimization for beacon scheduling, IoT sensors for enhanced context, and blockchain for decentralized identity management. Each beacon transmitter (e.g., an IoT device in a smart city environment) emits a short-range Bluetooth Low Energy (BLE) beacon. The unique identifier within the beacon is a Decentralized Identifier (DID) anchored to a public blockchain network (e.g., Ethereum). The "beacon service identifier" is a hash of a smart contract address on the same blockchain. The wireless device receives these BLE beacons. An onboard AI agent, trained on local environmental data from fused IoT sensors (e.g., air quality, ambient light, pedestrian density), dynamically adjusts its filtering criteria for beacon service identifiers and prioritizes which detected DIDs to interact with. For example, in a high-density area, only beacons with specific environmental service identifiers might be prioritized. When a relevant DID is detected, the wireless device initiates a secure communication with the central server (via 5G/Wi-Fi 6). The server, which acts as an off-chain oracle, queries the blockchain to verify the detected DID's authenticity and retrieve associated verifiable credentials and policy information stored in a distributed ledger. The AI on the server, fed with real-time IoT data and historical interaction patterns, then optimizes the "further action," such as pushing hyper-localized advertisements, smart city alerts, or facilitating peer-to-peer verifiable data exchange, all while respecting the privacy policies encoded in the blockchain-based identity. The AI also dynamically adjusts the beacon's transmission power and interval based on network congestion and environmental factors to optimize energy efficiency.

graph TD
    A[IoT Beacon Device] --> B{BLE Transmitter};
    B --> C{BLE Beacon <br/>(Blockchain DID, MAC, Hashed Smart Contract ID)};
    C --> D[Wireless Device <br/>(IoT Sensor Fusion, AI Agent)];
    D -- Detected DID + Sensor Data --> E[5G/Wi-Fi 6 Modem];
    E --> F[Central Server <br/>(AI Optimization, Off-chain Oracle)];
    F --> G[Public Blockchain Network];
    G -- Verifiable Credentials/Policies --> F;
    F -- Hyper-localized Content/Actions --> D;

5. The "Inverse" or Failure Mode: Stealth Mode Beacon for Covert Asset Tracking with Emergency Locator Override

Enabling Description:
This derivative describes a "stealth mode" beacon system designed for covert asset tracking, with an inverse feature of an emergency locator override. Each asset is equipped with a specialized beacon transmitter employing ultra-narrowband, spread-spectrum radio technology operating at extremely low power (e.g., -40 dBm, sub-GHz frequencies) to minimize detectability. The beacon transmits a highly obfuscated unique asset identifier and a pseudo-random MAC address, with a "stealth service identifier" that is a very faint, infrequent pulse sequence detectable only by specialized receivers with long integration times. The wireless device (a designated tracking unit) employs a high-sensitivity, multi-channel software-defined radio (SDR) with advanced digital signal processing for correlation detection to identify these stealth beacons, effectively "filtering" for the faint stealth service identifier. In its failure mode, or upon detection of a specific emergency condition (e.g., tamper detection, critical battery level, or remote activation from the central server), the beacon enters an "emergency locator override" mode. In this mode, it switches to a higher power output (e.g., 0 dBm) and broadcasts a distinct, easily detectable "emergency service identifier" (e.g., a standard LoRaWAN beacon with a pre-defined emergency payload) and a clear, non-obfuscated emergency asset identifier. The tracking unit (wireless device) then rapidly transmits the emergency asset identifier and its own precise GPS coordinates via its WWAN connection to the central server. The central server, which typically maintains the mapping of obfuscated to clear identifiers, receives this emergency alert and initiates a rapid response protocol.

stateDiagram-v2
    state "Stealth Mode" as Stealth
    state "Emergency Locator Override" as Emergency

    Stealth --> Emergency: Emergency Condition Detected / Remote Activation
    Emergency --> Stealth: Emergency Resolved / Deactivation Command

    Stealth: Ultra-narrowband, low power transmission
    Stealth: Obfuscated Asset ID, Pseudo-random MAC, Stealth Service ID
    Stealth: Receivers use SDR with long integration for detection
    Emergency: Higher power, standard LoRaWAN beacon transmission
    Emergency: Clear Emergency Asset ID, Emergency Service ID
    Emergency: Tracking Unit transmits GPS + Emergency ID to server

Combination Prior Art Scenarios

These scenarios combine the teachings of US11443344 with existing open-source standards, demonstrating how the patented concepts could be rendered obvious by leveraging publicly available technologies and specifications.

1. Integration with Open-Source Bluetooth LE Beacon Standards (e.g., Eddystone)

Combination:
The method of US11443344 (Claim 1) is combined with the open-source Eddystone protocol for Bluetooth Low Energy (BLE) beacons.
Description:
A beacon transmitter utilizes an off-the-shelf BLE module running the Eddystone-UID frame type. The Eddystone-UID frame carries a 16-byte Namespace ID and a 6-byte Instance ID. The unique identifier of US11443344 is represented by the combination of the Namespace ID and Instance ID. The "beacon service identifier" is implicitly handled by the Eddystone-UID frame type itself, which scanners can filter for. The MAC address is the standard BLE MAC address of the transmitting device. The wireless device receives these Eddystone-UID beacons and filters specifically for the Eddystone-UID frame type. Upon detecting a relevant Namespace ID/Instance ID combination, the wireless device accesses a pre-downloaded local database (populated from the central server via WWAN) or requests information from the central server about the entity associated with that Namespace ID/Instance ID. This information (e.g., product details, promotional offers, user profile links) is then used for a "further action," such as displaying content or initiating a transaction.

2. Integration with Open-Source Wi-Fi Ad-Hoc Mode (IBSS) and OpenWrt

Combination:
The method of US11443344 (Claim 1) is combined with an Independent Basic Service Set (IBSS) Wi-Fi network (ad-hoc mode) where devices run the open-source OpenWrt firmware.
Description:
A beacon transmitter, running OpenWrt on its Wi-Fi module, is configured to operate in IBSS mode and periodically transmit Wi-Fi beacon frames. The unique identifier of US11443344 is encoded within a custom Information Element (IE) in the beacon frame, or as the Service Set Identifier (SSID) itself. The MAC address is the standard Wi-Fi MAC address of the device. The "beacon service identifier" is a specific pattern within the custom IE, or a predefined SSID format (e.g., "Service-XYZ_"). A wireless device, also running OpenWrt, scans for Wi-Fi networks and specifically parses beacon frames for the designated "beacon service identifier" within the custom IE or matches the SSID pattern. Upon detecting a relevant unique identifier, the wireless device uses its cellular/WWAN connection to communicate with a central server. The server, acting as a registry for these OpenWrt-enabled IBSS devices, provides information (e.g., network configuration parameters, content to be shared, user presence data) related to the detected device, enabling the "further action" on the wireless device, such as establishing a peer-to-peer Wi-Fi Direct connection or displaying service information.

3. Integration with LoRaWAN for Long-Range Beaconing and Edge Computing

Combination:
The method of US11443344 (Claim 1) is integrated with LoRaWAN (Long Range Wide Area Network) for the short-range beacon transmission, extending the "short range" to several kilometers, and leveraging edge computing for initial filtering.
Description:
A beacon transmitter, such as a low-power IoT sensor, periodically sends out a LoRaWAN uplink message formatted as a "beacon transmission." This message contains a unique device identifier (EUI64), a pseudo-randomized session key (as a MAC address equivalent), and a "LoRaWAN service identifier" encoded in the payload. The "short-range wireless radio" in this context is the LoRa radio. A wireless device, such as a mobile gateway or another LoRa-enabled end-device acting as a scanner, receives these LoRaWAN beacon transmissions. An edge computing module integrated into or co-located with the mobile gateway (wireless device) performs initial filtering of the received LoRaWAN payloads to select only those including the "LoRaWAN service identifier." If a unique device identifier is present among the filtered transmissions, the edge module performs a preliminary "further action," such as locally caching associated metadata. The complete beacon data and detected unique identifiers are then forwarded via the mobile gateway's WWAN connection to a central server. The server holds comprehensive data related to the unique identifiers and performs more complex policy enforcement and content delivery, responding to the mobile gateway which then relays relevant information to the end-user on the wireless device. This architecture enables sparse deployments over large geographical areas with minimal power consumption for the beacons.