3 ms·

This comment thread is very quickly going to become a discussion about software patents in general, however in this case it worth also looking at the history of

This comment thread is very quickly going to become a discussion about software patents in general, however in this case it worth also looking at the history of the case. My understanding is that Google partnered with Sonos back in 2013 to bring Google Play to Sonos speakers, during that partnership Google basically milked Sonos for info on how their platform worked in order to compete with them. I suspect that the outcome of this where Google devices have to have volume controlled individually isn't due to a patent on that specific functionality, but due to something with the inter-speaker communication system that Sonos pioneered (multiple wireless speakers playing sound in sync with each other, with no audible delay). Google will have had to change how they have speakers talk to each other and the side effect is the lack of group volume control. A patent on "speaker group volume control" I agree would be silly, but a parent on a wireless control system and protocol for multiple speakers that can be grouped together is far less so.

beambot 5y ago
I wouldn't classify myself as someone particularly "skilled in the art", though I've definitely built audio DSP solutions. I can think of 2-3 ways to achieve "wireless control system and protocol for multiple speakers that can be grouped" while just sitting here. In classic infringement avoidance ridiculousness, I have no desire to dig into the details... but this superficially feels like it would fail the obviousness test for patentability.
- samwillis 5y ago
  Everything seems obvious in hindsight. I think the true innovation and problem that Sonos solved when they started was to have synchronised compressed audio streams play on multiple speakers with do audible delay between them. That is not a partially "easy" problem to solve, and bear in mind that when they started they had to implement their own wifi network for the speakers as the wifi standards of the time (from memory) both wouldn't provide the necessary bandwidth but also few people had wifi at the time. The were no smart phones when they stated, they had their own "smart" remotes even.
  - lostlogin 5y ago
    > Sonos solved Sonos aren’t popular here at HN due to some truely awful decisions they have made. I really like my small system and it works great - mostly. You hit some seriously rough edges if you have a Unifi network, and Sonos’s use of STP rather than RSTP is system breaking until you realise it. And even when you solve this issue, there will be random outbreaks of dysfunction and failure to connect. The Sonos app is terrible, and the integration with Spotify occasionally craps out - logging out and then in again can fix it, sometimes. I like the system but it’s got a way to go.
    - samwillis 5y ago
      You are quite right, it does have rough edges and certainly more than 10 years ago when we started buying into their system (we have four rooms covered by 8 speakers now). The Spotify bug when it randomly cuts our is REALY annoying, it seems to happen in a cluster about once a week. Fortunately we weren't effected by their incredably ill conceived changes to the "legacy" speakers, they deserve criticism for that and I'm sure I would be less charitable if we had been effected.
  - nomel 5y ago
    > Everything seems obvious in hindsight. > That is not a partially "easy" problem to solve I'm curious if we could re-invent it, right here in this thread, without looking up how it's done.
    - fallingfrog 5y ago
      Have each speaker transmit a little packet with a timestamp 10 times per second to each other. Or relative to some designated central point. Each speaker will have an internal clock but use the central clock tick to keep exactly synchronized. Having synchronized their timestamps, the central hub transmits a specific time for playback to begin. At this point you need to make sure that there isn't any unexpected buffering going on, output buffers have to be tiny/realtime or the process of sending signal out has to be again synced to the clock, which means you need control over the firmware/drivers. Worst case you might have to skip or repeat a couple samples once in a while to keep synced up which in a 44000 samples per second signal is not a big deal. You need a big enough input buffer to play a few seconds of audio, just to be safe, but the output buffer has to be realtime. That's pretty much how I'd do it, off the top of my head.
mtrovo 5y ago
> suspect that the outcome of this where Google devices have to have volume controlled individually isn't due to a patent on that specific functionality I couldn't find the complete list of patent infringements (Sonos alleges more than 100) but it does seem there's one in particular about controlling volume on multiple speakers / rooms at once. https://www.theverge.com/2022/1/6/22871121/sonos-google-patent-itc-ruling-decision-import-ban https://www.theverge.com/2022/1/6/22871121/sonos-google-pate...
quitit 5y ago
This seems plausible as the group-volume feature isn't unique to Sonos (and predates them), however their specific means of implementing it likely is unique and patentable.
- tssva 5y ago
  The patent in question is not about the specific manner in which Sonos implements group-volume. It in fact doesn't even state how Sonos implements it. It is purely about the concept of centrally controlling the volume of local area network connected distributed speakers using a centralized control unit.
  - PeterisP 5y ago
    Then it should be unpatentable - you should be able to patent a novel technical solution that's necessary for a desirable feature, but not the concept of a feature; patents are for "how to achieve X" not for the outcome.
    - tssva 5y ago
      You aren't supposed to be able to patent an idea or concept but that is what software patents all too often do which is one of the reasons they are so awful. For instance this patent covers having a controller which presents a UI to raise, lower and mute/unmute the volume of a group of network attached speakers. When the user selects to do one of those things the controller communicates over the network to the group of speakers to raise, lower or mute/unmute their volume. The specific technology which implements this ability, i.e. how the controller communicates with the speakers, is not part of the patent. It is purely on having a controller which does the above however it may achieve it. Edit: Thought I would point out that when Sonos first filed their claims they made a big noise about Google using the same protocol as they to do to control their speakers. This protocol isn't covered by the patents in question. The reason is that the protocols in question are UPnP standard protocols.

beambot 5y ago

I wouldn't classify myself as someone particularly "skilled in the art", though I've definitely built audio DSP solutions. I can think of 2-3 ways to achieve "wireless control system and protocol for multiple speakers that can be grouped" while just sitting here. In classic infringement avoidance ridiculousness, I have no desire to dig into the details... but this superficially feels like it would fail the obviousness test for patentability.

samwillis 5y ago
Everything seems obvious in hindsight. I think the true innovation and problem that Sonos solved when they started was to have synchronised compressed audio streams play on multiple speakers with do audible delay between them. That is not a partially "easy" problem to solve, and bear in mind that when they started they had to implement their own wifi network for the speakers as the wifi standards of the time (from memory) both wouldn't provide the necessary bandwidth but also few people had wifi at the time. The were no smart phones when they stated, they had their own "smart" remotes even.
- lostlogin 5y ago
  > Sonos solved Sonos aren’t popular here at HN due to some truely awful decisions they have made. I really like my small system and it works great - mostly. You hit some seriously rough edges if you have a Unifi network, and Sonos’s use of STP rather than RSTP is system breaking until you realise it. And even when you solve this issue, there will be random outbreaks of dysfunction and failure to connect. The Sonos app is terrible, and the integration with Spotify occasionally craps out - logging out and then in again can fix it, sometimes. I like the system but it’s got a way to go.
  - samwillis 5y ago
    You are quite right, it does have rough edges and certainly more than 10 years ago when we started buying into their system (we have four rooms covered by 8 speakers now). The Spotify bug when it randomly cuts our is REALY annoying, it seems to happen in a cluster about once a week. Fortunately we weren't effected by their incredably ill conceived changes to the "legacy" speakers, they deserve criticism for that and I'm sure I would be less charitable if we had been effected.
- nomel 5y ago
  > Everything seems obvious in hindsight. > That is not a partially "easy" problem to solve I'm curious if we could re-invent it, right here in this thread, without looking up how it's done.
  - fallingfrog 5y ago
    Have each speaker transmit a little packet with a timestamp 10 times per second to each other. Or relative to some designated central point. Each speaker will have an internal clock but use the central clock tick to keep exactly synchronized. Having synchronized their timestamps, the central hub transmits a specific time for playback to begin. At this point you need to make sure that there isn't any unexpected buffering going on, output buffers have to be tiny/realtime or the process of sending signal out has to be again synced to the clock, which means you need control over the firmware/drivers. Worst case you might have to skip or repeat a couple samples once in a while to keep synced up which in a 44000 samples per second signal is not a big deal. You need a big enough input buffer to play a few seconds of audio, just to be safe, but the output buffer has to be realtime. That's pretty much how I'd do it, off the top of my head.

mtrovo 5y ago

> suspect that the outcome of this where Google devices have to have volume controlled individually isn't due to a patent on that specific functionality I couldn't find the complete list of patent infringements (Sonos alleges more than 100) but it does seem there's one in particular about controlling volume on multiple speakers / rooms at once. https://www.theverge.com/2022/1/6/22871121/sonos-google-patent-itc-ruling-decision-import-ban https://www.theverge.com/2022/1/6/22871121/sonos-google-pate...

quitit 5y ago

This seems plausible as the group-volume feature isn't unique to Sonos (and predates them), however their specific means of implementing it likely is unique and patentable.

tssva 5y ago
The patent in question is not about the specific manner in which Sonos implements group-volume. It in fact doesn't even state how Sonos implements it. It is purely about the concept of centrally controlling the volume of local area network connected distributed speakers using a centralized control unit.
- PeterisP 5y ago
  Then it should be unpatentable - you should be able to patent a novel technical solution that's necessary for a desirable feature, but not the concept of a feature; patents are for "how to achieve X" not for the outcome.
  - tssva 5y ago
    You aren't supposed to be able to patent an idea or concept but that is what software patents all too often do which is one of the reasons they are so awful. For instance this patent covers having a controller which presents a UI to raise, lower and mute/unmute the volume of a group of network attached speakers. When the user selects to do one of those things the controller communicates over the network to the group of speakers to raise, lower or mute/unmute their volume. The specific technology which implements this ability, i.e. how the controller communicates with the speakers, is not part of the patent. It is purely on having a controller which does the above however it may achieve it. Edit: Thought I would point out that when Sonos first filed their claims they made a big noise about Google using the same protocol as they to do to control their speakers. This protocol isn't covered by the patents in question. The reason is that the protocols in question are UPnP standard protocols.