Derivative works

Defensive Disclosure and Prior Art Generation for U.S. Patent 11,080,001

Document ID: DPD-11080001-20260426
Publication Date: 2026-05-13
Subject Patent: U.S. Patent No. 11,080,001 ("Concurrent transmission and playback of audio information")
Core Inventive Concept: A method for a master media playback device to transfer its role to a slave device within a synchronized group by sending a message containing the state of the audio, its own network address, and the audio source's network address.

This document discloses a series of technical implementations, variations, and applications derived from the core concept of the subject patent. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing them as prior art for any future patent applications in this field.

---

1. Material & Component Substitution

1.1. Master/Slave Role Transfer over Optical Li-Fi Networks

• Enabling Description: The network interface (41) of each zone player is replaced with a Light Fidelity (Li-Fi) transceiver. Communication occurs via modulated visible light. In this embodiment, the master device transfer message is encoded into the light stream. This is advantageous in environments with high radio-frequency (RF) interference, such as hospitals or aircraft. The "network address" in the transfer message is a unique Li-Fi node identifier assigned by a central Li-Fi access point. The audio source information points to a network-attached storage (NAS) device connected to the same Li-Fi/Ethernet backbone. The transfer protocol remains logically the same, but the physical layer is optical, requiring line-of-sight, which also enhances security.

• Mermaid Diagram:

  sequenceDiagram
      participant M as Master (Li-Fi)
      participant S1 as Slave 1 (Li-Fi)
      participant S2 as New Master (Li-Fi)
      participant AP as Li-Fi Access Point
  
      M->>AP: Stream Audio Data
      AP-->>M: Modulated Light
      AP-->>S1: Modulated Light
      AP-->>S2: Modulated Light
      Note over M,S2: Synchronized Playback in Progress
      M->>M: User initiates transfer to S2
      M->>AP: Transmit[TransferMsg(AudioState, M_Addr, Src_Addr)] to S2
      AP->>S2: Relays TransferMsg via light
      S2->>AP: Acknowledge Transfer
      S2->>AP: Request Audio Stream from Src_Addr
      Note over S2,S1: S2 is now Master
  

1.2. Role Transfer Using Non-Volatile Ferroelectric RAM (FRAM)

• Enabling Description: Each playback device's control module (42) utilizes Ferroelectric RAM (FRAM) for storing the synchrony group's state table (master address, slave list, current playlist URI, track position). FRAM offers fast write speeds and non-volatility. In a "sudden death" failure of the master (e.g., power loss), a designated successor slave, determined by a pre-arranged priority list, polls the last-known master. Upon non-response, the successor broadcasts a "master assumption" message. Other slaves then query the new master, which serves the group state directly from its own up-to-date FRAM copy. This eliminates the need for a formal transfer message from the dying master, enabling a more resilient failover. The "transfer" is implicit, based on the availability of the state in each device's non-volatile memory.

• Mermaid Diagram:

  stateDiagram-v2
      Master: Group State (FRAM)
      Slave_1: Group State (FRAM)
      Slave_2: Group State (FRAM)
  
      [*] --> Active
      Active: Master Active, All slaves sync FRAM state via heartbeat
      Master --> Failure: Power Loss
      Failure --> Election
      Election: Slaves detect heartbeat loss
      Slave_1 --> New_Master: Highest Priority Assumes Role
      New_Master: Broadcasts "New Master" message
      Slave_2 --> New_Master: Acknowledges new master
      New_Master --> Active
  

---

2. Operational Parameter Expansion

2.1. Stadium-Scale Synchronized Audio with Hierarchical Mastership

• Enabling Description: For a system with thousands of speaker nodes (e.g., a stadium or large campus), a single master creates a bottleneck. This variation introduces a hierarchical master structure. A "Grand Master" (GM) device synchronizes with the primary audio source. The GM does not send audio to all nodes directly. Instead, it sends audio and timing information to a set of "Regional Masters" (RMs), for instance, one per stadium section. Each RM acts as the master for its local synchrony group of slave speakers. If an RM fails, one of its slaves is promoted to RM, and the change is reported to the GM. If the GM itself needs to be replaced, it sends a transfer message to a designated backup GM, which then re-establishes connections with all RMs. The transfer message includes the list of RM network addresses.

• Mermaid Diagram:

  graph TD
      subgraph Internet Audio Source
          Src[Audio Source]
      end
      subgraph Control Network
          GM[Grand Master] --- BGM[Backup Grand Master]
          GM -- Audio+Timing --> RM1[Regional Master Sec. A]
          GM -- Audio+Timing --> RM2[Regional Master Sec. B]
          GM -- Audio+Timing --> RM3[Regional Master Sec. C]
      end
  
      subgraph Section_A_Speakers
          RM1 --> S1_A[Slave 1A]
          RM1 --> S2_A[Slave 2A]
          RM1 --> SN_A[Slave nA]
      end
      subgraph Section_B_Speakers
          RM2 --> S1_B[Slave 1B]
          RM2 --> S2_B[Slave 2B]
          RM2 --> SN_B[Slave nB]
      end
      subgraph Section_C_Speakers
          RM3 --> S1_C[Slave 1C]
          RM3 --> S2_C[Slave 2C]
          RM3 --> SN_C[Slave nC]
      end
  

2.2. Synchronized Playback in Cryogenic Environments

• Enabling Description: The system is implemented for synchronizing data acquisition from an array of superconducting quantum interference devices (SQUIDs) operating at cryogenic temperatures (near 4 Kelvin). The "playback devices" are data acquisition units (DAQs), and the "audio information" is a quantum measurement pulse sequence. The "master" DAQ controls the precise timing of the pulses. Due to the extreme environment, component failure is more likely. The master transfer protocol is implemented over a low-temperature-rated optical fiber network. The transfer message contains the current state of the quantum experiment (pulse sequence ID, timing offsets, source waveform generator address). This ensures that if the master DAQ fails, a slave can take over and continue the experiment without needing to restart and re-cool the entire apparatus.

• Mermaid Diagram:

  flowchart LR
      subgraph ControlRoom [Control Room (300K)]
          A[Waveform Generator]
          B(Experiment Controller)
      end
      subgraph Cryostat [Cryostat (4K)]
          C(Master DAQ) -- Fiber --> D(Slave DAQ 1)
          C -- Fiber --> E(Slave DAQ 2)
          D -- Fiber --> E
          F(SQUID Array)
      end
      B -- Command --> C
      A -- Waveform --> C
      C -- Pulse Timing --> F
      D -- Measurement --> F
      E -- Measurement --> F
      C --"TransferMsg(exp_state, C_addr, A_addr)"--> E
  

---

3. Cross-Domain Application

3.1. Aerospace: Distributed Rover Mission Management

• Enabling Description: A fleet of planetary rovers forms a "synchrony group" to perform a coordinated terrain scan. The "master" rover dictates the scanning path and instrument timing (the "audio program"). The "audio source" is the mission control server on Earth, providing the high-level plan. If the master rover is about to enter a communications shadow or experiences a system fault, it transfers its master role to another rover with a better connection or health status. The transfer message contains the current mission state vector (path progress, next waypoint, active instruments) and the uplink/downlink address for mission control.

• Mermaid Diagram:

  sequenceDiagram
      participant MC as Mission Control
      participant MasterR as Master Rover
      participant SlaveR as Slave Rover
  
      MC->>MasterR: Send Mission Plan
      MasterR->>SlaveR: Sync Commands (Path Segment, Scan Time)
      loop Coordinated Scan
          MasterR->>MasterR: Execute Scan
          SlaveR->>SlaveR: Execute Scan
      end
      MasterR->>MasterR: Predicts entry into Comm Shadow
      MasterR->>SlaveR: TransferMsg(MissionState, MasterR_Addr, MC_Addr)
      SlaveR->>MC: Acknowledge New Master Role
      SlaveR->>SlaveR: Continue Mission Plan as Master
  

3.2. AgTech: Drone Swarm Crop Treatment

• Enabling Description: A swarm of agricultural drones executes a synchronized, variable-rate pesticide application. The "master" drone holds the master prescription map (the "playlist") and calculates real-time flight paths and spray commands for the slave drones based on its GPS location. The "audio source" is a cloud server holding the initial map. If the master drone's pesticide tank runs low, it initiates a master transfer to a fully-loaded slave drone. The transfer message includes the prescription map URI, the last completed map coordinate, and the master's own drone ID for logging purposes. The new master then directs the old master to return to base for refilling.

• Mermaid Diagram:

  graph TD
      A[Cloud Server - Rx Map] --> M(Master Drone);
      M -- "Sync Commands" --> S1(Slave Drone 1);
      M -- "Sync Commands" --> S2(Slave Drone 2);
      M -- "detects: pesticide < 5%" --> S1;
      subgraph Transfer Message
          direction LR
          a[Rx Map URI]
          b[Last Coord]
          c[Master ID]
      end
      M -- Transfer Message --> S1;
      S1 -- Becomes Master --> S2;
      S1 -- "RTB Command" --> M;
  

3.3. Industrial IoT: Coordinated Robotic Assembly Line

• Enabling Description: A group of robotic arms on a flexible assembly line work in a "synchrony group" to assemble a product. The "master" arm's controller dictates the timing for all other arms in the cell. The "audio source" is the Manufacturing Execution System (MES) server providing the assembly instructions. If a sensor on the master arm detects a potential motor failure (e.g., via vibration analysis), it preemptively transfers the master role to the next robot in the sequence. The transfer message contains the current assembly step number, the list of peer robot controller IP addresses, and the IP address of the MES. This allows the production line to continue with minimal interruption while the failing robot is flagged for maintenance.

• Mermaid Diagram:

  sequenceDiagram
      participant MES
      participant Robot1_Master
      participant Robot2_Slave
      participant Robot3_Slave
  
      MES->>Robot1_Master: Load Assembly Plan
      Robot1_Master->>Robot2_Slave: Command: Pick Part A
      Robot1_Master->>Robot3_Slave: Command: Hold Fixture
      Robot1_Master->>Robot1_Master: Action: Weld
      Robot1_Master->>Robot1_Master: AI detects motor vibration anomaly
      Robot1_Master->>Robot2_Slave: TransferMsg(AssemblyStep, {R1,R3}_IPs, MES_IP)
      Robot2_Slave->>MES: Announce: I am new Master
      Robot2_Slave->>Robot3_Slave: Command: Continue Sequence
  

---

4. Integration with Emerging Tech

4.1. AI-Optimized Predictive Master Handover

• Enabling Description: Each device in the synchrony group runs a lightweight, on-device machine learning model that monitors its own health (CPU load, memory usage, network latency, temperature) and the health of its peers. The current master device uses its model to predict its own Time-To-Failure (TTF) or Time-To-Degradation (TTD). Concurrently, it receives health telemetry from all slaves. If its predicted TTF falls below a system threshold, it initiates a transfer to the slave with the best current and predicted health score. The transfer message is standard, but the trigger is predictive rather than reactive, preventing any audible gap in playback.

• Mermaid Diagram:

  flowchart TD
      A[Master Device] --> B{Monitor Self & Peer Health};
      B --> C[Feed data to On-Device ML Model];
      C --> D{Predict Time-To-Failure (TTF)};
      D --> E{TTF < Threshold?};
      E -- No --> B;
      E -- Yes --> F[Select Healthiest Slave as New Master];
      F --> G[Send Master Transfer Message];
      G --> H[New Master Takes Over];
  

4.2. IoT-Triggered Context-Aware Group Management

• Enabling Description: The synchrony group is integrated with an external IoT sensor network (e.g., motion sensors, NFC readers, microphones). A user walking from the living room to the kitchen can trigger the master role transfer. For example, an NFC reader by the kitchen doorway, when tapped by the user's phone, sends a signal to the network. The current master (Living Room speaker) receives this signal and interprets it as a "relocate master" command. It then sends the transfer message to the Kitchen speaker, making it the new master. The "audio info" could be augmented to include context, like "User entered kitchen," allowing the new master to adjust equalization settings automatically.

• Mermaid Diagram:

  sequenceDiagram
      actor User
      participant Phone
      participant NFCR_Kitchen as NFC Reader
      participant ZP_LivingRoom as Master
      participant ZP_Kitchen as Slave
  
      User->>Phone: Walks towards kitchen
      Phone->>NFCR_Kitchen: NFC Tap
      NFCR_Kitchen->>ZP_LivingRoom: Event: User Location = Kitchen
      ZP_LivingRoom->>ZP_Kitchen: TransferMsg(AudioState, LR_Addr, Src_Addr)
      ZP_Kitchen-->>ZP_LivingRoom: Ack
      Note right of ZP_Kitchen: I am now Master
  

4.3. Blockchain-Verified Handover for Digital Rights Management (DRM)

• Enabling Description: For licensed, high-fidelity audio streams, the master role carries a specific DRM token. The synchrony group operates on a private, permissioned blockchain. The master device's identity and its active DRM token are recorded as a state on the chain. A master transfer is executed as a smart contract transaction. The current master calls a transferMaster function on the smart contract, specifying the new master's public key. The transaction atomically transfers the DRM token and updates the "current master" state variable. Slave devices listen for events emitted by the smart contract to identify the new master. The "audio source" address is the URI of the DRM-protected stream.

• Mermaid Diagram:

  classDiagram
  class SmartContract {
      +address currentMaster
      +mapping(address => bool) isMember
      +string currentStreamURI
      +string drmToken
      +transferMaster(address newMaster)
      +updateStream(string newURI)
  }
  class ZonePlayer {
      +address deviceID
      +listenForMasterChangeEvent()
      +playStream()
  }
  SmartContract "1" -- "N" ZonePlayer : interacts with
  

---

5. The "Inverse" or Failure Mode

5.1. Graceful Degradation Transfer Protocol

• Enabling Description: The master device, upon detecting a non-critical fault (e.g., high thermal load throttling its CPU), initiates a "degradation transfer." It sends an extended transfer message to the designated new master. This message includes the standard state information, but adds a "Playback-Constraint" flag (e.g., CONSTRAINT_LOW_BITRATE, CONSTRAINT_MONO). The new master assumes control and immediately sends a command to the audio source (if capable) or to all slaves to switch to the constrained mode. This ensures the synchrony group remains active, albeit at a lower quality, preventing a complete dropout during the handover. Once the original master recovers, it can request the master role back.

• Mermaid Diagram:

  graph TD
      M[Master] -- "Detects high temp" --> Trigger
      Trigger --> Pkg[Package TransferMsg + Constraint_Flag]
      Pkg --> S_New[Send to New Master]
      S_New -- "Receives Msg" --> Assume[Assume Master Role]
      Assume --> CmdSrc[Command Source: Switch to Low Bitrate]
      Assume --> CmdSlaves[Command Slaves: Expect Low Bitrate]
      CmdSlaves --> Play[Synchronized Low-Fi Playback Continues]
  

5.2. Silent Failover with Buffered Pre-Roll

• Enabling Description: This method is designed to handle an abrupt, unannounced failure of the master. All slave devices in the group actively maintain a slightly larger audio buffer (e.g., 5 seconds) than the master (e.g., 3 seconds). Slaves monitor a constant "heartbeat" packet from the master. If the heartbeat is missed for a specified duration (e.g., 3 missed packets), a deterministic election protocol (e.g., the slave with the lowest MAC address) is triggered. The elected slave immediately promotes itself to master and begins serving its buffered audio to the group, starting from the point where the old master was presumed to have failed. Because the slaves have a larger buffer, there is a high probability of a seamless, inaudible transition. The new master then re-establishes contact with the audio source. The "transfer message" is effectively replaced by the heartbeat failure and a deterministic election algorithm.
• Mermaid Diagram:

  sequenceDiagram
      participant Master
      participant Slave1 (New Master)
      participant Slave2
  
      loop Normal Operation
          Master->>Slave1: Heartbeat
          Master->>Slave2: Heartbeat
          Master->>all: Audio Packet N
      end
      Note over Master: **-- Abrupt Failure --**
      Slave1-->>Master: Heartbeat Timeout
      Slave2-->>Master: Heartbeat Timeout
      Note over Slave1, Slave2: Both initiate election protocol
      Slave1->>Slave1: My MAC is lowest. I am Master.
      Slave1->>Slave2: Announce New Master
      Slave2->>Slave1: Acknowledge
      Slave1->>all: Begin streaming from my buffer (Packet N+1)
  

---

Combination Prior Art Scenarios (Integration with Open Standards)

1. Bonjour/Zeroconf for Master Discovery and Transfer: The process of a slave becoming a master is combined with the IETF's Zeroconf standards. The current master advertises its service (e.g., _sonos-master._tcp) via mDNS (Bonjour). When a transfer is initiated, the master sends the transfer message and then sends a final mDNS packet de-registering its service. The new master, upon receiving the transfer message, immediately registers itself with the same service name but its own IP address. Slave devices use standard mDNS discovery to find the current master, making the transition seamless for any client device or other slave joining the group, as they simply resolve the _sonos-master._tcp service to find the new IP.

2. RTSP Control for Master Handover: The audio playback is managed using the Real-Time Streaming Protocol (RTSP). The master device acts as an RTSP server for the slaves, which are RTSP clients. The "audio information" in the transfer message is an RTSP session URL with a range= parameter indicating the current playback time (e.g., rtsp://server.example.com/audio.mp3/trackID=123?range=npt=30-). To transfer the master role, the current master sends a proprietary transfer message containing this RTSP URL to the chosen slave. The new slave then issues an RTSP PLAY command to the original audio source using the provided URL and time offset and begins acting as the new RTSP server for the other slaves.

3. NTP Synchronization with Master Role Election: The core synchronization mechanism of the '001 patent is augmented by the Network Time Protocol (NTP). All devices in the synchrony group are clients of a common external NTP server, ensuring they share a highly accurate wall-clock time. The audio stream itself contains presentation timestamps relative to this NTP time. The role of the master is primarily to distribute the playlist and handle user commands. If the master fails, a slave can take over because all devices already share a common, authoritative time reference. The transfer message in this case does not need to contain detailed timing information, but rather the high-level state (playlist URI, track index, and a "start playing at NTP timestamp T" command), simplifying the handover. The new master is chosen via a simple election protocol (e.g., lowest IP address) triggered by the loss of the master's keep-alive signal.