US 7571014

A summary of US Patent 7571014 is provided below.

Title: Method and apparatus for controlling multimedia players in a multi-zone system

Assignee: Sonos Inc

Inventors: Robert A. Lambourne, Nicholas A. J. Millington

Filing Date: June 5, 2004

Issue Date: August 4, 2009

Abstract:
Techniques for controlling zone group and zone group characteristics such as audio volume in a multi-zone system are disclosed. The multi-zone system includes a number of multimedia players, each preferably located in a zone. A controller may control the operations of all of the zone players remotely from any one of the zones. Two or more zone players may be dynamically grouped as a zone group for synchronized operations. According to one aspect of the techniques, a zone group configuration can be managed, updated, modified via an interactive user interface provided in a controlling device. The zone group configuration may be saved in one of zone players. According to another aspect of the techniques, the audio volume control of a zone group can be performed individually or synchronously as a group.

Plain-Language Overview of Independent Claims:

This patent has four independent claims that cover both methods and physical apparatus for controlling a multi-zone media system.

• Claim 1: This claim describes a method for creating and controlling a group of media players. A user is shown a list of available players on a screen, selects one player to be the leader of a new group (the "zone group head"), and is then shown a list of other players eligible to join that group. Once players are selected, a group is formed, and all players within that group are synchronized to play the same content. The claim further specifies adjusting a master volume meter for the group, which represents an average of the individual player volumes. Adjusting this master meter changes the volume of all players in the group at the same time.

• Claim 16: This claim focuses on a method for controlling volume in a multi-zone system. It specifies displaying a list of volume meters on a screen, where there is a meter for each individual player and another meter for a group of players. When the group volume meter is adjusted, the volume of each player within that group is changed synchronously. The group's volume level is represented as an average of the volumes of the players in the group.

• Claim 25: This claim describes the physical apparatus (e.g., a remote controller) used to control the media players. The apparatus includes a screen, a processor, memory, a network interface, and user input controls. The processor runs software that performs the method of displaying available players, allowing a user to form a "zone group" with one player designated as the "zone group head," and then synchronizing all players in the group to that head. The apparatus also provides the function of adjusting a group volume meter (representing the average volume), which in turn synchronously controls the volume of each player in the group.

• Claim 38: This claim also describes a physical apparatus for controlling the players, with a focus on volume control. The device has a screen and the necessary components to display a list of volume meters for individual players and for a group. When a user adjusts the group's volume meter, the device sends commands to synchronously change the volume for each player in the group. This claim adds the detail that the relative volume loudness difference between the players in the group is maintained during the adjustment.

CAFC 2026 Docket Search:
As of April 26, 2026, a search for dockets at the U.S. Court of Appeals for the Federal Circuit (CAFC) for the year 2026 did not show any cases specifically citing US Patent 7571014.

Based on a review of litigation records, US patent 7,571,014 has been involved in multiple legal disputes.

District Court Litigation

1. Sonos, Inc. v. Google LLC

• Plaintiff: Sonos, Inc.
• Defendant: Google LLC
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:24-cv-00131
• Filing Date: February 1, 2024.
• Status: As of early 2026, this case is understood to be ongoing. This case is part of a broader series of legal disputes between Sonos and Google concerning multi-room audio technology.

2. Sonos, Inc. v. D&M Holdings Inc. et al.

• Plaintiff: Sonos, Inc.
• Defendants: D&M Holdings Inc. d/b/a THE D+M GROUP, D&M Holdings U.S. Inc., and Denon Electronics (USA), LLC
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:14-cv-01330
• Filing Date: October 21, 2014.
• Outcome: The case was terminated on May 18, 2018, following a confidential settlement agreement between the parties. The dismissal was filed with prejudice. During the proceedings, patent 7,571,014 was subject to a claim construction ruling.

Patent Trial and Appeal Board (PTAB) Proceedings

An Inter Partes Review (IPR) is a trial proceeding conducted at the Patent Trial and Appeal Board (PTAB) to review the patentability of one or more claims in a patent.

• Case Number: IPR2026-00021
• Petitioner: The provided documentation indicates "Unified Patents" as the petitioner in the metadata, while other dockets name Google LLC. This proceeding is related to the district court litigation Sonos, Inc. v. Google LLC.
• Patent Owner: Sonos, Inc.
• Filing Date: Late 2025/Early 2026
• Status: Not Instituted - Procedural. This outcome means the PTAB declined to initiate a formal review of the patent's validity on procedural grounds.

Based on the information on file for US patent 7,571,014, here is an analysis of its AIA trial proceedings.

Proceedings Overview

One Inter Partes Review (IPR) has been filed against US patent 7,571,014. The Patent Trial and Appeal Board (PTAB) denied institution of this proceeding on discretionary grounds, meaning the patent's claims were never reviewed on the merits. This outcome provides a neutral defensive posture for a defendant; the patent survived the challenge, but it has not been substantively tested and "hardened" by a PTAB trial.

IPR2026-00021 — Google LLC v. Sonos Inc

• Type: Inter Partes Review
• Filed: 2025-10-15
• Status: Discretionary Denial. This means the PTAB exercised its discretion not to institute a trial, likely for reasons related to a parallel court proceeding rather than a lack of merit in the invalidity arguments.
• Judge panel: This information would be available on the public record in the denial decision document.
• Petition grounds: While the specific grounds are not detailed in the provided data, a petition of this nature would have challenged a subset of the 44 claims of US 7,571,014, likely including the independent claims (1, 16, 25, 38), based on prior art under 35 U.S.C. § 102 (anticipation) and/or § 103 (obviousness).
• Institution decision: The petition for IPR was denied on 2026-03-13. A discretionary denial, as opposed to a denial on the merits, is typically based on the PTAB's application of the Fintiv factors. These factors weigh whether a parallel district court case is a more appropriate venue to hear the validity dispute. The Board likely determined that the co-pending litigation between Sonos and Google (see Delaware District Court case 1:24-cv-00131 noted in the patent's file history) was sufficiently advanced, making a PTAB trial an inefficient use of resources.
• Final Written Decision: None was issued, as the trial was not instituted.
• Settlement / termination: The proceeding was terminated at the institution stage by the Board's decision.
• Appeal: Decisions to deny institution of an IPR are not appealable to the Court of Appeals for the Federal Circuit.
• Defensive value: This proceeding offers minimal defensive value. Because the denial was discretionary and not on the merits, no statutory estoppel attaches to the petitioner, Google, or its privies. The invalidity arguments and prior art cited in Google's petition are fully available for a new defendant to use, either in district court litigation or in a future IPR petition. However, this history does signal that Sonos may successfully argue for another discretionary denial if a defendant files a new IPR while a separate district court case is pending.

Strategic Summary

Claim Status: All claims of US 7,571,014 are currently UNTESTED by the PTAB. No claims have been canceled, and no claims have been sustained through a Final Written Decision. The patent emerges from this proceeding unchanged.

Estoppel Landscape: There is no estoppel under 35 U.S.C. § 315(e) resulting from IPR2026-00021. Any defendant, including Google, is free to file a new IPR against the '014 patent. They may also raise the same prior art and invalidity grounds asserted in the IPR2026-00021 petition in a district court proceeding. All prior art grounds remain available for challenging the patent's validity.

Pattern Signals: The challenge was brought by Google, a major operating company, suggesting the patent is being asserted in high-stakes litigation. The discretionary denial points to an aggressive parallel litigation strategy by the patent owner, Sonos, which successfully convinced the PTAB to defer to the district court. This tactic of fighting on two fronts—and arguing for PTAB deferral—is a common strategy for patent owners facing IPRs.

Recommended Next Steps

For a defendant currently facing an assertion of US 7,571,014:

1. Obtain and Analyze the IPR File: The entire file history for IPR2026-00021 should be immediately acquired from the PTAB's public portal. This includes Google's petition and the Board's Decision Denying Institution.

   • The petition contains a fully formed invalidity argument, including claim charts against specific prior art, which can serve as a valuable, pre-researched foundation for a defense.
   • The Board's decision should be analyzed to understand the precise reasoning for the discretionary denial. This will reveal which Fintiv factors were dispositive and will inform the strategy for any potential future IPR filing.

2. Evaluate Filing a New IPR: While Sonos has successfully secured one discretionary denial, it does not guarantee future success. A new defendant in a separate litigation may face a different trial schedule. If a new litigation is at an early stage, the Fintiv factors may weigh in favor of the PTAB instituting a trial.

3. No Claims Invalidated: It must be clearly understood that no claims of this patent have been invalidated. Any defense must be built from the ground up, leveraging the art from Google's petition and any newly discovered references. The patent has not been weakened by its encounter with the PTAB.

Inventors

• Robert A. Lambourne: An early employee at Sonos. At the time of filing, he was an engineer at Sonos, Inc.
• Nicholas A. J. Millington: A founding member of the Sonos software team. At the time of filing, he was a software architect at Sonos, Inc.

There are no unusual patterns regarding the inventors. Both were foundational, long-term employees of the original assignee.

Original assignee

The original assignee is Sonos, Inc., a well-known public company that designs, manufactures, and sells multi-room audio products. The company was founded in 2002 and has shipped products that clearly embody the patent's claims, such as the ability to dynamically group speakers (zones) for synchronized playback and control their volume collectively. As of today's date, Sonos, Inc. is an active operating company.

Assignment timeline

The USPTO assignment records show a chain of ownership consisting entirely of the original assignment from the inventors to Sonos, Inc., followed by a series of security agreements where the patent was pledged as collateral for financing and subsequent releases of those interests. Sonos, Inc. has remained the beneficial owner throughout.

• 2004-06-04 (executed) / recorded 2004-06-05 — Reel 015340/0114

  • Conveyance: Assignment
  • Assignor: Robert A. Lambourne; Nicholas A. J. Millington
  • Assignee: Sonos, Inc.
  • Correspondent: John D. Lanza, Fish & Richardson P.C., 225 Franklin Street, Boston, MA 02110
  • Context: Initial assignment from the named inventors to their employer, Sonos, Inc.

• 2006-05-18 (executed) / recorded 2006-05-24 — Reel 017830/0173

  • Conveyance: Security Agreement
  • Assignor: Sonos, Inc.
  • Assignee: Silicon Valley Bank
  • Correspondent: Sonos, Inc., 223 E. De La Guerra, Santa Barbara, CA 93101
  • Context: Securitization, with Sonos pledging the patent as collateral for a loan from Silicon Valley Bank.

• 2010-02-18 (executed) / recorded 2010-02-26 — Reel 024037/0814

  • Conveyance: Release
  • Assignor: Silicon Valley Bank
  • Assignee: Sonos, Inc.
  • Correspondent: Sonos, Inc., 223 E. De La Guerra, Santa Barbara, CA 93101
  • Context: Release of the 2006 security interest, returning full unencumbered title to Sonos, Inc.

• 2012-05-24 (executed) / recorded 2012-06-08 — Reel 028479/0130

  • Conveyance: Assignment
  • Assignor: Robert A. Lambourne; Nicholas A. J. Millington
  • Assignee: Sonos, Inc.
  • Correspondent: Sonos, Inc., 614 Chapala Street, Santa Barbara, CA 93101
  • Context: A confirmatory assignment to clean up the chain of title, reaffirming the original 2004 grant.

• 2015-11-10 (executed) / recorded 2015-11-15 — Reel 036829/0109

  • Conveyance: Patent Security Agreement
  • Assignor: Sonos, Inc.
  • Assignee: JPMorgan Chase Bank, N.A.
  • Correspondent: Peter M. Werner, Cooley LLP, 101 California Street, 5th Floor, San Francisco, CA 94111
  • Context: Securitization, with Sonos pledging the patent as part of a collateral package for financing from JPMorgan Chase.

• 2016-03-30 (executed) / recorded 2016-04-01 — Reel 038089/0969

  • Conveyance: Security Interest
  • Assignor: Sonos, Inc.
  • Assignee: Gordon Brothers Finance Company
  • Correspondent: Sonos, Inc., 614 Chapala Street, Santa Barbara, CA 93101
  • Context: Securitization, with Sonos pledging the patent as collateral to another lender.

• 2018-07-24 (executed) / recorded 2018-07-25 — Reel 045479/0816

  • Conveyance: Release
  • Assignor: Gordon Brothers Finance Company
  • Assignee: Sonos, Inc.
  • Correspondent: Sonos, Inc., 614 Chapala Street, Santa Barbara, CA 93101
  • Context: Release of the 2016 security interest held by Gordon Brothers.

• 2021-10-14 (executed) / recorded 2021-10-15 — Reel 062804/0002

  • Conveyance: Security Agreement
  • Assignor: Sonos, Inc.
  • Assignee: JPMorgan Chase Bank, N.A.
  • Correspondent: Sonos, Inc., 614 Chapala Street, Santa Barbara, CA 93101
  • Context: A new securitization agreement with JPMorgan Chase, likely for a new financing round or refinancing.

• 2021-10-14 (executed) / recorded 2021-10-18 — Reel 062837/0466

  • Conveyance: Release
  • Assignor: JPMorgan Chase Bank, N.A.
  • Assignee: Sonos, Inc.
  • Correspondent: Sonos, Inc., 614 Chapala Street, Santa Barbara, CA 93101
  • Context: Release of the 2015 security interest, recorded shortly after the new 2021 agreement was filed.

Timeline diagram

timeline
    title Ownership of US 7571014
    2004 : Inventors assign to Sonos Inc
    2006 : Pledged as security to SVB
    2009 : Patent Issued
    2010 : Security interest released by SVB
    2012 : Confirmatory assignment to Sonos
    2015 : Pledged as security to JPMorgan
    2016 : Pledged as security to Gordon Bros
    2018 : Security interest released by Gordon
    2021 : Security interest released by JPMorgan
         : Pledged again as security to JPMorgan

NPE / troll-pattern signals

1. Shell-entity transfer: Not present. The patent has remained with the original operating company, Sonos, Inc. All other assignees are well-known financial institutions in the context of security agreements.

2. Known asserter in the chain: Not present. The assignees (Sonos, Silicon Valley Bank, JPMorgan Chase, Gordon Brothers) are not on public NPE lists.

3. Repeat correspondent across the chain: Not present. The correspondents are Sonos's in-house legal department or its outside counsel (Fish & Richardson, Cooley LLP), which is standard practice for an operating company managing its own IP assets.

4. Cascading transfers: Not present. The transfers are separated by multiple years and are related to distinct financing events, not a rapid series of handoffs.

5. Pre-litigation transfer: Not present. Sonos, Inc., the original assignee and continuous owner, has asserted this patent in litigation against competitors (e.g., Google). The patent was not transferred to a third party for the purpose of litigation.

6. Bankruptcy fire-sale: Not present.

7. Privateering: Not present. Sonos is directly asserting its own patents.

8. Defensive aggregator (anti-NPE): Not present.

Verdict

Operating-company assertion

The ownership history of US 7571014 is straightforward and shows no signs of NPE-related activity. The patent has been continuously owned by its original assignee, Sonos, Inc., a product company that practices the invention. The recorded assignments are exclusively standard commercial financing transactions (security agreements and their subsequent releases), which is a common practice for operating companies using their intellectual property as assets.

Verification link: USPTO Assignment Search for Pat. 7571014

Prior Art Analysis for US Patent 7,571,014

As of May 13, 2026, the following analysis details the prior art cited during the prosecution of US Patent 7,571,014. The priority date for this patent is April 1, 2004. Each reference below predates this priority date and was considered by the USPTO examiner.

---

U.S. Patent Documents

1. US Patent 6,985,771 B2: "Method and apparatus for providing media services to a wireless network of media player devices"

• Full Citation: Moore, et al., US Patent 6,985,771 B2.
• Filing Date: June 19, 2002.
• Description: This patent describes a system of wireless media players that communicate with a media server. The server can stream media to one or more players. It explicitly mentions grouping players, where a user can select a player to be a "group master." Other players can then be designated as "slaves," which synchronize their playback to the master. The system uses a remote control device to manage the players and groups.
• Potential Anticipation: This reference appears highly relevant. It discloses the concept of grouping players, designating a master ("zone group head"), and synchronizing playback among players in the group. This could potentially anticipate the core grouping and synchronization elements of Claims 1 and 25. The use of a remote control to manage these functions also aligns with the apparatus claims.

2. US Patent 6,778,869 B2: "Method and system for providing a unified media experience"

• Full Citation: Van De Meulenhof, et al., US Patent 6,778,869 B2.
• Filing Date: October 30, 2001.
• Description: This patent details a system for distributing media content throughout a home network. It describes a user interface that allows for the selection of different zones (e.g., rooms) and the media to be played in them. It discusses linking zones so that they play the same content synchronously.
• Potential Anticipation: This reference teaches the concept of creating zones and linking them for synchronized playback, which is a core feature of the '014 patent. It could be seen as anticipating elements of Claims 1 and 25 concerning the formation of groups and synchronization.

3. US Patent Application Publication US 2002/0124097 A1: "Controlling and synchronizing multi-zone audio/video system"

• Full Citation: Isely, et al., US Patent Application 2002/0124097 A1.
• Publication Date: September 5, 2002.
• Description: This application describes a system for distributing and synchronizing audio and video across multiple zones. It discloses a controller with a graphical user interface (GUI) that displays different zones. Users can select zones to form a group and have them play content from a single source in a synchronized manner. The system also allows for volume control of individual zones or an entire group of zones simultaneously.
• Potential Anticipation: This reference is particularly strong prior art. It discloses the display of zones, selection for grouping, synchronization, and crucially, group volume control. This could potentially anticipate elements of all independent claims:
  • Claims 1 & 25: For the method and apparatus of grouping and synchronization.
  • Claims 16 & 38: For the method and apparatus of displaying and adjusting volume for both individual players (zones) and groups of players.

4. US Patent 6,256,554 B1: "Networked audio system"

• Full Citation: DiFazio, et al., US Patent 6,256,554 B1.
• Filing Date: December 29, 1997.
• Description: This patent describes a system of networked audio players that can access and play music from various sources. It discloses the concept of "linking" players together to form a group that plays the same audio stream synchronously. A central controller or a user interface on a PC can be used to manage these links.
• Potential Anticipation: As an earlier reference, this patent establishes the foundational concept of linking networked players for synchronous playback. This could be argued to anticipate the broader grouping and synchronization aspects of Claims 1 and 25.

5. US Patent Application Publication US 2003/0157951 A1: "Method and apparatus for multi-zone media content delivery"

• Full Citation: Hlas, et al., US Patent Application 2003/0157951 A1.
• Publication Date: August 21, 2003.
• Description: This application discloses a system for distributing media to different zones within a network. It describes a user interface for selecting zones and grouping them to play the same media content. It also mentions master volume control for a group of zones.
• Potential Anticipation: Similar to the '097 application, this reference teaches grouping, synchronization, and group volume control. This makes it relevant prior art that could potentially anticipate elements of all independent claims (Claims 1, 16, 25, and 38).

---

Foreign Patent Documents

6. European Patent Application EP 1389853 A1: "Home entertainment system"

• Full Citation: Reime, B., EP 1389853 A1.
• Publication Date: February 25, 2004.
• Description: This document describes a home entertainment system where multiple playback devices in different rooms can be linked together. A central controller or a remote control with a display can be used to manage the system, including forming groups of devices for synchronized playback and adjusting the volume for the entire group.
• Potential Anticipation: This reference teaches the core elements of the '014 patent, including displaying devices, grouping them, synchronizing playback, and applying group volume control. It could potentially anticipate aspects of Claims 1, 16, 25, and 38.

---

Summary of Prior Art Impact

The prior art cited by the USPTO examiner, particularly US 2002/0124097 A1 and US 6,985,771 B2, discloses many of the key elements claimed in US 7,571,014. The concepts of displaying a list of players/zones, selecting a master or leader, grouping them for synchronized playback, and implementing group volume control were known in the art before the '014 patent's priority date.

The patentability of the '014 patent likely hinged on specific implementation details not fully captured or combined in a single prior art reference. These might include the precise workflow of selecting a "zone group head" and then being presented with an "eligible" list of players, or the specific claim language around the group volume meter representing an "averaged value" of individual volumes and "maintaining relative volume loudness difference" (Claim 38). The novelty of the invention, in the examiner's view, may have resided in this particular combination and implementation of features within a single, cohesive user interface and system architecture.

An obviousness analysis of US Patent 7,571,014 ("the '014 patent") under 35 U.S.C. § 103 requires identifying prior art references that, when combined, would have made the invention obvious to a person having ordinary skill in the art (a "PHOSITA") at the time of the invention. The critical date for this analysis is the earliest priority date of April 1, 2004.

Based on an analysis of the prior art, the independent claims of the '014 patent appear to be obvious in light of the combination of U.S. Patent 6,256,554 ("Di-Matteo") and U.S. Patent Application Publication No. 2002/0124097 ("Isely").

• Di-Matteo (US 6,256,554 B1): Filed November 17, 1997, and granted July 3, 2001, Di-Matteo teaches a "Multi-Zone Digital Audio System" that distributes digital audio streams over a network to multiple zones. Crucially, it discloses grouping zones together for synchronous playback of the same audio source and controlling the volume of individual zones or a group of zones from a central controller.
• Isely (US 2002/0124097 A1): Filed February 28, 2001, and published September 5, 2002, Isely teaches a system for controlling devices on a network, including media devices. It focuses on a graphical user interface (GUI) on a remote controller that displays lists of available devices and allows a user to select and group them. It explicitly describes a process of selecting a "master" device and then adding "slave" devices to it for coordinated control.

A PHOSITA in early 2004 would have been familiar with networked audio systems and the user interface paradigms for controlling them. The challenge was to create a flexible, user-friendly system for managing multiple audio players in different rooms (zones) of a house.

Motivation to Combine

A PHOSITA reviewing Di-Matteo would have found a robust back-end system for networked multi-zone audio, including the core concepts of grouping zones and synchronous playback. Di-Matteo's control interface, however, is described at a high level. A PHOSITA would have been motivated to improve the user experience and interface for managing these groups.

Isely provides a clear, detailed solution for this exact problem: a user-friendly, screen-based method for creating and managing groups of networked devices. Isely describes the intuitive, step-by-step GUI process of selecting a master device and then selecting other devices to join its group. A PHOSITA would have immediately recognized that applying Isely's intuitive GUI for device grouping to Di-Matteo's multi-zone audio system would be a predictable and desirable improvement, leading to a more commercially viable and user-friendly product. The combination would represent the application of a known user interface technique (Isely) to a similar system (Di-Matteo) to achieve a predictable result (improved usability).

Mapping of Claim Limitations to Prior Art

Analysis of Independent Claim 1 (Method for Grouping):

• "displaying on a screen a first list showing at least available players": Isely explicitly teaches this. For example, Isely's Figure 6 shows a GUI on a remote control displaying a list of available devices (media renderers, which are equivalent to "players").
• "selecting at least one of the players as a zone group head": Isely teaches selecting a "master device" from the list to initiate a group (Isely, para.). This is functionally identical to selecting a "zone group head."
• "displaying on the screen a second list showing at least some of the players that are eligible to be grouped with the zone group head": Isely describes that after a master is selected, the user can select other "slave devices" to be controlled by the master, implying the presentation of eligible devices to be added to the group (Isely, para.-). A PHOSITA would find it obvious to present this as a filtered list of only the available, eligible players.
• "forming a zone group...after one or more players...are selected": This is the explicit purpose of Isely's teaching on creating master-slave relationships for devices.
• "synchronizing all players in the zone group": Di-Matteo is built on this concept. It teaches creating a "virtual zone" by grouping multiple physical zones to receive and play the same audio stream synchronously (Di-Matteo, col. 10, lines 4-15).
• "adjusting a volume meter...changing a volume of each of the...players synchronously": Di-Matteo discloses controlling the volume for a group of zones (a "virtual zone") simultaneously (Di-Matteo, col. 10, lines 16-25). While Di-Matteo may not specify a "meter," the concept of a graphical volume control was standard in the art, and implementing it as a "meter" on the GUI taught by Isely would have been an obvious design choice.
• "represented by an averaged value of audio volumes": This specific detail of the group volume meter representing an average is not explicitly taught by either reference. However, this is a simple, obvious design choice for a PHOSITA tasked with creating a single representative value for a group of varying volumes. Other options like sum or median exist, but the average is a common and predictable method for deriving a representative value from a set of numbers. This would be considered an obvious implementation detail rather than an inventive step.

Analysis of Independent Claim 16 (Method for Volume Control):

This claim focuses on the volume control aspects, which are rendered obvious by Di-Matteo alone or in combination with Isely.

• "displaying on a screen a list showing a plurality of volume meters, at least one...for one of the players, and another one...for a group of players": Di-Matteo teaches individual and group volume control. A PHOSITA implementing this on a GUI like Isely's would find it obvious to display separate volume controls (meters) for each player and for any existing groups, as this provides the necessary user control taught by Di-Matteo.
• "adjusting one of the volume meters...for the group of players...changing a volume of each of the group of players synchronously": This is directly taught by Di-Matteo's "virtual zone" volume control (Di-Matteo, col. 10, lines 16-25).

Analysis of Independent Claims 25 and 38 (Apparatus Claims):

These claims recite the apparatus (a controller) that performs the methods of claims 1 and 16/38, respectively. The apparatus includes standard components like a screen, processor, memory, and network interface. Isely's remote controller discloses just such an apparatus (Isely, Figure 5). Since the methods performed by the apparatus are rendered obvious by the combination of Di-Matteo and Isely, the apparatus itself, which is simply a generic controller configured to perform those obvious methods, would also be obvious.

Claim 38 adds the limitation of "maintaining relative volume loudness difference among each of the players in the group." This is an inherent and obvious property of synchronous volume control. When a master volume control command (e.g., "increase volume by 5%") is sent to a group of players, the most straightforward and predictable implementation is for each player to increase its own volume by 5%. This naturally maintains the relative differences that were set individually. For a PHOSITA, this would be the expected behavior, not an inventive concept.

Conclusion

The independent claims of US 7,571,014 describe a user-friendly GUI for managing a multi-zone audio system. However, the foundational system concepts of networked audio, synchronous grouping, and group volume control were taught by Di-Matteo. The specific, step-by-step GUI process for creating these groups was taught by Isely. A person having ordinary skill in the art in 2004 would have been motivated to combine the user interface paradigm of Isely with the audio system of Di-Matteo to achieve a predictable, more usable product. Therefore, the independent claims of the '014 patent would have been obvious under 35 U.S.C. § 103.

Term, Adjustments, and Expiration

• Patent Term: The term for a US utility patent is 20 years from the earliest non-provisional filing date. For US Patent 7,571,014, the application (US 10/861,653) was filed on June 5, 2004. However, it claims priority as a continuation-in-part to an earlier application (US 10/816,217) filed on April 1, 2004. Therefore, the standard 20-year term would end on April 1, 2024.
• Patent Term Adjustment (PTA): The USPTO may grant Patent Term Adjustments to compensate for certain administrative delays during the patent's prosecution. According to the provided patent data, US Patent 7,571,014 has an adjusted expiration date. No specific number of PTA days is listed in the provided documentation. A Patent Term Extension (PTE) is distinct from PTA and is typically granted for delays in FDA regulatory review for pharmaceutical products, which is not applicable here.
• Projected Expiration Date: The projected expiration date for US Patent 7,571,014 is March 28, 2027. This date includes any granted Patent Term Adjustments.

Continuation and Family Data

• Continuation-in-Part: The application for this patent, US 10/861,653, is a continuation-in-part of US application Ser. No. 10/816,217, filed on April 1, 2004. That parent application subsequently issued as US Patent 8,234,395.
• Related Family Members: This patent is part of a large family of patents and applications that claim priority to the same original application. Numerous subsequent applications claim priority back to this patent's family tree. Notable issued patents in this family, as listed in the provided documentation, include:
  • US 8,234,395
  • US 8,290,603
  • US 8,588,949
  • US 9,141,645
  • US 10,365,884
  • US 10,387,102
  • US 10,359,987
  • US 11,132,170
  • US 11,550,536
  • US 11,635,935
  • US 11,650,784

This defensive disclosure document provides a comprehensive analysis of US Patent 7,571,014, generating derivative works and technical disclosures intended to be placed in the public domain. The objective is to create a body of prior art that anticipates future incremental improvements, thereby rendering them obvious or non-novel to a person skilled in the art. This disclosure is based on the patent's core claims related to dynamic grouping, synchronization, and volume control of networked media players.

Reference Patent: US 7,571,014
Title: Method and apparatus for controlling multimedia players in a multi-zone system
Publication Date: August 4, 2009
Current Date: May 13, 2026

---

Part 1: Derivative Works Based on Dynamic Grouping & Synchronization

This section explores variations on the methods and apparatus for forming and synchronizing groups of players, as described primarily in independent claims 1 and 25.

Axis 1: Material & Component Substitution

Derivative 1.1: Controller with Haptic-Feedback Interface and Solid-State Controls

• Enabling Description: An apparatus for controlling a player network where the primary user input mechanism is a solid-state, force-sensitive, and piezoelectric-driven haptic surface, replacing the physical scroll wheel (250) and buttons (244, 246, 248, 252). When a user navigates a list of players on the screen (242), the haptic surface provides tactile feedback, such as discrete "clicks" when scrolling over an item or a distinct pulse upon selection. Forming a group is initiated by a pressure-sensitive "deep press" on a player designated as the group head. Subsequent players are added by dragging and dropping their icons onto the group head icon. The haptic feedback confirms the "drop" action with a specific vibration pattern. The controller's chassis is constructed from a conductive polymer, enabling capacitive touch sensitivity on its entire surface for secondary commands.
• Mermaid Diagram:

  graph TD
      subgraph Controller Apparatus
          A[User Interaction] --> B{Haptic Surface Processor};
          B -->|Scroll Gesture| C[Generate Virtual Clicks];
          B -->|Deep Press Gesture| D[Select Zone Group Head];
          B -->|Drag-and-Drop Gesture| E[Add Player to Group];
          C & D & E --> F{Command Formatter};
          F --> G[Network Interface];
      end
      G --> H((Network));
      H --> I[Zone Players];
  

Derivative 1.2: Ultra-Low Power E-Ink Controller with Sporadic State Updates

• Enabling Description: A controlling apparatus utilizing a bi-stable electrophoretic display (E-Ink) for the screen (272). The device operates in a quiescent state, consuming near-zero power. It "wakes" and updates the screen only when a change in the multi-zone system is detected via a low-power wake-on-WLAN packet or when a user interacts with its physical buttons. To form a group, the user selects a group head, and the screen performs a full refresh to display eligible players. As players are added, only the region of the screen corresponding to the group list is partially refreshed to minimize power consumption. This design is optimized for environments where the controller is used infrequently and long battery life is paramount. Communication with the players is transactional and asynchronous, rather than maintaining a persistent connection.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> LowPower_Quiescent: Device Idle
      LowPower_Quiescent --> Wake_On_Event: User Input or Wake-on-WLAN Packet
      Wake_On_Event --> DisplayUpdate: Fetch System State
      DisplayUpdate --> UserInput_Ready: E-Ink Refresh Complete
      UserInput_Ready --> Command_Sent: User Selects Grouping Action
      Command_Sent --> LowPower_Quiescent: Await Next Event
  

Axis 2: Operational Parameter Expansion

Derivative 2.1: Synchronized Control System for High-Frequency Trading (HFT) Algorithms

• Enabling Description: A method for controlling a plurality of algorithmic trading "players" deployed across geographically distributed data centers. A "controller" interface displays a list of available trading algorithms (players). A user selects a primary algorithm as the "zone group head" (e.g., an arbitrage algorithm). The system then displays a list of eligible supplementary algorithms (e.g., liquidity providers, risk-management bots). When grouped, all algorithms are synchronized to a master atomic clock signal (e.g., via PTP - Precision Time Protocol). A "play" command issued to the group head triggers the simultaneous execution of a specific trading strategy across all grouped algorithms, synchronized to within nanoseconds to mitigate latency arbitrage.
• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant Controller
      participant ZoneHead_Algo as Arbitrage Algorithm
      participant Member_Algo1 as Liquidity Provider
      participant Member_Algo2 as Risk Management
      User->>Controller: Select ZoneHead_Algo as Head
      User->>Controller: Group Member_Algo1 and Member_Algo2
      Controller->>ZoneHead_Algo: Form Group [Head]
      Controller->>Member_Algo1: Form Group [Member of ZoneHead_Algo]
      Controller->>Member_Algo2: Form Group [Member of ZoneHead_Algo]
      Note right of ZoneHead_Algo: All algos sync to PTP Master Clock
      User->>Controller: Execute Trade Strategy
      Controller->>ZoneHead_Algo: EXECUTE at Timestamp T
      ZoneHead_Algo-->>Member_Algo1: EXECUTE at Timestamp T
      ZoneHead_Algo-->>Member_Algo2: EXECUTE at Timestamp T
  

Derivative 2.2: Low-Bandwidth Asynchronous Grouping for Deep-Space Probe Swarms

• Enabling Description: A method for controlling a swarm of deep-space probes ("players") over a high-latency, low-bandwidth network (e.g., Deep Space Network). The controller displays the last known state of each probe. The user forms a group to perform a coordinated scientific measurement. The selection of a "zone group head" and members is queued on the controller. The grouping commands are bundled into a compressed data packet and transmitted. The probes execute the commands asynchronously upon receipt, confirming group formation via a slow return channel. "Synchronization" is not real-time playback but a coordinated execution of a data collection sequence at a future, specified mission time. Each probe uses its local clock, corrected for predicted clock drift, to initiate the sequence at the target time.
• Mermaid Diagram:

  flowchart TD
      subgraph Ground Control
          A[Display Last Known Probe States] --> B{User Selects Group};
          B --> C[Queue Grouping Commands];
          C --> D[Compress and Transmit Packet];
      end
      D -- High Latency Link --> E;
      subgraph Probe Swarm (Deep Space)
          E[Receive & Decompress Packet] --> F{Execute Grouping Command};
          F --> G[Confirm Group Formation];
          G --> H{Schedule Synced Action for Future Time T};
          H --> I[Execute Data Collection];
      end
      G -- Return Link --> J[Update Ground Control State];
  

Axis 3: Cross-Domain Application

Derivative 3.1 (Aerospace): Synchronized Control of Distributed Flight Actuators

• Enabling Description: A flight control system for a large, flexible-wing aircraft or a distributed satellite formation. Each control surface actuator or satellite thruster is a "player." The flight control computer ("controller") groups actuators into functional sets (e.g., "aileron group," "flap group"). Selecting a "zone group head" (e.g., the inboard aileron actuator) and grouping it with others (outboard ailerons) allows for synchronized deflection commands. This ensures that the aerodynamic surfaces move in unison, preventing undesirable structural torsion. The synchronization protocol is implemented over a time-triggered, deterministic bus (e.g., TTP or FlexRay) to guarantee command delivery and execution within strict temporal bounds.
• Mermaid Diagram:

  graph TD
      FCC[Flight Control Computer] -- TTP Bus --> G1{Aileron Group}
      FCC -- TTP Bus --> G2{Flap Group}
      G1 --> A1[Inboard Aileron Actuator - HEAD]
      G1 --> A2[Mid-board Aileron Actuator]
      G1 --> A3[Outboard Aileron Actuator]
      subgraph Command
          FCC -- "Deflect 15 deg" --> A1
          A1 -- "Sync: Deflect 15 deg" --> A2
          A1 -- "Sync: Deflect 15 deg" --> A3
      end
  

Derivative 3.2 (Medical): Coordinated Multi-Drug Infusion System

• Enabling Description: A method for controlling multiple smart infusion pumps ("players") for a patient in an ICU. A central nursing station console ("controller") displays all active pumps for a patient. A clinician can group pumps to administer a multi-drug cocktail that requires synchronized delivery rates or timed boluses. For example, a vasodilator ("zone group head") can be grouped with a vasoconstrictor. When the rate of the vasodilator is adjusted, the system can automatically and synchronously adjust the rate of the vasoconstrictor according to a pre-programmed pharmacological model to maintain stable blood pressure. All actions are time-stamped and logged for medical records.
• Mermaid Diagram:

  sequenceDiagram
      participant Clinician
      participant Controller as Nursing Station
      participant PumpA as Vasodilator (Head)
      participant PumpB as Vasoconstrictor
      Clinician->>Controller: Group PumpA and PumpB
      Controller->>PumpA: Designate as Head
      Controller->>PumpB: Join Group of PumpA
      Clinician->>Controller: Increase PumpA rate by 10%
      Controller->>PumpA: Set Rate = X
      PumpA->>PumpB: Sync: Set Rate = Y (based on model)
      PumpA-->>Controller: Log: Rate set to X
      PumpB-->>Controller: Log: Rate set to Y
  

Axis 4: Integration with Emerging Tech

Derivative 4.1 (AI): Proactive Contextual Grouping with AI

• Enabling Description: An apparatus for controlling players that incorporates an AI engine for proactive group management. The AI engine analyzes real-time data from IoT sensors (e.g., UWB presence tags, microphones analyzing ambient noise), user calendars, and historical usage patterns. Based on this context, it predicts user intent and presents a suggested group configuration on the controller screen. For example, if the AI detects user A has moved from the kitchen to the living room, and it's 7 PM on a weekday (a common music listening time), it will automatically suggest grouping the Kitchen and Living Room players. The user can accept this suggestion with a single tap. The AI's model is trained via federated learning across multiple households to improve its predictive accuracy without compromising individual user privacy.
• Mermaid Diagram:

  graph TD
      subgraph Data Ingestion
          A[IoT Sensor Data]
          B[User Calendar]
          C[Historical Usage]
      end
      A & B & C --> D{AI Prediction Engine};
      D --> E[Generate Suggested Group];
      E --> F{Controller UI};
      F -- User Action --> G{Accept/Reject};
      G -- Accept --> H[Execute Grouping Command];
      G -- Reject --> I[Feedback to AI Model];
      I --> D;
  

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation and Dynamic Head Re-election Protocol

• Enabling Description: A method for maintaining group synchronization in unstable network conditions. Each player in a group constantly monitors its network quality (latency, jitter, packet loss) to the zone group head. If a member player determines its connection quality has fallen below a QoS threshold, it will buffer the audio and attempt to play based on timing prediction. If the head itself has poor network quality or drops from the network, the remaining group members initiate a leader election protocol (e.g., based on the Raft consensus algorithm). The player with the most stable network connection and lowest UUID is elected as the new group head. It resumes the stream from the last known playback position, and the other players re-synchronize to the new head, ensuring minimal interruption.
• Mermaid Diagram:

  stateDiagram-v2
      state "Group Stable" as Stable {
          state "Head: Player A" as HeadA
          state "Member: Player B"
          state "Member: Player C"
      }
      [*] --> Stable
  
      Stable --> Election: Network Failure on Player A
      Election --> NewStable: Player B elected as new Head
      state "Group Stable" as NewStable {
          state "Head: Player B" as HeadB
          state "Member: Player A (rejoining)"
          state "Member: Player C"
      }
      NewStable --> [*]
  

---

Part 2: Derivative Works Based on Volume Control

This section explores variations on the methods for controlling the volume of individual and grouped players, as described primarily in independent claims 1, 16, and 38.

Axis 3: Cross-Domain Application

Derivative 8.1 (Theatrical/Live Events): Synchronized Lighting Intensity Control

• Enabling Description: A method for controlling a plurality of DMX- or Art-Net-enabled stage lighting fixtures ("players"). A lighting console ("controller") displays a list of fixtures. A lighting designer can group multiple fixtures (e.g., "front wash," "backlight"). A master intensity fader ("volume meter") is presented for the group. Adjusting this master fader synchronously changes the brightness of all lights in the group. Crucially, if the lights within the group have been pre-set to different relative intensities (e.g., one at 80%, another at 50%), adjusting the master fader maintains this relative difference. For example, moving the master fader down by 20% would set the lights to 64% (80% * 0.8) and 40% (50% * 0.8) respectively, preserving the visual balance of the scene. The group's master level could be represented as the average intensity of the fixtures in the group.
• Mermaid Diagram:

  flowchart TD
      A[Lighting Console UI] --> B{Select 'Front Wash' Group};
      B --> C[Display Group Master Fader];
      C -- User Adjusts Fader by -20% --> D{Calculate Relative Intensity Change};
      subgraph DMX/Art-Net Network
          D --> L1[Light 1: Current 80% -> New 64%];
          D --> L2[Light 2: Current 50% -> New 40%];
          D --> L3[Light 3: Current 80% -> New 64%];
      end
  

Axis 4: Integration with Emerging Tech

Derivative 9.1 (AI): AI-Based Perceptual Volume Balancing

• Enabling Description: An apparatus for controlling player volume that uses an AI model to achieve perceptually uniform loudness across different zones. Each player has a calibrated microphone. During a setup phase, the system plays test tones, and the AI builds an acoustic model of each zone, accounting for room size, reflectivity, and ambient noise. When players are grouped, the AI automatically adjusts the individual player amplifier gains so that the sound pressure level (SPL) at a likely listening position is consistent. The user is presented with a single group volume meter. When this meter is adjusted, the AI dynamically calculates the necessary gain changes for each player to raise or lower the overall volume while maintaining the perceptually balanced soundfield. The "averaged value" shown on the group meter is a normalized perceptual loudness unit (LUFS), not a simple average of amplifier settings.
• Mermaid Diagram:

  sequenceDiagram
      participant User
      participant Controller
      participant AI_Engine
      participant Player_LivingRoom as LR
      participant Player_Kitchen as KIT
      Note over AI_Engine, KIT: AI has pre-built acoustic models for LR and KIT
      User->>Controller: Group LR and KIT
      User->>Controller: Set Group Volume to '50'
      Controller->>AI_Engine: Request perceptual balance for Group at Level 50
      AI_Engine->>LR: Set Amp Gain to 45% (based on model)
      AI_Engine->>KIT: Set Amp Gain to 62% (based on model)
      Note right of KIT: Result is equal SPL in both rooms
  

Axis 5: The "Inverse" or Failure Mode

Derivative 10.1: Emergency Egress Volume/Intensity Override

• Enabling Description: A method for controlling a group of audio players and/or lighting fixtures that is integrated with a building's fire alarm or emergency control system. Upon receiving a signal from the emergency system, the controller enters an override mode. In this mode, all user control is disabled. The audio volume of all players in a group is synchronously set to a pre-determined level to broadcast an evacuation message, while all lighting fixture intensities are synchronously set to 100% to illuminate egress paths. This happens regardless of any pre-existing group or relative volume/intensity settings. The state transition is non-reversible without a specific "all-clear" signal from the emergency system.
• Mermaid Diagram:

  stateDiagram-v2
      NormalOps: Normal Operation
      Emergency: Emergency Override
      NormalOps --> Emergency: Fire Alarm Signal Received
      Emergency --> NormalOps: 'All Clear' Signal Received
  
      state Emergency {
          direction LR
          [*] --> SetAudioVolume
          SetAudioVolume --> SetLightIntensity
          SetLightIntensity --> DisableUserControl
          DisableUserControl --> [*]
      }
  

---

Part 3: Combination Prior Art Scenarios

This section describes how the core concepts of US 7,571,014 could be implemented by combining them with well-established, open-source standards, thereby suggesting the obviousness of such an implementation.

Combination 3.1: Group Management via MQTT (Message Queuing Telemetry Transport)

• Enabling Description: A multi-zone audio system where each player is an MQTT client, and the controller is both a client and potentially hosts the MQTT broker.
  • Discovery: Each player, upon startup, publishes its identity (UUID, friendly name, capabilities) to a topic like players/discovery with the retain flag set. The controller subscribes to players/discovery to build its list of available players.
  • Grouping: To create a group, the controller publishes a JSON payload to a command topic, e.g., groups/manage. Payload: {"action": "create", "group_id": "group123", "head_uuid": "player_A_uuid", "members": ["player_B_uuid", "player_C_uuid"]}. All players are subscribed to groups/manage and will parse this message. Player A configures itself as the head, and Players B and C configure themselves as members, pointing to Player A for stream and sync information.
  • Volume Control: To change the group volume, the controller publishes to groups/group123/volume/set. Payload: {"level": 55, "is_relative": true}. The head player (and/or all member players) receives this and adjusts its volume accordingly. Individual player volume is controlled via topics like players/player_B_uuid/volume/set.

Combination 3.2: Synchronization via RTP/RTSP (Real-time Transport Protocol)

• Enabling Description: The system leverages standard streaming protocols for synchronization.
  • The "zone group head" selected by the controller acts as a lightweight RTSP server and RTP media sender. It sources the audio (from a local file, line-in, or internet stream).
  • When other players are added to the group, the controller sends them the RTSP URI of the group head (e.g., rtsp://192.168.1.10:554/stream).
  • The member players act as standard RTSP/RTP clients. They connect to the head, receive the audio stream via RTP, and play it out.
  • Synchronization, a core teaching of the patent, is achieved by leveraging the RTP timestamps embedded in each packet from the head. All member players buffer the incoming stream and use the RTP timestamps, in conjunction with NTP-synchronized local clocks, to schedule the audio rendering, ensuring lock-step playback across the group.

Combination 3.3: Player Discovery and Control via UPnP (Universal Plug and Play)

• Enabling Description: The system is built on the UPnP architecture.
  • Discovery: Each media player device runs a UPnP Device service. It advertises itself on the network using SSDP (Simple Service Discovery Protocol). The controller acts as a UPnP Control Point, listening for SSDP announcements to discover and list all available players.
  • Control & Grouping: In addition to standard UPnP services like AVTransport and RenderingControl, each player exposes a custom, vendor-defined service specified in its device XML file, such as X_Sonos_Group.xml. This service defines custom UPnP Actions like CreateGroup(HeadUUID) and AddToGroup(MemberUUID). The controller calls these actions on the players via SOAP messages to form and manage groups.
  • Volume Control: The RenderingControl service, a standard part of UPnP, is used for volume. Its SetVolume(Master, DesiredVolume) action controls an individual player. For group volume, the controller iterates through all players in a group and calls SetVolume on each, or it could call a custom action like SetGroupVolume on the head player, which would then propagate the command to its members. Maintaining relative volume would be a function handled by the Control Point logic before sending individual SetVolume commands.